Software Supply Chain Attacks And You - Dan Lorenc

we're getting started close enough uh craftsman dan lawrence um everybody should be able to see my screen and the webcam right now uh so we can i'm gonna get started uh we'll give people one more minute or so since it still says 359 here for me oh there we go all right four o'clock we can get started uh so thanks for listening to the last talk of the day my talk on open source supply chain so my name is dan lawrence i'm doing a session live stream team here in austin texas i'm a software engineering lead at google and i've been working in open source for a long time now i've been involved in the cloud and

containers um open source space for a while but before that i've also been doing open source so a little close to about a decade now so open source security and open source supply chain security is a topic that's near and dear to my heart and it really keeps me up at night with some of these terrifying attacks uh so recently in open source i've been kind of working the techcon convenience delivery open source project to help start that and i'm still a maintainer in me today but i'm also working on a larger industry-wide effort to help secure the open source supply chain uh both of which i'll talk about in a little bit more detail later in the

presentation um i don't know about everyone here this is one of my first virtual events um so i'm hoping to have a little bit of fun i'm trying to make it interactive um we're gonna be doing a couple of quizzes and polls later on where i get to ask you some questions and i want to see your answers um in chat in the discord so um there's everybody should see the discord channel track two in the clouds i'll just type there and once we get to that part i'm ready to type their answers and please try to keep this interactive and be honest this is the judgment for the talk okay all right let's jump in

um so open source is under attack i'm going to start by covering the state of open source and supply chain security um unfortunately it's not good today you're under attack i'm going to cover uh how's under attack by who and i think you can protect yourself today and then at the end i'm going to talk about some of the larger efforts going on to help solve this as an industry and how you can get involved to help out if you're interested let's start with the problem with open source i don't want to batch open source open source is amazing most of my career using and building it i'm sure everyone else here interacts with every single day

but we do need to face the facts having a problem with open source helps our security is not a solution and it's not how we're going to solve them i'm going to start off here with one of those terrifying and depressing problems today i mean if you're not terrified by the time this session is over hopefully you can re-watch the recording and to keep doing that until you get terrified all right let's start out here with the first quiz um i don't know if everybody here remembers what this is um but this was a usb flash drive um before dropbox google drive and cloud storage is how people actually use the transfer files between computers

um so first question is hopefully people are listening within the discord if you found one of these on the street would you pick it up and plug it into your personal laptop i don't want to answer here zero no

no on the usb all right good um okay so it sounds like a little bit of a silly question but let's go a little bit farther with this if you found one of these outside of your office would you pick this up and take it into your office and plug into a work you know um okay even less so okay start to see where this is going okay so let's pretend you work in a data center not even allowed in the door so let's pretend you work in a production data center throughout the server maintenance in that data center and you found one of these on the sidewalk outside there you could take it and plug it into your

server running your databases hopefully people start to see where this is going and hopefully people have received some kind of training on this from their company and what to do so everybody doesn't get these answers on the fly um this sounds like a silly uh question but the reason this has been happening to everybody so strongly by our security teams and our training departments because this is a real type of attack um this has been used dozens and dozens of times even at the international level if anybody remembers the stuxnet worm used to disrupt uranium enrichment that attack was allegedly carried out by dropping thumb drives near facilities in iran to reach an air gap um i even had a

little bit of a run into this once uh and learned how seriously my company takes this type of threat i was living in san francisco back in the time getting some people in chat saying they can't see the presentation can anyone see it okay so some people can alright um sounds like it's working for some people okay uh all right sounds like there have been some intermittent problems hopefully people can get that resolved um yeah so i was living in san francisco in 2013 and a friend of mine had just gotten a brand new drone uh we went to fly it near the bay bridge in barcelona in san francisco drone technology was a little bit new at the

