Microsoft announced that its Secure Supply Chain Consumption Framework (S2C2F) has been adopted by the Linux Foundation's Open Source Security Foundation (OpenSSF) in a move to improve "supply chain security for everyone," according to Microsoft Azure CTO Mark Russinovich.

The OpenSSF's adoption of the framework means "the community it serves can also now have a hand in growing and improving it," Microsoft's Principal Program Manager of Secure Software Supply Chain Adrian Diglio said.

The No. 2 cloud giant has been using S2C2F in its own open source software (OSS) development processes for the past three years, and as "a massive consumer of and contributor to open source, Microsoft understands the importance of a robust strategy around securing how developers consume and manage OSS dependencies when building software," Russinovich explained.

Diglio told SDxCentral that Microsoft will continue to lead the special interest group within OpenSSF dedicated to S2C2F, and the hyperscaler will collaborate with OpenSSF members and its community to maintain the framework. "We will also collaborate closely with the other OpenSSF Working Groups, such as End Users WG and Best Practices WG, as appropriate," Diglio said.

The consumption-focused framework, which was adopted under OpenSSF's Supply Chain Integrity Working Group, uses a threat-based, risk-reduction approach to mitigate real-world cyber threats. The framework identifies and lists supply chain threats that relate to OSS and explains how its requirements address potential threats.

"Consumption of open source software is one of the largest pieces of any development team’s or organization’s software supply chain," Diglio said, adding, "The S2C2F requirements provide clarity so that teams around the world can take action to improve the security for how they consume open source into the developer workflow."

S2C2F prioritizes platform- and software-agnostic focuses that fall into eight separate areas, each with its own set of requirements that will address threats and reduce risk. From there, the areas are categorized into four levels of maturity "so teams can prioritize and make incremental progress," Diglio said.

Level 1 includes common OSS knowledge and practices like scanning for known vulnerabilities and updating OSS dependencies, which are the minimum requirements for any OSS governance program, Russinovich noted. Level 2 includes additional technology to improve organizations' mean time to remediate (MTTR) OSS vulnerabilities that aims to patch quicker than threat actors can attack.

Level 3 targets proactive security analysis together with preventative controls to prevent "accidental consumption of compromised or malicious OSS," and Level 4 focuses on controls to defend against sophisticated attacks, which are typically the most challenging to deploy at scale. "Therefore, these should be considered aspirational and reserved for your dependencies in your most critical projects," he explained.

This framework allows teams to efficiently prioritize their OSS security based on the appropriate level of maturity. "The ability to target a specific level of compliance within the framework means teams can make intentional and incremental progress toward reducing their supply chain risk," Russinovich said.

S2C2F also "pairs well with any producer-focused framework" like Google’s Supply chain Levels for Software Artifacts (SLSA) project, Russinovich noted. Project SLSA is a framework for ensuring the integrity of software artifacts throughout the software supply chain, and it's a major project within OpenSSF.

Initially launched in June of last year, Project SLSA allows companies to audit the supply chain within internal workflows by using a system of incremental levels, each with an increasing amount of trustworthiness. Only secure and untampered-with artifacts reach the fourth and highest level. These artifacts can be securely traced back to their source, providing a sense of confidence for consumers.

In a blog post about SLSA, Kim Lewandowski of Google’s open source security team laid out eight different threats — for example, a compromised build platform like with the SolarWinds breach — and how SLSA’s framework might have prevented them, or at least made them more difficult for attackers to exploit. “In its final form, SLSA will differ from a list of best practices in its enforceability. It will support the automatic creation of auditable metadata that can be fed into policy engines to give ‘SLSA certification’ to a particular package or build platform,” the blog explains.

"With S2C2F complementing SLSA, together they provide a complete guide for how to approach building and consuming software securely," Diglio added.