Maturity model implementation guide
The following maturity model allows an organization to make incremental progress from their existing set of security capabilities toward a more secure defensive posture against Open Source Software (OSS) Supply Chain threats. Additionally, the maturity model takes into account different threats and themes at each Maturity Level.
Security levels
The maturity model is split into 4 levels. As level increases, so does your organization's security posture against OSS threats. Below is a description of each level and some examples of policies implemented at each level.
| Level | Theme for each Maturity Level | Example OSS SSC Framework Requirement |
|---|---|---|
| 1 |
Minimum OSS Governance Program |
Inventory + Scan for OSS vulnerabilities |
| 2 |
Shifting further left to achieve strong OSS Governance Program |
Automated OSS patching to improve vulnerability MTTR |
| 3 |
Proactive Security Review and malware Analysis to address Supply Chain Threats |
OSS malware scans and proactive code analysis to detect backdoors and zero-day threats |
| 4 |
Addressing threats from the most sophisticated adversaries |
Rebuilding OSS on trusted build infrastructure |
Objective
Each security level has a set of requirements for fulfillment. Below is a table of requirements to secure your organization against OSS threats. For the highest levels of confidence and trust against OSS threats, all of the listed requirements should be implemented to reach Level 4. Getting to Level 3 should be the objective for framework adoption; Level 4 should be considered an aspirational North Star. To learn more about each requirement, how to implement them, and what threats they protect against, please use the links at the bottom of this page.
| Requirement description | Framework Requirement ID | L1 | L2 | L3 | L4 |
|---|---|---|---|---|---|
| Use package managers |
ING-1 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
✓Checkmark |
| Local copy of artifact |
ING-2 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
✓Checkmark |
| Scan for known vulnerabilities |
SCA-1 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
✓Checkmark |
| Scan for software licenses |
SCA-2 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
✓Checkmark |
| Inventory OSS |
INV-1 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
✓Checkmark |
| Manual OSS Updates |
UPD-1 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
✓Checkmark |
| Scan for end of life |
SCA-3 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
|
| Have an incident response plan |
INV-2 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
|
| Auto OSS updates |
UPD-2 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
|
| Display vulnerabilities as comments in pull requests |
UPD-3 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
|
| Audit that developers are consuming OSS through the approved ingestion method |
AUD-2 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
|
| Validate integrity of consumed OSS |
AUD-3 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
|
| Secure package source file configuration |
ENF-1 |
✓Checkmark |
✓Checkmark |
✓Checkmark |
|
| Deny list capability |
ING-3 |
✓Checkmark |
✓Checkmark |
||
| Clone OSS source code |
ING-4 |
✓Checkmark |
✓Checkmark |
||
| Scan for malware |
SCA-4 |
✓Checkmark |
✓Checkmark |
||
| Proactive security reviews |
SCA-5 |
✓Checkmark |
✓Checkmark |
||
| Enforce OSS provenance |
AUD-1 |
✓Checkmark |
✓Checkmark |
||
| Enforce consumption from curated feed |
ENF-2 |
✓Checkmark |
✓Checkmark |
||
| Validate the SBOMs of OSS consumed |
AUD-4 |
✓Checkmark |
|||
| Rebuild OSS on trusted infrastructure |
REB-1 |
✓Checkmark |
|||
| Digitally sign rebuilt OSS |
REB-2 |
✓Checkmark |
|||
| Generate SBOMs for rebuilt OSS |
REB-3 |
✓Checkmark |
|||
| Digitally sign produced SBOMs |
REB-4 |
✓Checkmark |
|||
| Implement fixes |
PRI-1 |
✓Checkmark |