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 programs if anyone wants all all right so recap this

is a framework it's not a tool it is not another scanner that you're putting in there it is just a checklist of Standards to give a common terminology and an achievable laded approach to have integrity and security of build processes and external packages so that there's resiliency all along the software supply chain you should care because right now now there has been a exponential increase in software supply chain attacks because it is easy because more than 50% of the code that most people are using was not written by them that is not a bad thing everyone's like oh well maybe we just write our own code no the reason why today we are able to

deploy software so quickly is because we are leveraging open source which is great but that comes with risks so there's a trade-off go fast have a little bit more risk so how do we admit those risks and also government requirements are kind of coming they may not hit your industry yet they may not affect your company yet but sooner or later because it's becoming standards uh you are going to get impacted one way or another as a software producer you want to produce attestations and you want to verify any of the attestations of the tools you're using by setting in a policy you probably have policies at your workplace already for example do not use GPL or

maybe you're at an awesome place that allows GPL whatever but you probably already have some rules that you have to check when you're using these dependencies anyway just add it as an additional rule for when I'm pulling these into my artifact repository my jrog whatever this is another thing to check if you're just a consumer if you're not Distributing all you have to do is do the verification and again there's saua verifier by the ossf you could write your own it's not that complicated and there are lots of free tools to help you out with both production and verification all right so do we have any questions y yeah so you got

devel typically there yeah so so the the qu question is you're working with the development team and you you say yeah you know you want to you want to design your application securely are you doing all these things and they get their hackles up like how how do you approach them to get the adoption of this so the thing is you want to try and make it as minimal for them as possible which is going to be more work on either your devops team or your security team so you have to find one team which willing to take the hit so if you can for example use some SCA tool or maybe you've got gitlab which has SCA tools built in

you're like hey there's going to be this automated check which occurs for your dependencies and I've turned it on to check the licenses the vulnerabilities and that there's an attestation and it's going to put a comment in your PR don't start by having it block anyone okay again laded approach start at the very bottom just be like it's just going to warn you the that there's stuff we don't like in there and we would like you to try and work around it if you can for example if there's a vulnerability in the current version you're using and you look could you just go down one version or up one version and make it go away or

if there's no attestation can you double check that it is not typoed or would you mind if we proxied everything so that we could actually have the security team go through once a week or once a month to make sure none of these were typo squatted or known bad because then they could cut it off of the proxy and be like no this specific one's blocked cuz we figured out it was bad and then once everybody kind of gets it's boiling a frog in water uh once everybody gets used to that and it's not bothering them they're like okay it wasn't so bad then you can kind of crank it up a little and be like hey if it has a critical

vulnerability and it's going to one of our production systems we are going to block it and you're going to have to get a manager to sign off but then it can go if you want but again you could like go down a version or up a version or whatever and like here's ways to mitigate around it so you just keep slowly dialing it up because you're right if you make the developments team frustrated slow them down a lot it's not going to work out but you need to show them like hey it's not so bad and here's quick remediation steps and here's quick ways to get around it so that you and I don't have to have a conversation every

month for like why do you have 20 criticals or why do you have like 10 things that are not from npm or they're not from piie like why did you just go YOLO it off of you know Source Forge anybody

else uh oh than you hi Nicole um how would I put it one of the things that is frustrating sometimes for me uh being kind of a blue team guy with the government is a lot of the work that happens good work that happens is done on a volunteer basis of hours kind of like what you're doing right now um for for people who don't know we're establishing cyber Alberta right now community of of Interest try to actually strengthen the overall cyber security for the province one of the next thing we're about to do is establishing some kind of an Alberta Bas to start with who knows it might become National set of uh I'm going to call it controls a

compliance framework you want to work with the community of interest to do it it's not government coming and saying Thou shalt do the following things it's really something we want to work with the community of interest to establish you get the control framework wonderful now how do we implement it and such and I'm looking at what you're presenting today saying this would be a fantastic framework to implement across the province for your development efforts how do you and the group you're working with promote this framework and would it be helpful to count on an organization like what we're setting up right now this 250 Members Plus organization right now to try to promote implement ing a framework

like this that at the end of the day would be extremely useful like how do you it today how do you do it today and um how this is why I take offense to the boiling the Frog comment sorry for the accent but uh but how do you see it expanding uh would cyber Alberta be something that could be helpful if you were to come in do a presentation like that's kind of my question very much we yeah we've tried presenting it to groups um so far but there has not it's a little bit of a problem where right now we're trying to get people to be producing these so that people can verify them but there are not

