An organisation dedicated to improving open source security for its cross-industry participants has adopted a framework freely released by Microsoft, in a move welcomed by Azure CTO Mark Russinovich.
Microsoft has been using the Secure Supply Chain Consumption Framework (S2C2F) since 2019 to help ensure that developers are securely consuming and managing open source software at the company.
Redmond made it public over the summer and the S2C2F has now been adopted by OpenSSF.
Russinovich said that the open source software security framework “enumerates a list of real-world supply chain threats specific to OSS and explains how the framework’s requirements mitigate those threats.
“It also includes a high-level platform- and software-agnostic set of focuses.”
What is the S2C2F and is it useful for my organisation?
The Azure CTO describes the S2C2F as a “consumption-focused framework that uses a threat-based, risk-reduction approach to mitigate real-world threats” across the open source software supply chain.
The S2C2F is more straightforward and practical than it sounds.
It includes a guide to assess your organisation’s maturity when it comes to open source security. Reviewing it, The Stack found it a straightforward and highly practical guide that CIOs and CTOs may want to adopt.
“But ‘ahm not using that dangerous open source stuff!”
Open source supply chain security is a growing challenge for most IT leaders; even those who are under the illusion that they only buy world-class proprietary software from expensive providers. (We’ve met a few.)
(Looking closer they may find that they are running an open source database or two, or at bare minimum that their developers have built applications on a range of open source components or languages.)
The S2C2F framework is applicable to OSS dependencies consumed into a developer’s workflow.
That spans source code, language packages, modules, components, containers, libraries, or binaries.
Follow The Stack on LinkedIn today
As its authors note: “There are a myriad of ways that developers consume OSS today: git clone, wget, copy & pasted source, checking-in the binary into the repo, direct from public package managers, repackaging the OSS into a .zip, curl, apt-get, git submodule, and more.
“Securing the OSS supply chain in any organization is going to be near impossible if developer teams don’t follow a uniform process for consuming OSS. Enforcing an effective secure OSS supply chain strategy necessitates standardizing your OSS consumption process across the various developer teams throughout your organization, so all developers consume OSS using governed workflows” they add.
The S2C2F was designed with scale in mind.
As the framework notes: Some organizations may attempt to secure their OSS ingestion process through a central internal registry that all developers within the organization are supposed to pull from. However, what if one developer chooses to pull straight from pypi.org or npmjs.com? Is there anything preventing them from doing so? A central internal registry also has the problem of requiring a team to manage the process and workflow, which is extra overhead. As such, the S2C2F tools were developed to secure how they consume OSS today at scale without requiring a central internal registry or central governance body.”
Some of its guidance is basic but often overlooked by many.
That includes the requirement that all external open source code repositories used are mirrored to an internal location. Doing this, in addition to caching packages locally is also useful for many reasons, the framework says:
- Business Continuity and Disaster Recovery (BCDR) purposes, so that your organization can take ownership of code if a critical dependency is removed from the upstream
- Enables proactive security scans to look for backdoors and zero-day vulnerabilities
- Enables your organization to contribute fixes back upstream
- Enables your organization to perform fixes if needed (in extreme circumstances)
The framework also includes straightforward steps/pre-assessment guidance to get IT leaders comfortable engaging with developers and engineers to inquire about their existing tools, capabilities, and workflows.
Those mindful of improving open source security practises can find the S2C2F here.