time he didn't really know how to fly it that well so you got a little bit out of control with the drone and ended up crashing into a building across the street and landed on a balcony of that building if anybody's kind of familiar with that area the google office where i worked is right there i started looking and realized that you can crash the drone into my office so i went in um got my badge and wanted to look for the drone but it turned out our security team had already confiscated the drone i explained what had happened and they agreed to give the drone back to my friend but they were still a little bit

worried because using pictures or spy on the office so they wouldn't give it to uh they would get the drone back unless he showed them that he wasn't taking photos uh but and this is the part that really taught me how seriously people take attacks like this is that they wouldn't plug his sd card into their own computer that's not scary they were this i mean him go home and get his own laptop plug that in and show them the pictures on it that would have been a kind of crazy attack vector but don't plug anything you don't trust into your computer because the overall message no matter how you find it that's how scary this is it's scary it

should be so what does any of this have to do with uh open source security what do drawings and usb drives and or any which would have been broken source today all right so time for the next quiz back to the chat um what did we learn and what can we take away from these other examples what is the difference between plugging in one of these usb flash drives am i tying on a sidewalk into your laptop and typing this command api install express so your npm is that network management what is the difference between these two people meant it to plug place answers

see some people are thinking about it trust in the contents of the files

nothing not as much as you hope but a little bit of social care okay um so here's my answer i think most people are on track a little bit um my answer is only one of them says production when you plug a flash drive into your laptop it's kind of limited to that laptop but if you're typing if you have install express and packaging add up into an app that gets deployed to production it's gonna eventually run with a whole much more privilege um people will stay on track though uh in general we rely on social proof and hopefully uh assuming other people have looked at those files and trust them a little bit and uh hopefully nothing bad happens

when we take this code that we've never seen before and run it on our computers or worship data centers um i don't really want to make an npm here this is a problem with package manager pretty much in open source today so let's jump and do another bit of a demo with a couple more quizzes so now i will try to tab away from implementation and cool people should see my uh my id here so uh this is a demo of go programming which is what i use for most of my program today and it suffers from most of these same problems so i'm going to show an example here of how a supply chain attack might get

carried out and how hard it is to find this is a little toy project it's called numbers and it tells you whether or not a number tells you whether a number is even or odd so you can see how this works here go over on main.gov

and we can see the implementation um this takes the number as input and it uses this uh percent sign which is the modulo operator um to tell if it's even or uh um this might be a little bit unfamiliar to you um and my colleagues let me switch over here um here's the github repo decided that the module operator was just hard to maintain so i got this pull request um to switch from using that custom logic to using an open source library here okay this is what the pull request looks like coming into my package um some changes to our go module definitions um an import statement and then it switches over here cool so this package is called odd as a

function uh tell us something is even around um if i wasn't being that um conscientious i might just merge this and yeah i recommend it but let's pretend i know about open source supply chain attacks and i want to take a look here and see what's in this code before i merge it i'm going to take this and open this up on github is odd so we can see all the source code here it's got some tests which is awesome um i didn't have tests before i'll check out the implementation here nothing uh too tricky just calling cannoli library is even um and now if i want to be extra extra careful we can even take a look at the

xeno library also tests all right we're being way more careful than 99 source maintainers probably would be we still don't see any problems so let's uh take this one extra step so let's actually check out that branch and run it and see what happens and check how to use library now let's do the same thing go run go for oh um see here is princeton starting at crypto line so even though i looked at all that code somehow a crypto miner got bored how did that happen does anyone have any guesses in the chat before i show how this slipped in and then uh how you might help detect this and prevent it

let's add crypto code and all those date units i looked through where did that come from overloading synonyms and code stranger urls imported as a dependency um i assume i will go to synonyms we're talking about one of those attacks or something uses unicode characters um that's another organelle that's not what i did here reported as a dependency technically the only two that got pulled in were it is because it was hidden in a different version of the independency so i can show how you might have caught this uh there are two main ways uh one is we just actually go back and look through here you can see that we're using this specific version of the

