The Secure Supply Chain Consumption Framework (S2C2F) from the Open Source Security Foundation (OpenSSF) is a useful resource for enterprise software teams addressing risks from open-source dependencies.
The framework provides a structured list of guidelines and best practices to protect development organizations from consuming vulnerable and compromised open-source software (OSS) components. It enumerates real-world open-source risks and recommends processes for identifying, evaluating, and monitoring them throughout the software development lifecycle (SDLC).
Microsoft developed the framework and used it for several years before turning it over to the OpenSSF to manage. Here's what you need to know about the S2C2F's strength in mapping out OSS risk. But there is one key caveat: Remediation of OSS risk is left to organizations to work out.
[ Special Report: The State of Software Supply Chain Security (SSCS) 2024 | Download Report: State of SSCS ]
8 focus areas and 4 maturity levels are key
The recommendations are built around eight focus areas: ingest, inventory, update, enforce, audit, scan, rebuild, and fix+upstream. The S2C2F spells out requirements for each of the focus areas that organizations can implement to improve security processes in that area. The requirements, which range from the basic to the aspirational, are organized into four maturity levels.
By using the eight practices and four levels of the S2C2F, organizations have a road map to tell them where they are now and where they need to go. Matt Rose, field CISO at ReversingLabs, said the practices are a clear and concise explanation of where to do certain activities with OSS workflows to mitigate risks
"It is basically like having Google Maps for mitigation of OSS threats. Without it, there is a ton of confusion on what to do when and where."
—Matt Rose
S2C2F and SLSA work hand in hand
The S2C2F is primarily consumer-focused, unlike another framework for open-source security, Secure Software Supply Chain Levels for Artifacts (SLSA), which is focused primarily on software producers. The two, however, are complementary. While SLSA focuses on progressive levels of security for artifacts such as source code, the S2C2F recommends best practices for OSS consumers to address risks. OpenSSF noted last year about the collaborative work:
"One of its primary strengths, and why we were so excited to adopt it into the OpenSSF, is how well it pairs with any producer-focused framework such as SLSA. For example, S2C2F’s Level 3 requirement for provenance of all dependency artifacts can be achieved through generated artifact provenance in such a manner deemed trustworthy through SLSA."
S2C2F enables an incremental approach
Because each S2C2F requirement maps to a specific maturity level, organizations have an opportunity to take an incremental approach to securing their open-source supply chain. For instance, requirements for Level 1 on the S2C2F scale include the ability for organizations to use package managers to automate the tracking and updating of open-source components, to maintain an inventory of their open software, and to scan them for vulnerabilities.
Organizations at Level 2 of the S2C2F maturity scale have technology for improving mean time to vulnerability remediation. At Level 3, the focus is on preventive controls and proactive code analysis to reduce risk from compromised or malicious open-source software. Organizations at the highest S2C2F maturity level (Level 4) have controls that can help mitigate against the most sophisticated attacks.
As the OpenSSF describes it, Level 1 requirements are fundamentally basic and include practices that many organizations have already implemented, while Level 4 requirements are challenging to implement and likely aspirational for most organizations today.
Getting proactive with app sec is key
Callie Guenther, senior manager of cyberthreat research at cyber-risk monitoring firm Critical Start, said the S2C2F is designed to offer organizations a systematic approach to enhance the visibility of their open-source security posture.
"By emphasizing the importance of utilizing package managers and continuously inventorying OSS at its initial level, the framework provides a foundation for clear visibility into OSS components in use."
—Callie Guenther
As organizations progress through the levels, the S2C2F guides them to integrate more proactive security measures such as verifying the provenance of dependency artifacts, which can enable deeper insights into the origin and integrity of OSS components, Guenther said.
The inclusion of requirements to bolster mean time to remediate vulnerabilities ensures that organizations can react swiftly to emerging security threats, Guenther said. Other requirements at the higher maturity levels — such as those focused on prevention and proactive risk analysis — mitigate against accidental consumption of malicious and compromised OSS components.
"This proactive stance ensures security checks are ingrained in the workflow even before OSS consumption takes place. For projects of paramount importance, Level 4 ushers in advanced controls that serve to protect against sophisticated adversaries."
—Callie Guenther
John Gallagher, vice president of Viakoo Labs, said that with the S2C2F, the OpenSSF has given organizations a comprehensive framework to assess their maturity when it comes to open-source software. Having a maturity-model approach is critically important, especially when different parts of the organization are at different levels of maturity with open-source software, he said.
"A good example of this is with how organizations may be at a high level of maturity with their core IT systems, but are relatively immature when it comes to IoT security."
—John Gallagher
Why software integrity verification matters
As with all frameworks, development organizations need to implement the S2C2F in a manner that is consistent with how they consume open-source components and how they develop applications, ReversingLabs' Rose said.
"S2C2F is a great way for organizations to initiate a threat-based risk-reduction approach. However, it is just a framework to base your program on. It does not actually do the scanning or remediation of the threats. So more granular tooling is also needed."
—Matt Rose
There's also the issue of verifying that software built with open-source components behaves in the manner intended. This is especially important when performing supplier and third-party assessments. Organizations cannot rely on a software producer's assurance that its software is secure; binary analysis of the actual software deployable is very important for commercial and third-party software assessments, Rose said.
"That's because when you analyze a binary, you get a view of the entire application and not just a piece of the application. Binary code analysis is basically the final exam for all your software development processes, to ensure that the software you are developing is free from threats."
—Matt Rose
John Bambenek, principal threat hunter at Netenrich, said context is important for organizations evaluating the S2C2F. At present, the framework remains an early-stage effort. It provides guidance and principles to organizations looking to address their third-party open-source supply chain risks, but that's not a comprehensive approach.
"It’s built around eight practices and drives requirements from there. Therefore, it remains a little high-level for most organizations that can’t fill in the blanks on their own."
—John Bambenek