a lot of producers and so a lot of times you're just going to end up with the verification step being like I couldn't verify there wasn't a file there um which is why we're really excited npm is all in and so until we get more of the package managers it may not help you out a ton yet so right now we're mostly reaching out to like maintainers of Open Source software so if you have anyone who does m maintain OSF stuff like absolutely tell them like hey this is really easy you can plug it into your GitHub CU once there are more of these out there it'll be easy to verify it and we are happy to do presentations uh

wherever and the working group like I said you can just pop into the GitHub uh you don't have to participate in the meeting so everyone can put as much or as little time in there as they want but honestly the hope is that this framework like you said somebody could write like here's how you implement it using jfrog here's how you implement it using GitHub here's how you implement it using gitlab and then it just becomes a turnkey thing like SCA used to be a bespoke do-it-yourself adventure and now it's pretty TurnKey you just buy something plug it into your cicd you're done that's what we're kind of hoping for is it just becomes another framework piece

where it's like you pop in this framework and it just alerts you for these key things you can turn the knob on that and be like I want to be alerted only if it's really bad or all the time depending which software project where it's going hi Nicole um is it okay if I change the topic to women in Tech sure so uh uh several years ago in the early days it was probably a year or two of Edmonton bsides uh I came to your talk and spoke to you afterwards about uh how um dismayed I was that uh I think I had less than 10 I I work for a global it firm and we

had on our security team less than 10% female identifying staff not unique not good not unique um and uh uh you gave me some advice on um wording job ads that you know obviously there's tons more you can do um but I'm happy to report that probably it took three four maybe even five years I don't know how long ago that was uh but we've now got our um uh female head count up to 45% yes uh spanning both both uh Canada and the US awesome so thank you your advice Works anyone else who has the same problem uh talk to Nicole I've got like loads of tips to and I'll just put a quick plug

it does not matter what your role is in a company if you tell me what your role is I can tell you how you can make an impact for Dei not just for gender parity but like how do you make sure that you're treating parents well because parents get shafted a lot because it's like oh well they always leave at 4:30 to pick up their kids should we give them projects yes give them the stret projects but anyway wherever you are in the company I can give you advice and or yell at you yep one more question Nicole my name is Michelle balderson I'm from ISS squared um I've been in the security IND industry for probably 25 years of my

life I'm getting too old to exactly remember but 25 years of my life and um one of the things that we have is an extraordinary number of of uh Frameworks coming out right every single government wants to build a new framework no slide against cyber Alberta um but from a Global Perspective we have you know ISO we have IEC we have we have tons and tons of Frameworks so the question relative to this and and sorry those main Frameworks that I talked about are very hard to adopt let alone a software cycle framework that you're talking about is there plans of taking this framework and bringing it into IEC or or other Frameworks because then at that

point be making it a subp part of a core framework that we could use based off of Industry to make a lot of sense is there any plans for something like that no but um so because they're all owned by different groups there is no plan to harmonize them right now but right now specifically with SAA and then I can also talk to a couple other ones SAA actually covers a subset of the ssdf and so if you do SAA you actually accomplish a chunk of the ssdf and then you only have a small bit left and I know in version zero we were kind of advertising that but I'm not sure that we're still advertising it and so there

are definitely some people I know who love making spreadsheets because they're my people and my hope for a lot of stuff is that if you look at for example there's like the iso and a couple others and I've looked at them when you accomplish one you're actually accomplishing a subset of another and what I think would be really nice and I don't know if anyone officially would do it but maybe I should get some people to unofficially do it and say like hey by the way if you have to comply with these three or four Frameworks we suggest starting with this one because it'll actually get you you know half of the way here to this one and then you can do

this one so everyone does talk and a lot of people are on multiple different working groups like for example there's a lot of overlap with es bomb in SAA and you can actually use an es bomb as one of your Sala attestations so if you started with es bomb hopefully you did Bam you've got a whole chunk of your salsa done and so they really are we're all trying to cooperate such that they're Stepping Stones instead of just these completely disparate things but nobody's actually published a guide to that because there is no organization who wants to piss off all the organizations so not helpful but there's the answer thank you thank you thank you

n