Securing the Software Supply Chain

By Eric Tice

Introduction

Software is not yet aware and can’t self-identify positive or malicious changes or the impact throughout an interdependent chain of applications, and this is probably a good thing today. But as software is in a constant state of evolution and flux, this presents opportunities for bad actors to insert vulnerabilities at one or more points to achieve financial or political goals.

Over the last decade, hackers have been seeking ways to target applications through the software supply chain, and in particular, open source software elements. Hackers have had some spectacular successes: SolarWinds, Microsoft Winget, Kaseya, and most recently, Log4Shell (Dec 2021). Checkpoint Software observed over 800,000 global attacks within 72 hours of the vulnerability being made public. Many organizations were unaware of these attacks for years as they relied on their vendors to be trusted buffers to manage these threats. With the growing embrace of open source software, digital transformation, and wholesale migration to the cloud, the need for enhanced and innovative security solutions and a better understanding of the software ecosystem is becoming critical. This is no small endeavor, especially for highly regulated entities in industries such as banking, healthcare, and government.

What is Software Supply Chain Security?

Software supply chain security is the process of monitoring, analyzing, identifying, and mitigating vulnerabilities and compliance issues that threaten the processes, repositories, infrastructure, and tools used for developing and delivering software. This definition is relevant to current software development practices because most applications leverage open source components or other third-party libraries that are ingested into an organization through a variety of known and unknown methods and that may allow potential security gaps outside the users’ awareness or control.

Software Supply Chain Attack Timeline

Securing the modern software supply chain is a significant undertaking, and most enterprises face the following challenges:

• Growing number of fragmented toolsets
• Lack of experience or expertise with open source software
• Decentralized systems and lack of automation in continuous delivery
• Cloud native, hybrid, and multi-cloud deployment considerations
• Increasing pace, scale, and sophistication of threats
• Knowledge of Software Bill of Materials (SBOM) and how to build and manage them
• Accounting for software supply chain risks within the organization’s risk framework

Software supply chain attacks happen through a malicious element being introduced into the “chain” that causes a pervasive cascading effect. These threats can come at all stages of the Software Development Life Cycle (SDLC) and propagate downstream, usually completely unnoticed, making them difficult to remediate.

Types of Threats

The threat landscape continues to evolve, but some types are prevalent, targeting open source software. These are some of the most frequent types of attacks:

1. Malicious Code Injection — ex. SolarWinds and Kaseya

• Stealing credentials from a project maintainer
• Contributing pull requests to a project on a public project repo
• Tampering with open source developer tools to inject malicious code downstream

2. Typosquatting — ex. Python Package Index

An indirect attack vector exploiting typos when looking for software, typosquatting provides a malicious alternative to the expected URL or package name.

• For example, attackers attempted to “brandjack” three maven plugins by providing commonly used package names under a similar but different domain, com.github.codingandcoding:maven-compiler-plugin instead of the legitimate org.apache.maven.plugins:maven-compiler-plugin, link.

3. Code Signing — ex. Microsoft Windows 10

• Compromising certificates
• Theft of signing keys

4. Supply Chain Substitution Attack — ex. NPM and Yarn package JSON files being rewritten.

• Installer script is tricked into pulling a malicious code file from a public repository instead of the intended file of the same name from an internal repository.

There are also threats that are completely under the control of an organization to mitigate. But through complacency, lack of expertise, or lack of knowledge, they are not addressed with the required focus. Examples include:

• Lack of proper security policy definitions in scanning tools to perform automated scans
• Delaying patching of known vulnerabilities
• Limited feedback loop to enhance security policies and guidelines
• Lack of engagement in the relevant foundations and projects

Industry

