Emerging Best Practices in Software Supply Chain Security: What We Can Learn from Google, the White House, OWASP, and Gartner

hi how's everyone doing sorry to keep you all waiting anyways i'll get right into it um today i'm giving a presentation on the uh google salsa and nist ssdf supply chain or correction software supply chain frameworks and we are going to uh together construct a road map on how to actually utilize these frameworks to uh create a complete best practices guide so let's uh just hop right into it um first question is why do we need new uh appsec uh security uh frameworks the answer is attackers are shifting priorities from uh production apps to software delivery pipelines and the developers of your applications software supply chain attacks are on the rise i don't think i

need to explain solar winds to anyone who came to this talk um nor code cove the cassaya attack or xcode spy but there's been plenty of other attacks and they're certainly increasing in frequency by 2025 gartner predicts that 45 of organizations worldwide will have experienced attacks on their software supply chains which is a three-fold increase from last year the first framework that we are going to get into is the nist ssdf now the nest ssdf is a recently announced framework that uh pulls a lot of inspiration from owasp's sam and it also lists gartner the white house and the department of defense as general resources uh the reason why this framework was actually created was in results of a

presidential executive order um from midway last year this order was uh announced in response to the colonial pipeline attack and was specifically designed to harden actual infrastructure but since it has uh since its announcement it has been extended to uh cover other particular aspects particularly software supply chain security the development of commercial software often lacks transparency sufficient focus on the ability of software to resist attack and adequate controls to prevent tampering by malicious actors ultimately applications just don't have the visibility into what they actually have within them and of course anti-security thrives in a world where there is no visibility um the nest executive order has been following this timeline we've since seen an actual ioc framework announced

in direct response to this we've seen additional guidelines surrounding the specific aspects which this framework covers and uh since its announcement we've actually seen a final version of the uh nist ssdf announced uh v 1.1 and critical software as defined by by nist includes software that is uh created and maintained by federal organizations federal agencies and other critical infrastructure this can include health care this can include electricity this can include water resources uh yeah and uh nist is to publish security measure guidance by july 11th they'll be consulting with the office of management and budget cyber security infrastructure security agency and these guidelines will help outline security measures for critical software the nist ss correction the sscs

directs um direct organizations to utilize the uh secure software development framework uh as defined here i'm gonna skip over some of this for sake of time because ultimately this is extraneous but i know a lot of people in here are probably interested in iot um part of the nest ssdf actually covers uh internet of things and other um potential uh accessories that could have access to critical infrastructure ultimately the one of the main takeaways from this ssdf is the five objectives which include protecting the executive order critical software from unauthorized access and usage protecting the confidentiality and availability of the data used within these resources identifying the exact dependencies used within this software we've heard the term s-bomb used

quite a lot recently especially in the world of aptek and ultimately the goal of that is just to uh produce a software bill of materials that enumerates all of your dependencies you can't really secure what you uh aren't aware you have and i've probably thrown the statistic out to a few of you that i've talked to but 80 corrections 70 to 80 percent of all breaches that occur are caused by a known vulnerability that has gone unpatched which to rephrase means that 70 to 80 percent of all bridges could have been prevented by individuals keeping their uh dependencies updated um objective four includes rapid response which involves quickly detecting responding to and recovering from threats and incidents a lot of that

just goes back to basic planning and objective five is training which is ensuring that the most important part of your organization which is the people involved in it understand the priorities in terms of security that your organization has an additional thing that the ssdf produces is a risk severity schema you can read through most of most of this on your own time i think the slides are available but the one of the keys is that anything above significant risk has a mandatory reporting required which is designed to help prevent vulnerabilities from going unchecked because as we've seen with incidents such as log4j if one organization is affected by dependency uh breach chances are others uh might be affected similarly

and we can skip over that so the key practices of the ssdf come down to preparing the organization protecting the software of your organization producing well-secured software that has undergone vetting and other checks and responding to vulnerabilities in a uh in a uh um sufficient amount of time you don't waste time responding to vulnerabilities i don't think i need to explain that one uh moving on to the google salsa the google salsa framework was uh released early last year and it was created as a a sequel to binary authorization for borg which is a bit of a ridiculous name but it's uh google's internal standard that they've been using for quite a while and i

