Enhancing Software Supply-Chain Security: Navigating SLSA Standards and the MITRE ATT&CK Framework

By Magno Logan

Software supply-chain attacks have become one of the most exploited methods for compromising systems. These attacks are used to gain initial access to victims’ systems and allows adversaries to target a higher number of victims in a single instance, within a short period of time. In this case, contrary to the popular saying, ignorance is not bliss. Instead, to effectively prepare and secure their systems, organizations would benefit from recognizing pertinent components and the corresponding attacks that can be launched against them.

In this article, we will explore different supply-chain scenarios that attackers have leveraged to indirectly compromise organizations and their applications. We will correlate these scenarios, where applicable, with the Supply-chain Levels for Software Artifacts (SLSA) security frameworks and MITRE ATT&CK.

The SLSA specification is a critical end-to-end framework designed by Google to ensure the integrity of software artifacts throughout the supply chain. It is structured into progressive levels, with each level providing escalating security assurances.

The MITRE ATT&CK framework, on the other hand, is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations of the methods threat actors use in actual attacks.

Discerning how a software pipeline works and where the supply-chain risks might come from is crucial to understanding these attacks and the scenarios presented in this article. To do that, we need to make an analogy between a software supply chain and a traditional supply chain.

Traditional versus software supply chain

A traditional supply chain is a network of interconnected organizations, resources, activities, and technologies that produce, distribute, and deliver goods or services to end consumers. It encompasses all the steps required to bring a product or service from its initial raw material stage to the hands of the final consumer. The supply chain includes various stages, each contributing to transforming raw materials into finished products and their subsequent distribution. Depending on the product's nature and the supply chain's complexity, these stages might involve suppliers, manufacturers, distributors, retailers, and other intermediaries.

Figure 1. A diagram of a traditional supply chain alongside a software supply chain

Likewise, the software supply chain is a network of interconnected components, processes, and technologies that contribute to the creation and distribution of software. For example, as shown in Figure 1, a software supply chain typically involves developers, code, builds, package managers, container registries, and the created application. We examine in detail the processes involved in a software supply chain here.

In relation to these, the system entails various processes such as developing, testing, and delivering software products to end-users or customers. Organizations can achieve efficient, secure, and reliable software development and delivery processes by managing and optimizing the software supply-chain components and processes.

Real-World scenarios

Now that we have covered the basic concepts, standards, and frameworks, we may now analyze a few examples of highly relevant real-world scenarios that abused the software supply chain in different stages.

Figure 2. Software supply-chain threats according to SLSA in relation to the affected component

Table 1. Real-world scenarios of software supply-chain attacks according to SLSA

To dig deeper into actual attacks, we discuss the following examples from the Cloud Native Computing Foundation (CNCF) Supply Chain compromises list and expound on the prominent attacks listed in Table 1, including Codecov and SolarWinds.

• Codecov. Announced in April 2021, this is a code coverage tool for developers. Unfortunately, an unidentified hacker could access developers’ uploader script due to a mistake in their Docker image generation process. This flaw allowed the hacker to retrieve the required credentials and alter the Bash script.
• SolarWinds. The SolarWinds supply-chain attack was a sophisticated cyberattack where perpetrators inserted a malicious backdoor, SUNBURST, into SolarWinds' Orion software platform during the software's build process. This malicious code was then distributed to customers via routine software updates. Once installed and activated, the malware communicated with a server operated by the attackers, sending information about the infected systems. The attackers used this information to identify high-value targets, further infiltrating those systems by stealing credentials, escalating privileges, and exfiltrating data. The hackers effectively obfuscated their activities by blending into the network and mimicking legitimate traffic.
• PEAR PHP Package Manager. The PEAR package manager, a component of the PHP developer ecosystem, was compromised due to a password reset vulnerability and an unpatched, known CVE in a third-party dependency. Although Packagist has largely replaced PEAR, it remains influential in the PHP development community.
• Log4j. The Log4j remote code execution (RCE) vulnerability, aka Log4Shell, is a severe security flaw identified in the Java logging library, Log4j, which affected library versions up to 2.14.1. The vulnerability stems from Log4j's unexpected use of the Java Naming and Directory Interface (JNDI) combined with an LDAP (Lightweight Directory Access Protocol) server. Attackers could craft a specific string of text that, when logged by Log4j, causes the library to interact with a malicious LDAP server controlled by the attacker. This interaction could lead to the execution of arbitrary code with the permissions of the user running the Log4j library, potentially resulting in complete system compromise. The vulnerability was later addressed in Log4j version 2.15.0, which disabled JNDI LDAP lookups by default. Still, this update introduced a denial-of-service (DoS) vulnerability, ultimately addressed in version 2.16.0.
• Monero CLI binaries. The executable files of the Monero CLI wallet were compromised, making an infected version available to users. Using the infected binary, the attacker introduced two malicious functions to steal the seed from anyone who created or opened their wallet.

The following are other possible supply-chain attack scenarios that we previously blogged about and that are more related to cloud-native tools:

• In our research, we described the dangers of using third-party kubectl plug-ins leveraging the Krew plug-in manager without any security verification. In this case, attackers can either compromise legitimate plug-ins or deploy their malicious versions via typosquatting attacks to steal credentials from Kubernetes clusters.

Figure 3. Threat model scenario of sending a malicious plug-in to Krew

• We also investigated three widely used cloud-native tools: ArtifactHub, Helm, and ArgoCD. We then demonstrated scenarios where an attacker could abuse these tools to deploy malicious components inside a Kubernetes cluster.

Figure 4. Taking over a GitHub repository used by Argo CD

• Lastly, we identified hundreds of Open Policy Agent (OPA) servers exposed to the internet without authentication, allowing attackers to access, modify, or even delete data and security policies from the exposed OPA servers. This also enables them to carry out other attacks further.

Figure 5. Exposed OPA servers found on Shodan as of Aug. 11th, 2022; Query: port:8181 "policy-enable"

SLSA and MITRE ATT&CK

Now that we have covered real-world scenarios, we may now correlate the SLSA supply-chain threats with their respective MITRE ATT&CK techniques. Figure 6 shows a diagram of the ATT&CK techniques and other supply-chain scenarios that could happen throughout the software development life cycle:

Figure 6. MITRE ATT&CK techniques for a software supply chain

Conclusion

Managing a software supply chain that is both efficient and secure is not easy. To make things more agile, speed up processes, and use familiar methods, organizations have become much more reliant on third-party libraries and systems than they might realize. Therefore, protecting applications and systems is not just about safeguarding the code and internal assets — it is also about taking a more holistic approach to the software supply chain, considering every component and process. 

In this cloud-native era, as organizations leverage standard frameworks, they should also heed the necessary precautions to reduce the attack surface and mitigate the blast radius in case of compromise. A critical aspect of this approach is to trust but always verify the libraries, tools, and packages used and embed security tools and processes into applications whenever possible.

Armed with the knowledge of both the components and attacks associated with the development life cycle, organizations can better formulate plans on how to improve software supply-chain security.