Innovation and constant improvements to the detection and mitigation of security threats continue to be a focus now more than ever. In the last year, many of the key players in technology, security, and cloud have increased their commitment to building innovative new ways to address these threats, using both proprietary and open source technology. Many do not realize that almost all the software used today contains open source, including proprietary software. For example, not only does Microsoft use open source in many of its products but is one of the top five open source contributors: (See https://opensource.microsoft.com/).

This may cause many of you to take pause after the Log4J issues at the end of 2021, thinking, “Isn’t open source the cause of these issues?” While it is true that some open source libraries and components are not properly governed and can potentially be threats, innovation and a collaborative community mindset help the industry more rapidly address these concerns.

Since the focus continues to be the “Sec” in DevSecOps, we can look to automate all these core processes into existing and new pipeline development tools to assure a much higher level of threat management. The Open Source Security Foundation (OpenSSF) was formed in 2021 with the idea that they could help provide working groups to solve a number of these potential problems and prevent issues like SolarWinds and Log4J from happening or minimizing the impact when they do.

Projects like Alpha Omega have been created as a direct result of the Whitehouse Executive Order on improving the Nation’s Cybersecurity to identify and invest in scanning and remediating vulnerabilities in the top 10,000 most widely used open source libraries. Initiatives like this remind us that understanding what is running in our application ecosystem has been often ignored and that the need for detailed SBOMs and a dependency management toolset is critical to continued security. Over the years, many organizations have had very minimal standards around vulnerability and penetration testing, having them scheduled quarterly, or even yearly, to meet minimal compliance needs. As is evident now by the 650% rise in attacks in the last year, this approach can no longer continue.

Adoption of community-developed best practices in securing the software supply chain is a first step in managing against threats. As your organization begins to automate more and more of the SDLC process, it is important to adopt frameworks like Supply-chain Levels for Software Artifacts, or SLSA (“salsa”), to outline the key areas where a vulnerability may be exploited, so controls can be enacted to assure mitigation proactively.

The SLSA Framework

The SLSA framework provides a guideline for the implementation of appropriate security measures which drive automation planning. As a result, there are several initiatives that have started over the last year to help meet the requirements. Developer code signing and management, improved standards around SBOMs, configuration and vulnerability scanning are all areas that are bringing new tools to the market.

Recommendations

As new requirements and government mandates are produced to push for implementation of more strict and proactive measures in software supply chain security, it requires increased action for all enterprise organizations. It is a key part of every successful organization moving forward, regardless of how compliant they thought they were. A full assessment of policy and ways of working should be part of the immediate roadmap. We have discussed the threats and potential areas to address moving into this new phase of compliance, and we recommend the following first steps to build a more secure SDLC for your enterprise.

As part of building an SDLC governance and risk management plan:

• Reexamine your current business and technical strategy to align goals and ways of working to assure increased focus on proactive security.
• Perform an assessment of the existing application landscape with a SBOM as a key outcome of the exercise.
• Leverage strong governance procedures to keep an up-to-date SBOM for current and future planned usage, for transparency, and as a guiderail mapped to the OpenSSF critical projects list to understand potential issues.
• Demand a list of SBOMs, SLAs, and procedures used to vet dependencies from your software vendors to validate their commitment as an OEM to support security.
• Create a plan for proactive scanning and mitigation of vulnerabilities to assure proper SLAs with your customers.
• Automate your processes early to check for vulnerabilities with a developer-first mentality. Place initial responsibility on your development team to vet the tools they are using and building for potential security threats.

Conclusion

The threat of continued attacks on the software supply chain is very real. In the days during the development of this document alone, we have seen worldwide hacking groups and governments using cybersecurity as a weapon of war by Russia, Ukraine, and the hacking group Anonymous. Organizations’ need to make adoption of proactive software supply chain security practices a top priority. This can be accomplished by implementing a shift-left approach that begins in the early stages of the SDLC. It is initially managed by developers, increasing transparency into the packages and third-party tools being added to the code base via SBOMs and automation of key components using frameworks like SLSA. Early adoption of processes that allow for proactive risk mitigation and remediation provide enterprises with the tooling and structure needed to address the increase in threat to themselves as well as their downstream partners and clients.