Microsoft’s Secure Supply Chain Consumption Framework (S2C2F)
Microsoft’s Secure Supply Chain Consumption Framework (S2C2F)
A look at Microsoft's Secure Supply Chain Consumption Framework (S2C2F)
As one of the largest contributors and consumers of OSS, it should come as no surprise that Microsoft has also created a software supply chain security framework. Microsoft first officially announced the S2C2F in August 2022 but stated they have been using it internally to secure their own development practices as early as 2019. Taking it a step further, Microsoft contributed the S2C2F to the OSS community in November 2022 by having it formally adopted by industry OSS leader OpenSSF which is leading efforts such as the OSS Security Mobilization Plan.
Let’s dive into the framework a bit to see what it covers and aims to achieve. Microsoft states the goal of the framework is to lay out the core concepts of securely consuming OSS dependencies and implement core practices of secure OSS consumption.
Much like similar frameworks, the guidance emphasizes the critical role OSS plays across the software ecosystem and broader industries as well when it comes to driving both productivity and innovation.
Microsoft states the guidance is broken into two sections, the first being solution-agnostic and maturity oriented aimed at individuals such as Security Executives, while the implementation guidance is focused on actual software developers and their security peers, which makes it both informative at the organizational level while still being actionable on the tactical level.
S2C2F has 3 high level goals, which are:
Provide a strong OSS governance program
Improve the Mean Time to Remediate (MTTR) for resolving known vulnerabilities in OSS
Prevent the consumption of compromised and malicious OSS packages
The three framework goals work in tandem with three core concepts, which are:
Scale
Continuous process improvement
Control all artifact inputs
While the core concepts may sound simple on the surface, they can be incredibly complex and daunting in large enterprise environments that are developing software. As the guidance points out, the modern software developer consumes OSS in a myriad of ways.
Without developing standardized ways to consume OSS and having developers stick to them, it will not be possible to secure OSS as the framework points out. This required bringing a governed and structured approach to OSS consumption across all the organization's development teams. As with most security frameworks, S2C2F is a journey that organizations embark on and for this reason it is framed as a maturity model which focuses on continuous process improvement. Organizations can prioritize specific requirements for earlier implementation and make changes as new threats and risks emerge.
Lastly, practices and maturity implemented in isolation isn’t efficient and doesn’t address the broad attack and risk surface of the modern enterprise. For that reason, S2C2F is oriented around scale as a core concept as well. One specific example the guidance points out is the advocacy for a centralized internal registry that developers use, which was a recommendation in sources such as NIST’s Software Supply Chain guidance such as NIST 800-161 r1.
As the guidance point outs, this model falls apart as soon as a single developer decides to pull OSS components from anything outside of the internal registry and the internal registry itself requires overhead and management, which has an associated burden and cost. S2C2F was designed as they state to secure OSS consumption at scale without the centralization approach advocated for in other guidance we have covered. For organizations advocating for or taking a more decentralized approach, this thought process should resonate.
S2C2F itself is a combination of tools and requirements across a capability maturity roadmap focused on secure OSS ingestion through governance. The S2C2F guidance discusses common OSS supply chain threats, including covering not just the threats but also real-world examples of the attacks occurring and then maps them to specific S2C2F requirements.
Examples S2C2F provides range from accident vulnerabilities in OSS code or containers to intentional backdoors and malicious activity in repositories and packages. The guidance draws from sources such as Google’s Software Supply Chain Threats and Attack Vectors, which addresses threats from Source, Build, Deployment/Runtime and Dependencies
The threats listed also include more benign sources such as OSS components that have reached end-of-life and are no longer addressing vulnerabilities or maintainers simply failing to address vulnerabilities in a desired timeframe by consumers.
Secure Supply Chain Consumption Framework Practices
As mentioned, S2C2F includes a set of solution and vendor agnostic practices that can help organizations secure their OSS supply chain usage. Leaders such as compliance, security, and engineering managers as well as CISO’s can reference these practices to identify gaps in their organizations secure OSS usage and governance. Let's step through these practices to understand what they entail.
The first practice cited is Ingestion. As the guidance points out the first step of securing a software supply chain is controlling artifact inputs. This includes packaged and source code artifacts. The practice here is aimed at enabling organizations to ship assets despite external OSS sources being either compromised or unavailable. Packaged artifacts include things such as Linux package repositories or OCI registries and organizations need to proxy those external sources and save copies of what is required.
On the source code artifact front, the practice advocates mirroring external source code repositories internally and caching packages locally lets organizations continue to operate in situations, demonstrating business continuity. It also allows organizations to conduct security scans and even contribute fixes back upstream or fix the code locally in situations where this was desired rather than contributing back upstream.
After Ingestion, the next practice is Scanning, with the goal ensuring the consuming organization and individuals have visibility on vulnerabilities associated with the OSS component. As the guidance points out, trust is built through getting visibility into the security posture of the component being consumed. By scanning the ingested OSS component, the organization can identify misconfigurations, vulnerable code, known vulnerabilities or extraneous code that can increase the potential attack surface. There are plenty of OSS and proprietary scanning tools organizations can use to meet this practice.
Once an organization has ingested and scanned an OSS component, they need to inventory it so that they understand where their OSS components exist in production environments. A perfect example, as the guidance uses is the Log4J incident. Organizations who had accurate OSS component inventories were far better equipped to respond to the incident than organizations who lacked this inventory. As other critical vulnerabilities emerge in OSS components, organizations with inventories can quickly respond by remediating or triaging the vulnerable or compromised components and systems.
Having scanned and inventoried ingested components is a great start, but as we all know, software ages like milk. This means there will inevitably be a need to update and patch components that are in production environments. The next practice of course is having the capability to update components as needed. It is well known that when a vulnerability gets publicly disclosed, it is often a race between an organization's ability to patch or remediate the vulnerability and a malicious actor's ability to exploit it. For this reason, the practice of updating and patching vulnerable components at scale across the enterprises OSS footprint is critical.
Having a standardized process around OSS ingestion and use is one thing but you must inevitably be able to audit your environments to identify components that deviated from the process or pose a risk to the organization. Therefore, the next practice in the guidance is auditing. This means organizations can audit their OSS components and validate that they have gone through their standardized process of ingestion, scanning and inventory, otherwise governance starts to fall apart.
While auditing is great, organizations need to be able to do something about ungoverned OSS components that are discovered. Therefore Enforcement is the next practice in the guidance. If a developer bypass established processes and introduces ungoverned OSS components from untrusted sources, organizations must be able to remediate this deviation. The example the guidance provides is the enforcement of rerouting DNS traffic or establishing gates in the build process to break builds if unverified OSS components are introduced.
Increasingly, malicious actors make attempts to compromise the build process or infrastructure to lead to compromised binaries and artifacts. Next up in the guidance is the practice of being able to rebuild every OSS artifact being deployed from source code. This can be key is malicious actors have been able to insert a malicious OSS package with a backdoor or make unauthorized changes to generated binaries during the build.
The guidance emphasizes that for key artifacts or business critical high value assets, it may be necessary to create a chain of custody from the original source code for every single artifact used to create a production service or version of an application. This practice is focused on enabling developers who have that dependency on key OSS components to ingest the source code, rebuild it, modify it if needed such as by signing and cache the rebuilt artifact for internal use.
This practice points directly to Reproducible Builds, which are practices in software development for creating an independently verifiable path from source to binary code. This leads to bit-by-bit identical copies of all relevant artifacts. You’ll notice this practice is prevalent in other emerging guidance, such as SLSA, particularly for higher levels of maturity.
The final practice in the S2C2F is being able to fix issues and be able to contribute back upstream. The statement the guide makes is that “I can privately patch, build and deploy any external artifact within 3 days of harm notification and confidentially contribute the fix to the upstream maintainer”.
This is a very mature practice because it switches the onus from strict dependence on the maintainer and puts the software consumer in a position to not just be a user but an active contributor to an OSS project or component. This is exactly the type of behavior advocated for by researchers that we have touched on in other research such as the research by Chinamyi Sharma titled “A Tragedy of the Digital Commons.”
That said, the guidance states this is only for extreme scenarios and temporary risk mitigate when an upstream maintainer is not able to provide the public fix within the acceptable window of risk for your organization. This comes across as a recognition of allowing the maintainer to take the appropriate action but also being willing to help when appropriate, which is the ethos of the OSS community. The S2C2F guidance also advocates several ways organizations can contribute to the OSS community such as financial support directly or through foundations, participating in bounty programs, advocating best practices and being an active participate in key OSS projects.
S2C2F Implementation Guide
Similar to other frameworks such as SLSA, S2C2F is oriented around 4 levels of maturity. These go from Minimum OSS Governance all the way to Advanced Threat Defense, each with their own associated activities.
Level 1 includes basic activities such as caching packages internally, doing basic inventory and fundamental scanning and updating of OSS in your environment. Level 2 builds on that by driving down meantime-to-recovery (MTTR) for patching vulnerable components and performing incident response. Level 3 involved creating a deny list of known malicious or untrusted components and sources and scanning for malware present in the OSS components and enforcing provenance as previously discussed. Lastly, Level 4 is considered aspiration per the guidance, meaning it is a level of maturity that most organizations won’t meet, with the exceptions of the most mature, resourced, and sensitive organizations in the industry. Activities at this level include rebuilding OSS on trusted build infrastructure and creating and digitally signing SBOM’s for the rebuilt OSS components.
While these clearly lay out the 4 levels of maturity and associated capabilities or requirements, organizations need to understand how to approach assessing themselves or others against the levels laid out. The S2C2F guidance provides two high-level steps, which are preparing for the assessment and then actually performing it. Preparing involves ensuring the organization is comfortable engaging the development and engineering teams to inquire about the tooling, capabilities, and workflows the guidance discusses. The guidance goes on to provide a series of example questions that can be used as part of an assessment. These involve understanding how OSS is consumed currently in projects, where it comes from, as well as existing governance and security practices as discussed in the preceding core concepts, goals, and levels of maturity of the framework.
After an assessment has occurred organizations should have a better understanding of their current maturity level across the capabilities and practices the framework recommends. This empowers organizations to plan for improvements to address deficiencies or areas of weakness that were discovered during the assessment process. Organizations can make targeted investments and initiatives to improve capabilities and practices that they deem the most critical based on their respective goals and risk tolerance.
The S2C2F guide lays out the framework's requirements across a matrices table that includes the Practice, Requirement ID, Maturity Level, Requirement Title, and the associated Benefit to the organization for implementing the practice. Knowing that tooling is a core component is meeting the various requirements and maturity levels the guidance also provides tooling availability and recommendations. These include both existing free tools, tools from Microsoft and proposed planned tools that Microsoft is also working on.
The S2C2F guide is a welcome addition to the dialogue on supply chain security and the contribution of the framework by Microsoft to OpenSSF shows Microsoft’s commitment to the OSS community and helping the industry tackle this problem.