is even library so when i did my spot check i only looked at the top but it was hidden so we can take that commit and you can see that that one added a file to do once you print online thankfully you left this lock statement in just if you were able to detect it it was then deleted right after that so if you just look through the current state of the video repository you might never see these things to figure out what's actually getting merged here um i generally recommend vendoring dependencies so you can do google vendor then instead of just the uh descriptors here or the urls that are the trackpad and follow um it actually pulls the code in

it's going to get used so we can go through here and see the util file start crypto so that actually checks these dependencies in your repo so if we did that

[Music] around and then if we go back to github we'll review our pull request

even though github hides these gifts by default if we um they're at least now part of it so if we actually open up all these files we would see cryptoliner in here that would make it a lot easier to catch all right so i'll jump back to the presentation

awesome uh so i just showed drill modules i've talked about npm as well this is a problem with every package like i said um gold modules aren't all bad they do have some cool security features um but they're not perfect uh code review only shows the dependency metadata unless you're using vendoring that makes it hard to detect these things um uh and they go to you want a module proxy to store code from an intermediate location we were able to find that in a github repository that was reserved um if i had deleted the commit and that repository would have been even harder to find by going through there look at the go module approximate

directory restores things um and with go and new effect of an ecosystem number of dependencies is growing pretty rapidly um it's hard to take the time to review each line in a large project but it doesn't make it so you can skip you're still taking arbitrary code or basically picking up flash drives from the sidewalk and plugging them in every time you install a dependency that you didn't look at it um so to sum up this problem um we all understand that software and code review throughout the software development process is important because people will know to take that spirit they've been working on the team but we've somehow let open source slip through the cracks

um in general we hope that through social trust i'm having many eyes on the problem that stuff like this will get caught before it affects us but that's not always true these attacks are becoming more and more common so the chances of getting caught by one is increasing over time basically when everybody is responsible for reviewing open source software in many cases no one is responsible and no one's actually doing it um i showed how to review the source code for go um and it's easier than a lot of options because dependencies and go modules are just a source code imagine what that might look like for a language that packages uh build artifacts like java or even iphone

or some of the other interpreter language from the transformation step between the gear repository source code and the final thing you download installed let's take a look at python and what it takes to trace something like this back for a popular python module so i'm going to jump back to demo um we are going to start out with the requests library in python forgot the url if anybody has used python for a while um you're probably familiar with the requests library this is how most um http requests are made by this is one of the most popular libraries so if you go to the python package index and you type pip install requests this is roughly what you're going to get

we can look through here this tells us that the source code for requests is here on github you can click over to that to see the source code but if we download this through pip we're not actually going to get it break in this file um how do we know that what's in this file came from this repository um well the short answer is that we really don't we're trusting the maintainers of this to faithfully upload uh the build artifact from this github repository over to python package index um requests is huge and popular so we'll get kind of a pretty good feature that's what's happening if we look inside file and you can see that they actually have

a script here to publish a release it installs another dependency which if you kind of have an adversarial already had on you might get a little suspicious but it's not something called time of running some build commands you shouldn't want to upload that so if you were able to project some code into twine you actually have a chance to modify this code before it gets uploaded how do we know that this is what maintainers actually ran them we have no idea but since it's python we can still kind of do some basic verification thumb and download and keep varying so what would it look like to actually have to do something like that for python

we've got a couple scripts here so i don't have to remember all this bash time as i go but we can download the source code from github um git clone and check out the specific version we've looked at open that up um and then we're also going to download the published wheel which is what a python artifact is called um and explore those and then we can combine both of these and gift the two directors so for this one if we do it hopefully we should see nothing too drastically different now download the source code um and then the disk started okay so there actually are uh some files that are only in the git

repository facebook like kind of overplay it the document directory settings and stuff like that that you don't necessarily need um the main meat of this is the same overall request for entry um so it is possible to verify these kind of things in python and other interpret languages but now imagine what it would look like to actually do this every single time you install the package or for a language like java just get packaged up into jars which are a lot harder to compose and inspect how many people out there are actually doing this stuff for every packaging and this isn't even really a full demo i did this for the request package but if

