The heightened regulatory and legal pressure on software-producing organizations to secure their supply chains and ensure the integrity of their software should come as no surprise. In the last several years, the software supply chain has become an increasingly attractive target for attackers who see opportunities to force-multiply their attacks by orders of magnitude. For example, look no further than 2021's Log4j breach, where Log4j (an open-source logging framework maintained by Apache and used in a myriad of different applications) was the root of exploits that put thousands of systems at risk.

Log4j's communication functionality was vulnerable and thus provided an opening for an attacker to inject malicious code into the logs which could then be executed on the system. After its discovery, security researchers saw millions of attempted exploits, many of which turned into successful denial-of-service (DoS) attacks. According to some of the latest research by Gartner, close to half of enterprise organizations will have been the target of a software supply chain attack by 2025.

But what is the software supply chain? Well for starters, it's defined as the sum total of all the code, people, systems, and processes that contribute to the development and delivery of software artifacts, both inside and outside of an organization. And what makes securing the software supply chain so challenging is the complex and highly-distributed nature of developing modern applications. Organizations employ global teams of developers who rely on an unprecedented number of open source dependencies, along with a breadth of code repos and artifact registries, CI/CD pipelines, and infrastructure resources used for building and deploying their applications.

And while security and compliance are consistently a top concern for enterprise organizations, the challenge of securing the organization's software supply chains looms larger and larger. Many organizations are making material progress with operationalizing DevSecOps practices, however, a great deal of them still find themselves in the early stages of figuring out what to do.

Which is exactly why we've put this article together. Though the following is by no means an exhaustive list, here are four guiding principles for getting your software supply chain security efforts rolling in the right direction.

Consider All Aspects of your Software Supply Chain When Applying Security

Given that over 80% of code bases have at least one open-source vulnerability, it stands to reason that OSS dependencies have been a central focus of software supply chain security. However, modern software supply chains encompass other entities whose security postures are either overlooked or not understood broadly enough within the organization to be properly managed. These entities are code repositories, CI and CD pipelines, infrastructure, and artifact registries, each of which requires security controls and regular compliance assessment.

Frameworks such as OWASP Top-10 for CI/CD and CIS Software Supply Chain Security Benchmark. Adhering to these frameworks will require granular RBAC, applying the principle of least privilege, scanning containers and infrastructure-as-code for vulnerabilities and misconfigurations, isolating builds, integrating application security testing, and proper management of secrets – just to name a few.

SBOMs are Essential for Remediating Zero-days and Other Component Issues

Part of Executive Order 14028, issued by the White House in mid-2021 to strengthen the nation's cybersecurity posture, mandates that software producers provide their federal customers with a software bill of materials (SBOMs). SBOMs are essentially formal records intended to provide visibility into all the components that make up a piece of software. They provide a detailed, machine-readable inventory that lists all open source and third-party libraries, dependencies, and components used in building the software.

Whether an organization is compelled by EO 14028 or not, generating and managing SBOMs for software artifacts is a valuable practice. SBOMs are an indispensable tool for remediating component issues or zero-day vulnerabilities. When stored in a searchable repository, SBOMs provide a map of where a specific dependency exists and enable security teams to quickly trace vulnerabilities back to impacted components.

Govern the Software Development Lifecycle with Policy-as-code

In the world of modern application development, rock-solid guardrails are an essential tool for eliminating errors and intentional actions that compromise security and compliance. Proper governance throughout the software supply chain means that the organization has made it easy to do the right things and extremely difficult to do the wrong things.

While many platforms and tools offer out-of-the-box policies that can be quickly enforced, policy-as-code based on the Open Policy Agent industry standard enables authoring and enforcing fully-customizable policies. Policies governing everything from access privileges to allowing or denying the use of OSS dependencies based on criteria such as supplier, version, package URL, and license.

Be able to Verify & Ensure Trust in your Software Artifacts using SLSA

How can users and consumers know that a piece of software is trustworthy? In determining the trustworthiness of a software artifact, you'd want to know about things like who wrote the code, who built it, and on which development platform it was built. Knowing what components are in it would also be something you should know.

Making a decision whether to trust software is possible once provenance– the record of a software's origins and chain of custody– can be verified. For this, the Supply Chain Levels for Software Artifacts (SLSA) framework was created. It gives software-producing organizations the ability to capture information about any aspect of the software supply chain, verify properties of artifacts and their build, and reduce the risk of security issues. In practice, it's essential for software-producing organizations to adopt and adhere to the SLSA framework requirements and implement a means of verifying and generating software attestations which are authenticated statements (metadata) about software artifacts throughout their software supply chains.

Given the magnitude and complexity of securing the modern software supply chain, the above guidance merely scratches the surface. But like everything else in the world of building and deploying modern applications, the practice is evolving fast. To help you get started, we recommend reading How to Securely Deliver Software – an ebook full of best practices designed to strengthen your security posture and minimize risk for your business.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter  and LinkedIn to read more exclusive content we post.