Software Supply Chain Security

Every point in the SDLC presents a potential cybersecurity risk including:

• Tech stack
• Open source dependencies
• Development environments
• CI/CD pipeline
• Artifact repositories
• Distribution systems

All of which are typically connected to the Internet, and therefore present a potential point of cyberattack. However, because all these systems are typically located behind the firewall in trusted network zones, they’re rarely secured or audited to the extent they should be following the SolarWinds Orion attack in 2020. 

Hackers have now realized the economies of scale they can gain by targeting software vendors, since a single successful attack can compromise thousands or even tens of thousands of customers that may blindly install software updates from their trusted supplier. As a result, software vendors are now the frontline of security for their customers. 

What is the Software Supply Chain?

The software supply chain extends from everything an organization imports from public repositories and third parties to everything they build using CI/CD automation and other software build systems to everything they distribute for consumption/use by internal teams and external customers:

• Import – the process of importing third-party tools, libraries, code snippets, dependencies and other software resources in order to streamline development efforts.
• Build – the process of compiling, building and/or packaging code, usually via an automated system that also executes tests on built artifacts.
• Consume – the process of working with, testing functionality, and running built artifacts in development, test and production environments.
• Distribute – the princess of making built artifacts available for use by both internal teams and external customers, including patches, upgrades, runtime environments, etc.

Each process is susceptible to software supply chain attacks, which have been growing exponentially over the past few years. In response, the US President Joe Biden issued an executive order to help government agencies source more secure software from their software providers.

What are the security and integrity issues affecting the software supply chain?

Software supply chain issues include compromised third-party components, open source dependencies and unsigned open source software that may have been tampered with, non-repeatable build systems, and unaudited internal software development systems. 

For example:

• Public repositories are often sources of compromised third-party dependencies since the components they offer are typically unsigned, and rarely built with strict security and integrity controls in place.
• Organizations that build their own third-party dependencies from source code often build them only once on a developer’s desktop rather than using a repeatable build system.
• Organizations rarely audit their software development process infrastructure (including developer tools, test and CI/CD environments) even though these systems are typically connected to the internet and therefore subject to attack.

What are the most common software supply chain threats?

Typical supply chain threats and security risks include typosquatting, vulnerabilities, dependency confusion, author impersonation, backdoors, compromised code and/or build systems:

• Typosquatting – the practice of uploading a compromised package to a public repository that is named similar to a popular open source project (i.e., matplatlib vs matplotlib)
• Vulnerabilities – typically a coding flaw in a module of an application that compromises the security of the software, thereby offering bad actors a vector of attack (i.e., log4j).
• Dependency Confusion – similar to typosquatting, compromised packages are named similar to proprietary packages a target company may use internally. The confusion arises when a build tool prioritizes dependencies in public repositories over private ones.
• Author Impersonation – the process of compromising a public repository that has poor identity and access management controls.
• Compromised Code – the process of compromising a public repository by uploading a malware version of a popular package that contains malicious code.
• Compromised Build Systems – build systems created without strict security and integrity controls can allow bad actors to inject compromised code or hijack the system altogether.

What is the weakest link in the software supply chain?

Public repositories are typically cited as the weakest link in the software supply chain since they impose few restrictions or guidelines for the third-party code contributions they accept. 

For example, public repositories generally lack:

• Strict controls around typosquatting and brandjacking, which can result in developers mistakenly downloading compromised packages.
• Strict guidelines to ensure that prebuilt packages are securely built.
• Signed artifacts, which would ensure that prebuilt packages have not been tampered with after they have been built.

 As a result, public repositories provide no guarantees as to the security and integrity of the components they offer. While security teams are often well aware of open source security issues in their codebase, they’re typically focused on vulnerabilities rather than supply chain risks.

How can software supply chain security be improved?

While typical software security practices like vulnerability scanning using Software Composition Analysis (SCA) tools, application security testing using SAST and DAST tools, reducing the attack surface, enforcing authentication permissions, and code reviews, are all good practices, software supply chain security requires that controls be put in place to address threats in third-party code and software development infrastructure, such as cloud-native or web application development environments and build systems.

Software supply chain security controls and threat mitigations include:

• SLSA — security frameworks like Supply chain Levels for Software Artifacts (SLSA) provide guidance for implementing software build system controls that prevent tampering and improve the security and integrity of built artifacts.
• SBOMs — a Software Bill Of Materials (SBOM) provides a machine-readable list of all the software comprising an application, service, API, or runtime environment, and also provides key metadata (license, supplier, version, etc) for each component. Common SBOM formats include Software Package Data Exchange (SPDX), Software Identification (SWID) tag and CycloneDX.
• Attestations — provide a way for software creators to independently prove to a third party that their software is intact, unmodified and therefore trustworthy. For example, the in-toto attestation format represents authenticated metadata about a set of software.
• Audits — put in place a continuous risk assessment framework that is regularly tested against to ensure development systems haven’t become infected or compromised.

Read Similar Stories