Securing the Software Supply Chain

Introduction

In 2018, the Software Bill Of Materials (SBOM) emerged as one of the key building blocks toward the security of the supply chain in software development. An SBOM is essentially a structured list of software components that make up a software product^[1][2][3]. Last year (2021), it became a requirement for federal contractors in the US, following Executive Order (EO) 14028^[4]. This EO has also driven a number of other initiatives, including from NIST and CISA, to provide guidance around source code analysis and integrity, increase visibility and SBOM generation, the hardening of DevOps platforms, etc.

There is, indeed, increasing demand for software transparency in supply chain security, especially in the wake of high-profile cyber attacks targeting the supply chain^[5][6]. According to Revenera^[7], 80% or more of the components in a single software application do not originate from the vendor selling the software. In reality, the supply chains of most organizations have grown so large, and are likely to change over time, the exact figures might even be unknown. Having an up-to-date and complete software assets inventory in place is still a major challenge for most organizations. In fact, beyond SBOMs, organizations also use many 3rd party applications to manage their security, CI/CD pipeline, analytics, sales, etc. According to Okta’s Business at Work 2022 report^[8], the average number of apps organizations deploy increased to 89 this year (an increase of 24% since 2016). Larger companies (2K+ employees or more) deploy even more apps; 187 on average. Best practices and security considerations should also expand to these applications, many of which are part of the software lifecycle and contribute to the organization’s attack surface and cyber exposure.

Supply chain threats

Reducing the cyber exposure associated with the supply chain requires good visibility into the components that make up the software, as well as those that manage its pipelines, especially in DevOps. Figure 1^[9], shows example threats spanning the CI/CD pipeline, where most of the tooling would originate from outside the organization itself.

Some of the threats shown in Figure 1, at the build stage, are linked to using untrusted sources or compromised dependencies. These have shown to be some of the most common attack vectors in recent supply chain attacks ^[10]. For IT and security teams, it is important to be aware of these threats, to begin with. In fact, an SBOM by itself doesn’t prevent untrusted dependencies, but it can be incorporated into an organization's dependency management process that would include integrity checks or the storage of trusted copies in private artifact stores for instance.

Threat modeling is the process of identifying and addressing cyber security threats at the design level and accounting for mitigation measures that will help reduce the associated risk. Reliable inventories and the monitoring of threats at this stage will significantly increase development efficiencies and decrease security issues down the road.

Figure 1. Software supply chain threats (from the Google Cloud team)^[9].

Figure 2. OWASP Top 10 CI/CD security risks^[11].

Securing the supply chain also means securing your CI/CD infrastructure. If a software vendor’s development process is breached, and malicious code implanted, that will propagate and penetrate deep into their customers' infrastructure. That’s what happened in the SolarWinds hack^[5]. The OWASP top 10 CI/CD security risks^[11] (Figure 2) helps defenders and threat modelers identify focus areas for securing their CI/CD ecosystem. Automated security tools and processes in emerging DevSecOps development practices^[12] are a good step toward securing CI/CD pipelines. However, threat modeling is necessary to include additional mitigations that cover abuses in access management, for instance, or the governance of 3rd party applications’ usage.

Stolen secrets, including digital certificates, also represent a major threat to the supply chain. Consider this: if a certificate, belonging to you or a partner, was to be compromised, security implications could be significant. An attacker can potentially authenticate as you or your partner, sign and distribute malicious code, or even use it to bypass inspection and protection systems. That’s what happened in the Mimecast certificate hack^[13]. Strong and mandatory IAM and code integrity policies must be followed to secure the build and update infrastructure.

Table 1. presents a few high-profile breaches and incidents, and associated supply chain threats. Properly securing supply chains is becoming increasingly urgent. The latest annual report from Sonatype^[24] reported an astonishing 742% average annual increase in software supply chain attacks over the past 3 years! In the next section, we will cover best practices and necessary controls to address threats and secure the supply chain.

Table 1. Example of known supply chain incidents and associated threats.

Threat

Known breaches/incidents

Compromise development platform

SolarWinds^[5]

Malicious artifact injection

Compromise dependencies

CodeCov^[6]

Compromise certificate/secrets

Mimecast^[13]

Compromise provenance of dependencies

Webmin^[18]
Submit malicious code to the source repo	Linux Kernel compromise incident known as “hypocrite commits”^[19]
Compromise source repo/server	PHP^[20]

Guidelines for supply chain security

A prerequisite for solving the supply chain security challenge is visibility, which includes being able to produce accurate and reliable SBOMs. The NTIA, which launched and led the community that established SBOM, publishes "The Minimum Elements For a Software Bill of Materials"^[14], defining “minimum elements” to be included in an SBOM. A list of everything else in your environment, especially apps interacting with your software lifecycle, will complement that. A well-run inventory tracking system is key here. Provided that an accurate list of components is available, threat modeling can be carried out and security best practices implemented at different levels, including for components and dependencies, as well as the DevOps platform and its data flow. Table 2 summarizes some of the existing guidelines and their coverage.

Table 2. Example supply chain security guidelines and their coverage.

Guideline/framework, or standard	Scope
Supply-chain Levels for Software Artifacts - SLSA^[15]	A framework for ensuring the integrity of artifacts throughout the software lifecycle. SLSA is organized into four levels providing each an increasing integrity coverage. The security requirements^[23] cover the source, build, and provenance, as well as general security requirements, including for access and privileges.
CIS Software Supply Chain Security Guide^[16]	A guide from CIS to help DevOps (and other stakeholders in the software lifecycle) secure their supply chain. It covers guidelines for the source code, build pipelines, dependencies & artifacts, as well as deployment.
NIST SP 800-161 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations^[17]	Describe the requirements and guidance for NIST's Cybersecurity Supply Chain Risk Management (C-SCRM) implementation. It covers foundational practices and requirements necessary to the success of a C-SCRM program, as well as security requirements and controls (using NIST SP 800-53, when it exists) with supplemental C-SCRM guidance and enhancements, and additional controls (e.g., supplier inventory).
ISO/IEC DIS 27036-3 - Guidelines for hardware, software, and services supply chain security^[21]	This part of ISO/IEC 27036 covers guidance on gaining visibility on the hardware and software supply chain, and the risk associated with the fragmentation in the hardware, software, and services lifecycles. It also covers the integration into the system and software lifecycle processes, as described in ISO/IEC 15288 and ISO/IEC 12207, as well as the support of security controls, as described in ISO/IEC 27002.
CISA’s “Securing the software supply chain guide”^[22]	The Cybersecurity and Infrastructure Security Agency (CISA) publishes recommended practices, specifically tailored for developers, to secure the software supply chain. It covers recommendations to secure code, verify dependencies, and harden build pipelines and code delivery.

Conclusion

Software supply chains are growing large and complex by the day, involving many third-party vendors and components that are absolutely in need of greater attention for both their visibility and security. In this article, we covered key aspects to effectively secure the supply chain, from SBOMs to guidelines and frameworks for security enhancement and hardening. We believe that threat modeling is the best way to operationalize these guidelines and frameworks and have a significant impact on the security posture of the system and software composing it.

References

‍