Supply Chain Security Framework: S2C2F

The Oxford Dictionary defines a supply chain as:

"the series of processes involved in the production and supply of goods, from when they are first made, grown, etc. until they are bought or used."

This definition also applies to the digital supply chain, i.e. the supply chain that concerns digital artifacts (the present article applies to this specific form of supply chain).

Supply chain security refers to all the activities and controls that aim to enhance the security of the supply chain (a.k.a. value chain).

Supply chain security is a hot topic at the moment, and rightly so.
Statistics show an increasing number of attacks on the value chain, and the projections for the coming months/years are not rosy.
Gartner predicts that by 2025, 45% of organizations will have experienced a software supply chain attack.

It, therefore, becomes essential to have an all-encompassing frame of reference, a coordinate system that can guide us through misty waters and help us identify the crucial points of our value chain and the ways in which we can secure them.
In this regard, various institutions, both public and private, are putting considerable effort into the development of these frameworks.

In this article, the SIGHUP DevSecOps and Cloud Security team wants to introduce you to S2C2F (Secure Supply Chain Consumption Framework), a relatively new effort made by the open-source security foundation in collaboration with Microsoft.

The S2C2F Framework

The S2C2F Framework is a combination of requirements and tools for any organization to adopt.
It mainly focuses on how to securely consume and manage open source dependencies.

Using a threat-based risk-reduction approach, the goals of the S2C2F are to:

1. Provide a strong OSS governance program.
2. Improve the Mean Time To Remediate (MTTR) for resolving known vulnerabilities in OSS.
3. Prevent the consumption of compromised and malicious OSS packages.

The framework is modeled after three core concepts — control of all artifact inputs, continuous process improvement, and scale:

• Control All Artifact Inputs: 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.
• Continuous Process Improvement: This helps organizations prioritize which requirements they should implement first. Since security risk is dynamic and new threats can emerge at any time, the S2C2F places heavy emphasis on understanding the new threats to the OSS supply chain and requires regular evaluation of S2C2F controls and introduction of changes in response to new technology advancements or new threats.
• Scale: The S2C2F tools were designed with scale in mind. 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 requires 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.

These three concepts can be put into action with the following 8 best practices:

A maturity model has been designed to categorize the requirements from the 8 different practices into four distinct levels, as it is not feasible to implement all eight practices simultaneously.
Through the maturity model, organizations can gradually progress from their current level of security capabilities to a more secure defensive position.
The model also takes into account various threats and themes at each maturity level. It is possible to have a mix of framework levels implemented across different projects, and while Level 4 is an aspirational vision for organizations due to its high cost, it is achievable for critical dependencies and projects. Nevertheless, implementing Level 4 across the entire organization at scale may prove challenging.

Level 1 involves using a package caching solution, performing an inventory of OSS, and scanning and updating OSS to improve security.
Level 2 focuses on shifting security further left by improving configuration security, decreasing patch response time, and automating OSS maintenance.
Level 3 proactively performs security analysis on the organization's most used OSS to reduce risk and prevent compromise.
Level 4 is considered aspirational and involves rebuilding OSS on trusted build infrastructure to defend against the most sophisticated adversaries and implement fixes at scale.

Conclusions

In summary, the main conceptual points to internalize are:

• Acquire as much ownership as possible of all input artifacts.
• Put in place a proper inventory of all artifacts and dependencies.
• Continuous assessment of possible vulnerabilities in the artifacts.
• Continuous update of artifacts when new versions are released.

We strongly believe that companies will be led by circumstances to devote ever greater attention to the security of their flows, and this often involves a cultural and technological change in how things are done.
Adopting state-of-the-art security frameworks, with the shift left paradigm at their core, has proven to be a cornerstone of modern SecOps and will continue to be vital to the resilience of our supply chains.

If you want to go deeper, and we strongly recommend you do, you can find the official documentation in this GitHub repo.