i should probably update this salsa has moved away from using google and they've moved towards using openssf which is an organization that uh their main purpose is uh helping uh secure open source software moving on though google salsa entails different levels and these different levels correspond to different rigor of cyber security google salsa level one is pretty much no guarantees there really isn't any guarantee of uh source or build security level one though um entails the build process being fully scripted and able to generate provenance um salsa level two requires using version control and hosted build services that generate authenticated provenance this helps mitigate some risks inherent to uh human tampering or potentially uh malicious behaviors

uh salsa level three entails the source and build platforms meeting specific standards to guarantee the availability of the source and the integrity of the governance or correction provenance respectively and salsa level four is the highest rigor of cyber security according to the salsa framework this requires two-person review of all changes and a hermetic reproducible build process which is another way of saying you need to have oversight over all changes that go into your code base and you need to make sure that your build isn't dependent on humans inputting anything that could possibly result in error later

i find that this is a pretty good model for demonstrating the different places that vulnerabilities can enter into your source build packaging use and it should be noted that this chain exists within all dependencies as well recursively there are five categories of salsa requirements build source provenance provenance content and common requirements first is source requirements this entails the application being version controlled having verified history being retained indefinitely or at least for a certain period of time and uh two person reviewed it's over there by the way um let's see in terms of build um this in terms this entails having a scripted build that is reproducible able to uh be created a theme early um and also

isolated so that it doesn't affect other environments and so that other environments don't affect it this for example could uh entail creating a build test environment a build source environment a build production environment ultimately you want to be able to separate out your different environments and you also want it to be reproducible because chances are if your application isn't or your build is not reproducible certain errors can be introduced it should be noted that this is not a salsa requirement though i don't think i need to explain all of this uh let's move on directly to the key learnings of the nes ssdf and google salsa the sscf focuses more on what whereas salsa focuses on how a way i

like to articulate this is that ssdf is much more descriptive of the security practices whereas salsa is much more prescriptive of what you should do to secure your software and as such they are complementary frameworks they also uh both have concepts of tiers versus levels with higher levels and tiers uh corresponding to higher um guarantees of security um nist recommends a review for hard-coded secrets let's see both of them uh require uh utilizing um or question enforcing security policy uh consistently in other words having strong governance of your security policy they also suggest to detect and remediate misconfigurations as they're occurring for example configuration drift for those of you use terraform in your environments and additionally reducing

code tampering risk which entails requiring a two-person review using hermetic builds and utilizing code signing even as complementary frameworks though they these two frameworks don't cover everything and there are some gaps some gaps include identifying suspicious behavior and code leaks for example a developer just put in their two weeks notice a couple weeks ago suddenly they're cloning a lot of repositories chances are you'd probably want to notice that or at least flag it doesn't necessarily imply guilt but it could additionally you want to slow down attackers with each layer of protection this comes back to least privileged access additionally you want to perform anomaly detection which helps prevent any sort of anomalies um from going undetected as

i described before um and these this usually comes from multiple different sources the main way that you can actually perform anomaly detection effectively is by comparing data from multiple sources in your software development life cycle as this helps prevent potential tampering from slipping through i have a description of all these uh frameworks and more in pretty explicit detail on scicode's website um yeah and this page should be live now let me know if it doesn't work uh and yeah sorry i had to rush out a little bit but uh yeah we should have like a minute or two for q a if anyone has any questions [Applause]

i agree i agree salsa.dev is actually on the resources page as well should be the last link under the salsa section

do we have any questions for tony like 30 seconds

so nist technically because it's it's cyber security framework came first salsa is still very new it's actually still an act of development um certain refinements still need to be made of course particularly with regards to what does provenance look like some say that that could actually be what s-bombs end up becoming but from what i've read on salsa's site there's a vision of potentially just integrating with an application or a build system and running a scan to determine configurations and generating a salsa provenance certificate from that again not entirely sure how that will work but that is on the roadmap as i understand it all right that's all the time we have thank you tony for presenting our

besides this uh thanks for having me [Applause]