What Is Supply Chain Compliance?
The software supply chain includes code, libraries, configurations, open source and proprietary binaries, container dependencies, and plugins which are integrated into a software project. It also includes development tooling, such as build servers, assemblers, compilers, source code repositories, security tools, and log analysis tools. Perhaps the most important part of the software supply chain is the organizations, processes, and people involved in software development projects.
This increasingly interconnected, large, and complex system of people, technologies, and process interfaces gives rise to many attack vectors. Malicious individuals can use any of these touchpoints to break into the software supply chain. Proprietary code, even software composed of third-party tools and open source libraries, can be used to inject malicious code, exploit code vulnerabilities, obfuscate package dependencies, hijack software updates, and subvert code signing processes.
Many regulations and industry standards now explicitly address supply chain security, and provide specific security requirements for companies. Many standards require that organizations make use of software bills of materials (SBOMs) that describe what is included in the supply chain for a specific software product.
In general, compliance standards increasingly require organizations to add supply chain security into their supply chain management processes. This means careful risk management for external vendors, logistics and transportation. The goal is to identify, analyze and mitigate risks inherent in supply chains in order to meet compliance requirements and prevent supply chain attacks.
This is part of a series of article about supply chain security
In this article:
4 Software Supply Chain Security Standards
The Center for Internet Security (CIS) is a non-profit organization focused on improving cybersecurity preparedness and response in the public and private sectors.
CIS joined forces with Aqua Security to create software supply chain guidelines.
DevOps teams, application security managers, security experts, help desks, auditors, and planners can use it to develop, deploy, evaluate, and secure solutions for automated software updates in DevOps pipelines.
These guidelines were developed using a consensus-based review process, via a global community of specialist experts. This process combines in-the-wild experience with threat databases to produce technology-specific guidelines to help protect your environment. Consensus participants bring perspectives from a variety of backgrounds including software development, consulting, auditing and compliance, operations, security research, government, and law.
Supply Chain Levels for Software Artifacts (SLSA—pronounced salsa) is a security framework including standards and control lists that can help prevent tampering, ensure integrity, and protect the infrastructure and packages of a software project. The goal is to ensure every link in the supply chain enjoys the maximum resilience and security.
SLSA provides four levels of implementation for organizations:
- Level 1: Easy to deploy, provides supply chain visibility and can create provenance for supply chains.
- Level 2: Adds software tamper protection and minimum build integrity guarantees.
- Level 3: Hardens infrastructure against attacks and improves reliability for complex system integration.
- Level 4: Provides the best guarantee of build integrity and dependency management.
The National Institute of Standards and Technology (NIST) has released the Secure Software Development Framework (SSDF) 1.1. It describes several best practices that organizations and third-party vendors should follow, to achieve tighter control over the software development lifecycle.
SSDF mainly focuses on how an organization can secure the software supply chain regardless of platform, technology, operating environment, or programming language, by implementing security throughout the DevOps process.
It provides four primary strategies:
- Prepare your organization for supply chain attacks
- Protect all software components against tampering and unauthorized access
- Create sufficiently secure software by addressing security gaps in software releases.
- Scan for and remediate vulnerabilities.
The Supply Chain Integrity, Transparency, and Trust (SCITT) initiative is a proposed set of Internet Engineering Task Force (IETF) industry standards for managing compliance of goods and services in an end-to-end supply chain.
SCITT ensures the authenticity of entities, evidence, policies, and artifacts through continuous verification of goods and services, and ensures that the work of different entities in the supply chain is authoritative, undeniable, tamper-proof, and auditable. It provides detailed information about dependencies in a variety of formats, both structured and unstructured. SCITT uses the concept of a claim—a well-formed statement with evidence backed by a verifiable entity.
Auditing the Software Supply Chain to Ensure CIS Compliance
As the creator and a key contributor to this comprehensive and much-needed guide, Aqua aims to help DevOps teams and the wider cloud-native community adopt it. Aqua built Chain-bench, the first open-source tool for auditing software supply chains against CIS recommendations. This makes it easier to meet organizational requirements and set up secure configuration mechanisms.
Aqua’s open-source tools are based on standards defined as best practices by the CIS Software Supply Chain Guidelines. These security recommendations are divided into five sections covering all aspects of the software supply chain.
- Source code: As the first step in the software supply chain, the source code is the origin of information for the entire process. Undetected vulnerabilities, misconfigurations, and exposed data specific to the supply chain can lead to scenarios where you need to protect your own source code.
- Build pipelines: A set of instructions for performing actions on raw source code, to produce a final artifact. You should review your build pipeline and implement security recommendations for your build components. This includes the operating environment, execution, management, and more.
- Dependencies: These exist by default at almost every stage of software supply chain development. Because they are often written by third-party developers, unresolved dependencies can make them vulnerable. The Log4j attack is a classic example of how dependencies can compromise even the most popular products.
- Artifacts: Building the artifacts generated by the pipeline is another weak link of supply chains. To prevent compromised iterations from being incorporated into the supply chain ecosystem, they must be protected from the moment they are created.
- Deployment: To protect customers already using the application in production, it is necessary to secure application deployment, configurations, and files delivered to the end user.