In the first part of this series, we dived into the SLSA framework to understand where supply chain security is headed; in the second part, we did a tutorial on sigstore/cosign about signing and verifying the integrity and origin of software artifacts.
If you haven't read them yet, here are the links for you:
Today, we will talk about more software supply chain security frameworks and the role of secret detection in them.
With the increasing complexity and interconnectedness of software supply chains, it is becoming more and more challenging for organizations to identify and mitigate potential risks.
To provide a comprehensive set of guidelines, best practices, and standards that can help organizations establish a more secure and resilient software supply chain, there emerged many frameworks, for example:
NIST
SLSA
OSC&R
By providing a structured approach to risk assessment, mitigation, and management, software supply chain security frameworks are crucial for organizations to navigate the many aspects of risk assessment, evaluate mitigation priorities, allocate resources more effectively, reduce the likelihood and impact of supply chain attacks, protect critical assets and information, and ensure the security and integrity of their operations.
One of the most important aspects (if not the most important) of supply chain security is secrets protection. Secrets refer to sensitive information such as passwords, API keys, and certificates used to access and authenticate access to critical systems and data. Inside modern supply chains, they are omnipresent.
Secrets need to be distributed along the supply chain and stored in multiple components or links, and if their management is unhealthy, they are the perfect prey for attackers. That is why secret management is essential to software supply chain security, and most of these software supply chain security frameworks cover this topic.
Let's review framework recommendations when it comes to secrets and secrets detection.
2. NIST Secure Software Development Framework (SSDF)
2.1 Intro
Designed to help software developers and organizations improve the security of their software throughout the entire Software Development Life Cycle (SDLC), the Secure Software Development Framework (SSDF) is a publication by the National Institute of Standards and Technology (NIST), providing a comprehensive set of guidelines, best practices, and standards for developing secure software.
SSDF is divided into four groups:
Prepare the Organization (PO)
Protect the Software (PS)
Produce Well-Secured Software (PW)
Respond to Vulnerabilities (RV)
For a detailed introduction and key highlights of the SSDF, please read this blog.
In each group, the SSDF includes a set of security controls and practices that can be implemented to ensure that software is developed with security in mind and that potential vulnerabilities and threats are identified and mitigated.
2.2 The Role of Secrets Detection in SSDF
SSDF suggests defining both coding practices and security tools.
In the group "Produce Well-Secured Software (PW)," Practice 5 (PW.5) mentioned "create source code by adhering to secure coding practices," for example: validate inputs, avoid using unsafe functions and calls, etc. And if there is the most critical practice, it's "do not store hardcoded secrets in the source code."
Clearly, defining the security coding practices helps to produce well-secured software. But how to enforce and verify these? Maybe tools and automation are the answer: in the group "Prepare the Organization (PO)," Practice 3 (PO.3) mentioned, "implement supporting toolchains: use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC."
In addition to the tools, finding violations of coding practices is easier than ever. SSDF Taksk 3.1 (PO.3.1) suggests specifying which tools or tool types must or should be included in each toolchain to mitigate identified risks and how the toolchain components are to be integrated. A well-defined secrets detection mechanism and its integration with other tools are excellent ideas and easy ways to detect coding practice violations.
2.3 NIST Guidelines on Secrets and Testing
It's worth mentioning that the NIST has another security guideline focused on one of the most important stages of the SDLC: testing. The Guidelines on Minimum Standards for Developer Verification of Software was developed by NIST in consultation with the National Security Agency (NSA) in search of defining minimum testing standards.
The document does not address the totality of software verification but instead recommends broadly applicable techniques that form the minimum standards. For example, one of the recommendations is "review for hardcoded secrets" (section 2.4):
We recommend using heuristic tools to examine the code for hardcoded passwords and private encryption keys. Such tools are feasible since functions or services taking these as parameters have specific interfaces. Dynamic testing is unlikely to uncover such unwanted code.
To learn more about hardcoded secrets, read this blog: Wake-up call: why it's urgent to deal with your hardcoded secrets.
3. SLSA
3.1 Intro
With a different approach, the Supply Chain Levels for Software Artifacts (SLSA) framework defines four security levels, which are incremental and actionable milestones corresponding to integrity guarantees.
The SLSA (pronounced /salsa/) framework, which stands for Supply-chain Levels for Software Artifacts, is a comprehensive and evolving security framework designed to tackle security challenges in the software supply chain by improving integrity and security.
Developed by industry experts and open-source contributors, SLSA establishes progressive security requirements and best practices for each stage of the software supply chain.
These requirements are organized into four levels, each building on the previous one, to provide increased security assurance. Responsibility is split between the Producer and Build system to produce artifacts with a specific build level. The build system must strengthen the security controls to achieve a particular level. At the same time, the producer must choose and adopt a build system capable of achieving a desired build level, implementing any controls as specified by the chosen system.
By achieving a certain SLSA level, organizations can demonstrate their commitment to following rigorous security practices that help prevent supply chain attacks and protect their infrastructure and end-users. Read more here.
3.2 The Role of Secrets in SLSA
There are a few requirements to reach L3 of SLSA, and many are related to the secure storage of secrets. For example:
In one of the requirements, "isolated": the build system must guarantee that it is impossible for a build to access any secrets of the build service.
In another requirement, "provenance is unforgeable," it's required that any secret material used for authenticating the provenance must be stored in a secure management system appropriate for such material and accessible only to the build service account.
While the framework doesn't include any definition of what constitutes a secure system, SLSA explicitly requires all implementations to use "industry security best practices." This includes:
proper access controls
securing communications
proper management of cryptographic secrets
frequent updates
promptly fix known vulnerabilities
Take the "provenance is unforgeable" requirement above as an example again; you'd have to have a proper method to manage your secrets to satisfy the requirement to secure secrets appropriately.
4. OSC&R
4.1 Intro
With the entire software supply chain being increasingly targeted by threat actors, there emerged the need for a MITRE ATT&CK-like security framework that would allow experts to establish a common language and structure for understanding and analyzing techniques, tactics, and procedures (TTPs) used by adversaries.
This is the goal of the Open Software Supply Chain Attack Reference (OSC&R), a MITRE-like framework covering containers, open-source software, secrets hygiene, and CI/CD posture.
Like MITRE ATT&CK (a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations), OSC&R is organized into a clear and structured view of the TTPs used by adversaries, and it's the first and only matrix that focuses specifically on the software supply chain attacks. It covers various attack vectors, including vulnerabilities in third-party libraries and components, supply chain attacks on build and deployment systems, and compromised or malicious software updates.
4.2 SLSA vs. OSC&R
At this point, you might be wondering about the difference between the SLSA mentioned above and OSC&R. Well, I guess you are because I am.
The main difference is that in its current version, SLSA is from the defender's perspective, while OSC&R is more from the attacker's standpoint (but, of course, their goals are to increase software supply chain security).
SLSA: in its current incarnation, is more of a set of guidelines and describes different levels of protection and compliance. "If you achieve this and that, your supply chain is more secure and less likely to be tampered with." It classifies different types of software artifacts in a supply chain based on their level of integrity.
OSC&R: on the other hand, describes attacker behaviors and techniques used to compromise the software supply chain so that you can better understand the situation and then generate some actionable TODOs.
Integrity in the context of SLSA refers to the assurance that the software artifact has not been tampered with or modified unauthorizedly and is in its original and intended state.
OSC&R provides insights into an attack's target and current phase, allowing teams to pinpoint the potential impacts, evaluate the effectiveness of existing protections and controls, and prioritize responses.
4.3 Secrets in OSC&R
Since OSC&R is from the attackers' viewpoint, we can better see what the attackers can do with secrets. For example, the attackers can:
scan public artifacts for secrets
scan configuration on public resources
scan public CI/CD configurations for secrets and vulnerable actions
dump credentials from files
steal credentials in container artifacts
Scanning source code, public artifacts, configuration files, and CI/CD systems for secrets are common tactics malicious actors use to uncover sensitive data. For example, infrastructure code might contain credentials to deploy the cloud, Docker images might contain files with hardcoded secrets, and CI/CD pipeline definition might include some secrets since CI/CD needs to do some actions like deploying something somewhere. Furthermore, hardcoded secrets can be accidentally leaked through various means. For example, if a container is compromised and the container image has a file containing credentials, the attackers could get access to the file directly.
Once these secrets are discovered, they can be exploited to gain unauthorized access to systems, data, or resources, leading to significant security breaches.
And that's why secrets detection plays a crucial role in mitigating the risks associated with hardcoded secrets. Secrets detection tools can scan for sensitive information in various locations, such as source code, configuration files, and CI/CD systems, allowing developers to remediate the issues before they can be exploited by attackers. By implementing robust secrets detection mechanisms, organizations can proactively identify and eliminate hardcoded secrets from their codebase, preventing attackers from exploiting the system and gaining access.
5. Summary
In the third and final part of the "supply chain security" miniseries, we looked at a few security frameworks and the role of secret detection in them.
As this blog has length limitations, I can only highlight a few of the security frameworks available. While there are several other noteworthy frameworks, such as Microsoft's S2C2F, which offers a solution-agnostic set of practices and a maturity model-based implementation guide, it's worth noting that some practices may overlook certain security measures. For instance, while the "scan it" practice emphasizes scanning for known vulnerabilities in OSS packages, it fails to mention the importance of scanning for secrets as well.
In conclusion, software supply chain security is becoming increasingly important as organizations rely more on interconnected systems and third-party providers. The frameworks and tools discussed in this series provide a valuable resource for organizations looking for guidance on how to harden their chains. By understanding the role of secrets in supply chain security and implementing detection and management practices, organizations can significantly reduce the likelihood and impact of an attack, protect their critical assets and data, and ensure the security and integrity of their operations.
If you enjoy reading this article, please subscribe. See you in the next one!