What exactly is Supply-chain Levels for Software Artifacts (SLSA)?

all righty so we're here to find out what is Sala supply chain levels for software Architects artifacts um all right you know what it is now we're done right okay maybe not let's start with what is a supply chain I'm sure you all actually have an idea of what this is because we had problems with it the past few years and that's why like everything got super expensive and delayed but basically widgets any widget has a supply chain it includes the original stuff that gets refined the creation of each one of the components the Assembly of the components into subcomponents the subcomponents into the actual Widget the transport the sales the retail yada y yada with software it's the same idea you're taking these different pieces of software open source dependencies and they get bundled up into some proprietary stuff which gets put into a package then somebody else is like I'm going to take that package and OEM it into my package so you've got the same thing going why do you care well I'm sure we've all seen this XKCD comic yeah upwards of 50% of the code today that is being used is actually written by somebody else by a third party usually it's open source this means that if one open source component gets compromised everybody who Ed that gets compromised uh so everybody remembers like the oaka issue the pie torch torch traon issue there's been a lot of fun supply chain security problems lately all right so what's salsa have to do with this like I'm going to have some Tostitos while I do incident response well it was started by Google Google seems to have an obsession with food they've got a new thing called guac that goes with SAA I don't know they're very hungry I guess because they get all that free food uh and it is now actually owned by the ossf we're on version one uh it actually took a really long time to get to version one well okay great what is it it's a check checklist it's a framework that you're going to use to try and prevent tampering to show Integrity of these packages and the infrastructure that the packages are built on it's how you know that you're safe enough nothing's ever going to be safe if anyone tells you it's a silver bullet it's 100% they're lying don't believe them run the other way all right so what parts does it care about we divided it into three tracks build Integrity meaning you are building this software on what are you building it on Bob's computer uh does Bob have an antivirus what happens if Bob gets sick what if Bob clicked that link in his email you know is it can you reproduce it like if Bob's doing this bespoke process how do you know that build one is going to be the same as build two it's better to have a dedicated machine or dedicated infrastructure to do these build processes so that it's replicable so that you can kill it and spin it back up again and that hopefully that new spin up doesn't have whatever terrible thing somebody download it onto it there's also the source Integrity track hopefully anyone here who's doing code has like twers review maybe in your GitHub they require you to have some kind of security key a hardware key or at least be signing your commits these things help with Source Integrity it means somebody can go back in time and look and if you know somebody got compromised you can see okay well what were all the commits by that person that was compromis let's double check them let's see if there was anything fishy in there and last is dependencies the thing that we were just prattling on about is what you're bringing in is there some kind of checks that you're doing on them do you have like a SCA tool do you have sauca verification is there something you're doing to make sure that you're not just yoloing it all right so we've got those three different tracks within the tracks we've got levels one through four hopefully that's readable yeah good enough um so this looks a little complicated but it's the simplest we could come up with and basically it says if your Lev is zero you're not even trying if you're level one you've at least documented what's going on two you've provided some tamper resistance three you you're actually targeting specific threats you've got a pretty good you know amount of stuff going on to protect yourself and four is the highest level of confidence that you can have again that does not mean 100% safe it just means you're fairly confident if something happened you could detect it and so this is a progressing Integrity guarantee uh and it also gives everyone common language I'm sure everybody knows at work when you say the word service or secure or whatever means something a little bit different to everybody or vulnerability have you ever gotten into the fight about that one like this one's a high no it's not so when you have a Common Language at least you can be like per this standard per this framework we are this we may not agree with that but at least we know we're talking the same thing by the way all the slides um in my speaker notes have references to where all of these images and things came from and I'll make it available at Twitter or whatever the hell it's called now um afterwards and so you can find it there all right this one is a little bit complicated but like how do you figure out which one of those levels you are this is not something where you can just do one of the things in level two and you're like boo I got level two no you either have to do everything in a level you can bonus points do some of the stuff in the next level but you don't count as that level and so this is the checklist for the build track that we were talking about how do I know which level of the build track I am great Nicole where's that source track track and the dependency track we haven't written them yet so if anyone wants to join the working group with me there's details on that later if you've ever had a group of people all trying to decide how you get multiple different Industries to cooperate and agree on the thing you know it takes a while so anyway at least for here let's give an example what do I mean by Providence generation exists so Providence means where did you get this from did you just like pick that dependency up off random repo on the Internet or did you get it from piie you're documenting where this came from and then ideally it documented where it came from so you're trying to track it back through this supply chain and we're talking about producer so as a producer can I say that I'm following a consistent build process can I say I use GitHub and I use this cicd process or I use get laab and iuse use this pipeline configuration and so in the future if I want to replicate this I bam I just pull out GitHub or gitlab and this config file done replicable now the interesting thing here is for level three you've got to have it isolated and hosted right now we have a little bit of an argument about the word hosted because people seem to think and we agree with them that hosted implies you have to like host it on somewhere you could actually self-host that's fine we're trying to come up with some better terminology there but it just means that we don't want it to be you know Jane's laptop we want it to be a dedicated system that is isolated you don't need to go as far as air gap air gap is a pain in the butt been there done that but do you have a firewall around it can you prove it's not randomly calling out to the internet how many malicious dependencies can you detect and the answer is a lot by just looking for when you're building your process is that that open source dependency calling out to the internet to try and grab something is it trying to grab something that's typo squatted looks legit it isn't or is it trying to grab something not from a package manager that's super sus so instead have a local proxy cach build everything in isolation so you know exactly what is being built and that you've scanned all of that so that's why you get into level four being the most trustworthy all right so what does it do well it's not SAU is a framework it's not going to detect a cve it's not going to detect that you leaked a passcode it's not going to detect that you have a key leaked it's not going to stop Insider threat but it's going to allow you to set up some extra rules in your cicd process so that you can get earlier alerting to I wasn't able to tell where this came from or this did not come from a trusted Source this is something worth looking at it may not be a problem but you should take a look so it's giving you extra rules and policies you can put in place it's also really handy for incident response how many people here have to respond to something and be like okay when did this thing go wrong what got introduced well if youve got really nice records of all the changes to your build system and where you're grabbing everything from well I mean when you figure out approximately was between X and Y let's look at all the docks there right all right so SAA recently changed from version zero to version one if you did version zero or heard about it what's kind of the differences overall one is more stable because we kind of lowered our expectations um it sounds bad but it's actually good we were aiming for like really good build systems and we're like nobody's going to get there this is not going to help anybody so less ambitious but way more stable and achievable it also corresponds really well to the Providence requirements that we had dug through in version zero and so what I was talking about like tracking things back through the chain which gets into the whole guac thing which I'm not going into in this talk but you can look it up guac but then put minus guacamole otherwise your search results are just not going to help you uh we also deferred some of the level four stuff is like if you want to go for it go for it but we're not going to spell out exactly how to get there because most people are going to struggle to get to three all right so again key changes we made the levels into different tracks build versus Source versus dependency so you can focus on different ones instead of having to do everything all at once so you could say well I'm a build three but I'm a source two for example um and then we added some guidance around doing the verification so before we focused on making the documents version one has a lot more stuff about verifying the documents and then finally we updated some of the schemas if you are actually producing the schemas and not using a tool um there's a lot more clarity of exactly what we want in there why did it happen now governments that's the answer they're they're the problem right um well in this case they're actually trying to help everybody out uh US government put out uh EO 14028 uh European Union cyber resilience act Canada did see 26 but it's mostly for the Telecom industry maybe we'll get an update that expands it uh Germany cyber resiliency act clone with a different name um basically everybody is coming up with stuff because everyone has noticed this is a problem so even if your particular industry does doesn't yet have something saying you have to follow this it's not the worst idea to follow it it's similar to sbom and in fact you can use sbom as a piece of your sauca documentation for again saying what is my source where did it come from Etc just use an sbom so you know why not all right so software development life cycle hopefully you're all here because you do software development um or at least put software into your stuff what does software look like well if you sum it up it looks kind of like this somebody writes some code the code goes into a build system the build system grabs some dependencies it packages it up somebody uses it hopefully if nobody's using it maybe you're a startup um anyway and that comes with all of these problems that are kind of sorted out into these three sections and so you can see at each one of these areas there's the potential that somebody can compromise something so all right how is SAA actually going to help this process well and this is going to seem like a really weird segue but just hold on minute or two with me here if we produce these artifacts that I've been babbling on about and we've got these attestations here's the pieces of them and all right let's hopefully right here if we start over here the predicate AKA where' this crap come from goes into a statement that says hey I include all these different predicates which goes into an envelope which says I built into this and I here's how I built it I used GitHub and I used this cicd and I did it at this time and then by the way here's all the stuff that went into it then I sign it and then if I've got a lot of dependencies in my project I bundle them all up into a Json bundle format and then I can put this either along with the package that I'm deploying or if I'm putting it into a package reg registry npm and I think piie now have support you can upload it with your wheel your cargo your whatever so there's multiple different ways to send it up currently the recommendation is to use intto ATT testation format intto is its own format we just said hey it's really handy why don't we use it um it's just a Json format it's not particularly exciting it's just a specific set of key values where we say like hey can you tell us what time you started the build can you tell us you know what build processes you used you did it on this Docker container or whatever um and then the other thing is for your predicates you can like I said include an spdx sbom you could actually you don't have to use these formats you can invent your own format as long as who's ever consuming it is happy with it so if you just want to like put it as a text file cool put it as a text file the whole trick is can you actually go back and look and be like what was in there what did I do because we all remember solar winds and the dll changing so if you had a hash of something saying like it should have been this hash maybe you would have got an earlier warning all right so we created these documents that's great we published them we either put them into piyer or we sent them out with our bundles and they're signed so somebody can verify that they're actually legit so now I'm the consumer I'm going to say this hopefully I say it again somewhere in here we trust build platforms and we verify artifacts so for the build platform there is not going to be an automatical way that somebody's going to let you audit their build platform system it's not happening on the other hand a lot of times you probably give a security assessment to your vendors right A lot of the stuff for the build process is actually already in most security assessments so you can be like you know what I trust active State I trust Google I trust this person's build system I trust that they are doing twers review or they say they are um or an auditor went through and said that they are so now that I trust these companies if those companies sign the attestation I believe in their build system everyone has to take a leap of some trust somewhere and that's where you're going to take that leap of trust now that I trust these companies I can say anything signed by them when it comes into my process where I'm deciding to use that dependency where I'm deciding to OEM this I'm going to check the signature and then I'm going to crack it open and I'm going to see does the hash match does the number of files that I'm supposed to get match and if I want to go as far as that does the sbom match does everything it says I'm supposed to get is that exactly what I got so now I can actually put in a check during my build process to verify the artifacts and the files that I'm getting you can't can't verify their build system but once you trust it you can trust those signatures and go from there uh and I forgot to mention there's tools like saua verifier that are out there there's other tools that are out there you do not need to invent the verification saware yourself it's already there so we've now fixed a bunch of these we've fixed C through H being that we can just check things hopefully your SCA tools your cicd tools start building these in in the near future maybe if you have a feedback button you could be like hey I want to start doing this can you please support this in the near future so I mean you've still got problems with your source code but if you're following secure software development practices twers code review multiactor Keys you probably have a pretty good degree of trust in your source code hopefully and then if your build system if you're aiming to have a nice build system that's hosted remember you can self-host with a replicable system that you're scanning and you're updating and you're patching on a regular basis you've got a fairly trusted system maybe you're actually tearing it down and rebuilding it constantly so that if it does get compromised it's a little bit harder for it to stay compromised then you've actually got a pretty hardened system all right so I talked about all these tools that you can use let's go into some specifics testify SEC witness is agnostic uh um they do have a paid version but they've also got an open- Source version these guys are very nice and if you tweet at them they'll probably actually answer your questions uh although they might prefer if you just put in a question in the uh GitHub project but anyway it's pretty agnostic they wired it up to work with GitHub and git lab uh they may wire it up to work in other systems if you ask them or maybe if you try and help out Google Cloud build supports salsa GitHub actions support salsa gitlab Runner support salsa so I mean if you're using bit bucket I don't know what to tell you other than bit bucket you maybe you want to use something else anyway maybe you can get testify a second there uh and then all right you've got all these documents being built for yours you want to be able to verify all the stuff coming in that's where saua verifier comes in um some of these other systems may also be able to support the policies again use your feedback ask them to be able to do that you can also write your own if you want but it's annoying mostly uh it's not actually hard it's uh taking a signature verifying the signature calling it's like checking uh keys on https so if you've done that you could totally write your own some package managers like npm support this there's other stuff that is soon going to support it um if you want to use a vendor solution I work at active State we do that for you um so yeah you got tons of choices all right how do you get more involved if you're interested in Frameworks and you're interested in protecting dependencies in your stuff and everybody else's stuff because you don't want to deal with log 4J crap again well the ossf has a supply chain Integrity group uh working group specifically you can go to our GitHub repo there are open issues and they basically say hey you need to Define hosted better because it's confusing people you can just go ahead and you don't even have to be a member of the project you can be like hey I think this word would be better or I think maybe just putting a little Aster and pointing people to the appendix where we Define things would work whatever just jump on in join the group there's it's open to everybody uh you also could listen in on a meeting they're all put on to YouTube afterwards so you could see if you want to try and attend a meeting in the future um it may not work with your work schedule or whatever um but if you can the meetings are open to everybody to attend uh and we publish the agenda in advance so you can check that out and then I'm halfway through but I'm done my talk because I'm from Philadelphia and talk fast so we're going to recap and then people can ask questions or I can get into vulnerability disclosure progr