you actually type installed requests you're gonna get probably a dozen or so packages the request depends on so taking the time to follow all those packages back to their repositories the exact versions that they got downloaded from and comparing file by file isn't something that most people are going to take the time to do realistically you know each one of those is a potential attack vector into your application let's try to jump back here

so these are all simple applications that just had a couple dependencies um even the request itself only has a couple dependencies to go from although one of the projects that i spent a lot of time working on most people um in the cloud of engineer space and colleague whoever uses kubernetes one of the most active projects on github this right here is terrifying monstrosity chart on the left snapshot of the dependency graph of the kubernetes project taken a few months ago uh kubernetes is built in the go like i showed before and it does make use of vendors it changes the dependencies get checked into the kubernetes source management system um you can see how very deep and nested

all of this gets in a large project but even with the kubernetes i think each one of these dependencies has a whole bunch of other dependencies and it takes a lot of time to start to review these things some of these are coming from trustworthy sources and we don't need to take as close a look at stuff here from microsoft um this is just a snapshot of a couple things to finish but there's something from a trustworthy source like microsoft but then um a whole bunch of basically just smaller personal github repositories um that are now being imported by these treatment service attachments think about how long it would take if you just started working on

one of these projects to get um admin or maintenance privileges on these repositories where you can put in any code you want and wait long enough for the update picked up and pulled into upstream dependencies um and making into larger larger products it's another small problem though um even if we do we say we trust a couple of these organizations or large projects uh we have no way to actually guarantee that this came from microsoft it could be making use of one of those you are also wanting our typo spawning things he's one of those opposed actually one of those unique characters that looks like one um there's no kind of public key or assigning infrastructure for us to know

that these are coming from the people we think they are if you uh start to get excited and think about a red team scenario here if you just had a couple months how long would it take you to get maintenance privileges on something like this you can merge code and get malicious code into clusters all over the world this isn't really scalable today we're viewing and preventing these things new tools new practices and these new systems to help solve this in a scalable way across the industry i'm going to talk about a little bit of history and why now open source has been around for decades and decades and decades um so why are we only

worrying about this today when people have been copying around and using it for so long um your um overall kind of history of this uh this attack has been known about since at least 1984 there was a paper published called reflections on trusting trust it shows turtles all the way down here even if you trust all the source code that's coming in you also have to trust all the tools involved i mean this paper showed an even scarier scenario where somebody uh they could modify it as a compiler um source code that could insert backdoors and everyday programs that that compiler built um and there's some really funny stuff there where they insert uh back doors

into the disassemblers and everything too so even if you use the disassemblers to look for these back doors those disassemblers have been compromised they have no hyperloops so it's kind of troubles all the way down if you don't know how the tools you use were built or the tools that built those tools um it's kind of a nightmare scenario uh so people have known about these attacks forever they have started to accelerate though which is the working part um in 2006 i got pretty worried and made a whole bunch of security improvements and a bunch of debian and red hat package repositories were poisoned people were able to insert malicious packages right into the places that

everyone installs and their security tools and competitors from um 2010 there's a stuxnet where i might mention before to disrupt an international scale um some similar attacks have happened on criminal.org with one external development story and uh even uh in the new baggage management space um i like to call out the docker one two three three two one attack um it didn't have a huge impact but it is pretty scary when you think about what happened when docker was first gaining momentum and dr hoga was an open source uh repository for container it was a group of people um i don't think they were ever really started publishing a whole bunch of useful containers with

my sql tomcat coming some crypto uh images were published on them they did a good job of maintaining them and keeping them up to date for years and people started using stuff in docker one two three three two one then eventually um they inserted put the lining into these container images slowly over time it shows that if you're patient and actually do useful work people will build on you and end up you the way open source is supposed to happen and then you can reach that trust by using that platform you've built to um inject ransomware or crypto mining or all sorts of terrible things there have been much others recently like the webmin attack

that one was the build server compromise so the ci system was used to publish webmin a popular remote administration tool for servers was compromised so every release had some code injected into it to add a backdoor to a server administration tool and that was in a while for a while when you start thinking about you know resource supply chain um it's every piece of the way that this stuff gets delivered to you it's not just the source code it's also the build tools and both systems and every one of those is an attack factor it's really exciting if you've got a red team on uh really scary for anyone else um some more numbers here just to show

the scale of this problem um in 2020 has been a year full of pretty bad news i might need to have a few solid fire here and scare people anymore but uh supply chain attacks this year aren't looking any better than everything else um there are 11 million developers running npm commands each month grabbing packages from the internet and installing it um there's been an 80 percent increase in supply chain attacks in 2019 2020 isn't over yet but seeing a similar increase so far pretty much everyone is using open source software whether or not you know you are um 97 of the company is using it in some form so pretty much everyone needs to be

worried about this problem um and then there is the scale of code sharing with things like github and awesome package managers it comes more and more using other people's code the average node project has 86 dependencies that's just across all github so it's small and large many products i've looked at have one or two orders of magnitude one that getting pulled in every time you add something you need to think about the different attack factors here opening up for people into your code by any interpretation here this is serious and getting even worse again why now why are people only doing this now and why is it rising well the cost per hack and the rest of software is increasing all

of us are either trying to protect systems or doing our job we're closing all the other doors people stopped leaving servers just open to the internet we're all using https um most of the other common entry points are getting tougher so attackers will actually find the easiest way to the rise of open source at this point it's probably the easiest place to inject things um not everyone uses uh not all software is open source and you have to technically have to worry about these type of moves coming in from paid vendors but that's much harder than open source so that's the easiest attackers all right so now if the scary part is over um everyone can relax and start talking

about some reassuring things hopefully um if you want to kind of jump out of this and start looking at every line of your dependency code in your application i completely understand you don't have to listen to the rest of this um hopefully this will be recorded and you can watch the rest later but now it comes the optimistic part um how you can protect yourself today and what we're doing to make this um harder at manage your level how to protect yourself um thankfully nothing here is too complicated um you just need to start protecting your supply chain first you need to lock down your own repositories some basic stuff like enabling and requiring two-factor authentication for

every one of your contributors if someone you know an employee intercompany or another resource container that you trust on the city of code if they're not using two-factor authentication they could have been compromised so you need to start requiring everyone to adopt basic security standards require everything to go through code review and actually take the time to review the code that's coming in whether it's yours or not um this one is essentially this kind of painful reduce your dependencies uh dependencies are great and easy to get stuff done quickly but you need to think about every dependency as an attack evaluate if you really need your home using something great it's in hundreds of non-great

uh second level dependencies that's a problem uh take that into account as you're evaluating what to build on then uh the even tougher part um it's not tough from a complexity perspective it's tough it isn't painful at times you need to audit your dependencies um track updates to them but you need to review these updates just like first party code you need to go through everything this isn't only about people inserting malicious code dependencies have bugs too sometimes those bugs need to vulnerabilities to get reported cdus if you're not checking uh your dependencies you have cbd databases um then you have a bunch of different supply chain problems then the final piece um making your cict

pipeline observable so this is not so much about protection but it's about mitigation after the fact if you aren't vlogging every single version and every single bit shot and every commit and every digest of every artifact you're producing then if something like this does happen you're gonna have a much harder time figuring out how compromised you got um the stuff above this is about trying to prevent yourself from having a bad day this bottom one is about uh making that bad day not turn into a bad month if it does happen cicd system keeps all of these august and then you can track down what versions of your dependencies are in production and make it easier on yourself later

all right so i'm talking about uh some stuff that's going on that'll make these attacks harder and um

identity and software is a big one um today uh it's pretty common if you sign okay commits github you get a little badge like i showed here at the top right saying comment has been verified um which is great it looks like insecure but all that really says is this someone generated there and signed that it doesn't tell you who did that um just as someone did we need to get beyond just these signatures without another source of trust or pki key infrastructure um that verified badge doesn't really mean anything um for maintainers of open source projects we need ways for them to share their uh identity in the public keys that they need to be using um this will help

prevent that tax where people screw for pretending but it will also make it easier for maintainers to know whether or not a contribution coming into an open search project it's going to be someone they trust or not uh since these people are overburdened and barely have time to review the code

terribly hard today but there's a bunch of work going on in the open source git project itself to make it easier to sign commits today you have to use gpg which is kind of clunky to generate key pairs um but everybody already has says h can set up and push to github hopefully um and there's some work we have to make it possible to sign your new comments with these ssh students instead of having a manageable separate settings repairs um in two factors everywhere thankfully this is finally originally victory across the industry almost every service supports two-factor off um but it's hard to check to see if your contributors or other progress that you're using

are using two-factor author you can acquire it on your own project but you can't tell if you're depending on something that does not require um if you're only independencies from people even if you trust them and they're not easy to factor off um then that's a problem you need to make this visible and kind of sharing the projects with people that aren't using two factors off into setting up this basic security protection and then like i talked about uh just a minute ago um better pki infrastructure so that all known people can share the public keys that they do their work so we can have more trust the work that's being signed with these kids

moving beyond just that kind of important verified symbol that doesn't really give us much information so i'll next step up from identity who is typing things at their keyboard we also have to start uh playing better ways to trust the source code that we're using depending on if you take source code in a binary form you have very few tools to figure out what code went into that binary what tool is produced there are some projects that have to standardize a software bill of materials s-bom is that everything to search for their software build materials which will allow people to distribute executables and binaries to describe all the things that went into those download random program

you can see exactly where it came from in a trusted way um this is coming from me uh hopefully instrumented build systems that will automatically generate these standard formats once the api paper is um and then tying that source grip back uh once you can go from a binary to source code let's source code back to the identity of the contributor that's the federated strong identity programs we talked about before and then just looking at source code to figure out if it is secure we have security audits many large open source projects have done them uh but they're expensive and hard they don't do them often enough rather than get one audit every two or

three years um we need to come up with ways as an industry to contribute funding um to these projects that we're all depending on that aren't being uh don't have enough intention to have a refund auditing in a more scalable way for critical projects um once we have the really good data showing which are going in the contributors are for projects you need to start to do more advanced techniques it sounds like a data problem um because it is like an anomaly detection there have been a couple attacks where uh somebody just abandoned a package because they got maybe with their job or personal life and handed it over to another group of containers that we're

willing to take home if you were looking at the commitments you might see a huge change in activity there to find that profit something we need to take a closer look at and then in addition to auditing we can start to do things like crowdsource reviews so if you're on a project with hundreds of thousands of lines of dependencies at your company and you want to spend the time reviewing those hopefully uh crowdsource that so everyone out there isn't reviewing the same set of lines of code can build up a little bit of trust with each other um and flag things that we've all read to make sure that many eyes on every line of open source

is actually true if few more eyes on each one

after the source code course there is the build process we talked about the reflections on trust and trust favor and the demo i showed with the requests library we need to hit ci and build systems uh to log your activity and make this probably viewable so that everyone can trust it right and if we could actually just see in a secure possible format exactly which commands got running to transform that requests give repository to the published package in python so we don't necessarily have to audit it every single time we could just see the scripts that were happening trust those scripts and trust that the cs system will be run correctly the tool chain vulnerabilities can also

come in the tool chain level once in a while there's a bugs out there will come higher than the results and uh binaries built with it being subject to the os attacks for example um if you don't know the tool chain that was used to build your own application and you don't know if you're subject to those kind of things again we need ways to securely log the exact versions of the tool chains that were used then the final piece the artifact manager itself one of this matters if somebody can just upload artifacts directly to that or modify the artifacts that have been uploaded already um knowing who the vet and offensive different people from the maintainers i get

it's a great start here um knowing whether or not updates are available to thanks to fixed normal abilities that's another huge attack factor that people rarely consider if someone cds are out there in the wild and trick somebody into not updating because you can point them at an out-of-date package or something like that you can keep them vulnerable and exploit that later um there are actually some protocols designed to help uh flag stuff like this so if you know updates are supposed to be available and you're not receiving them um that completed and then tampering of course the source signatures uh didn't come in any commission everybody has some experience with already um but uh

organizations should be signing their artifacts unfortunately not every package manager supports this

um there is improvement happening to almost every one of these pieces um especially package managers this is kind of a time for a whole bunch of improvements here we talked about some cool stuff um well some of the parts that make go modules harder to work with securely but they do have some cool improvements uh the versioning selection algorithm info modules is designed to help prevent you from upgrading accidentally of the only upgrade when you need to and the goatee ones that hit module proxy server actually publishes all of these to a transparency log which is this type of system that lets them log the exact tags and versions of all the go modules to the source code so if you and i both

install the same original package we could be uh be very sure that we did the same source code that's something that's just started rolling out similar to the certificate transparency program it's used to secure the way that ssl certificates get issued but that type of support should be used by pretty much every package manager and then finally cbe reporting so this is how we report things that we do find uh this uh process is still very manual and humans are actually still numbered like you have to email someone usually or fill out a form to get a cpd number which is great back when you were talking about operating system packages uh if you have uh maybe a dozen or so

install on your computer but language package managers where there's um hundreds of thousands of times being uploaded each month uh it doesn't really scale to that process so it's going to improve the scalability of cpu recording so that it will scale to this open source world where there are way more packages than anyone's ever dealt with before some other cool stuff happening programming language improvements um a bunch of kind of the research level here it's not as far along but making it possible to apply permissions for the android app store at a dependency level within a larger program so if you want to install something you don't really trust so much today you're giving that the same permissions that the rest

of your program runs with imagine if you can sandbox that dependencies it's not allowed to access the final system that's not allowed to access the network i'm sure i trust it to do some basic uh computation there's also just general hygiene improvements the bulk stuff i talked about before turning out two-factor authentication signing commits signing packages all these things that everyone knows are good um that aren't necessarily taking the time to do you do enforce that and that's a lot easier and kind of increase the adoption of stuff that already exists and i talked about cds all right i'll end uh with a couple links to how you can get involved and then we can go to questions

um overall summary here uh supply chain attacks are a serious problem for opens for software and software in general i scared everybody a little bit that's a lot of that and this is a standards automation and big data problem that we can all stall together if you try um there's kind of a link here for a supply chain security project in the techcom cd open source project that i'm currently working on or you can see some information and reach out and get involved if you want to i need some contact information for me as well as you can follow up after uh here is my account where you can find that little crypto liner code both for

you running um and then my twitter and many languages that are standouts and their supply chain support um from a security perspective um yeah i'd say um i think go is probably done the most with the transparency log stuff that they've done to make certain classes of attack starter um i think one each package of trainers in general are all pretty far behind things like operating system package managers that have been met this for a lot longer but those kind of have the benefit of usually being set up and run where only a core team has access to publish those packages um and they don't have to deal with the scale of thousands of people uploading

stuff constantly i think um learning from light layers learning from the operating system i could commanders and integrated basic stuff like signatures and some of the tuf or the update framework has come up with uh on other classes of attacks that need to be prevented with those uh update notification prevention attacks i mentioned before how helpful would virus total be on this area um to virus that our approach registers not to be weak yeah i think um i kind of classified that as a dependency scanner um they're pretty good at picking up um known cves and their dependencies and kind of banning you to update or upgrade github has some of that data in now or if

you're using certain languages it'll notify you if there's a security update you need to pick up but the challenge there is how few of them are actually reported uh and how long to get them recorded and let's see these

file

you