In this example:

• If prebuilt components are downloaded, they should be staged in an artifact repository like Sonatype Nexus, JFrog Artifactory, or similar where they can be examined before being made available to developers.
  • If source code is downloaded instead (for example, if you are vendoring all the dependencies your application requires), you might want to stage it in a code repository like GitHub, Bitbucket, GitLab, etc instead. 
• All imported artifacts must be scanned for malware, trojans, backdoors, typosquatting and other malicious vectors using a code scanner such as UpGuard, BluEye, or similar solution. 
  • If prebuilt binaries are also being imported, you may require a separate binary scanning tool that can disassemble and examine compiled code, such as the Static Application Security Testing (SAST) Tools from Veracode, Checkmarx, or similar.
• You may want to consider implementing a second, “quarantine” repository where components can be further analyzed for security and integrity using Software Composition Analysis (SCA) Tools like BlackDuck, Snyk or similar to identify vulnerabilities. 
  • Some enterprises may want to perform further checks for compliance with corporate guidelines by identifying non-commercial-friendly licensing.
• Finally, a third “development” artifact repository is where all “ready to use” artifacts are placed for use by development teams. This repository should provide continuous vulnerability scanning, generate a vulnerability status, and send automated notifications when a vulnerability is found. Notifications should also include patch/upgrade recommendations. The aforementioned Sonatype Nexus, JFrog Artifactory will serve here, as well. 

There are numerous other tools that can be considered along this chain to help with automation, including:

• Policy management tools that can prevent the importation of any artifact that does not conform to corporate governance guidelines. Both general solutions like Open Policy Agent (OPA) and IDE-based solutions like Snyk can be considered here.  
• Automated remediation tools like GitHub’s Dependabot, Debricked or similar can help quickly fix vulnerabilities through automating the upgrade process when a newer version of the component is released. 

Implementing these kinds of best practices and tools can help avoid common exploits and malware associated with open source, including using known vulnerable components, avoiding typosquatted resources, and incorporating GPL licensed code in commercial applications. For example, Sonatype reports “2.1 billion OSS downloads with known vulnerabilities in 2023 could have been avoided because a better, fixed version was available.”

Securing the Software Supply Chain Build Process

The software artifact build process is typically automated through the use of Continuous Integration (CI) systems that must be hardened against attack and intrusion. The pipeline itself also offers a number of opportunities to better ensure the security and integrity of the artifacts being built, including:

• Source Code Integrity – the provenance or source of the code must be ensured before the build process can be kicked off. Consider adopting software attestations that help verify the origination of a component and how it was built such as those provided by TestifySec Witness, GitHub Actions or similar.
• Runtime Integrity – prior to populating any container with its runtime environment, consider verifying the integrity of the runtime against its Software Bill Of Materials (SBOM) to ensure all components (and no extra components) are present. SBOM vendors include Anchore, FOSSA, Mend, etc. 
• Hardened Build Service – implement strong tamper protection for your build service by following best practices that include isolated, ephemeral, hermetically sealed containers, as well as build scripts and a signing service that are inaccessible to users. Signing services include examples like SigStore, Microsoft Authenticode, or similar.
• Reproducible Builds – use of a deterministic build service to ensure that the output is always identical given the same inputs. CI solutions that can be made deterministic include CircleCI, Bazel, or similar.
• Code & Executable Testing – the CI process should incorporate both Static and Dynamic Application Security Testing. SAST and DAST tools include those from Acunetrix, SonarQube, Fortify, etc

Implementing these kinds of best practices and solutions can help avoid becoming the next Solarwinds, whose build process was compromised resulting in hundreds of downstream customers being affected including the US government, all arms of the US military, the big five accounting firms, and more. 

Securing the Software Supply Chain Deployment Process

Deployment systems, whether used for releasing on premise versions of an application or hosted SaaS deployments must be appropriately hardened. The same is true for any system that delivers automated security updates/patches. 

Post-release, vulnerabilities should continue to be tracked, with customers being provided notifications and timely updates. 

More on this section will be provided in the Buyers Guide, along with other areas including:

• Secrets management
• Cloud / PaaS systems
• Dependency management
• Threat modeling
• OS and language distributions
• And more

Conclusions: The Best Way to Secure the Software Supply Chain

While multiple Secure Software Development Frameworks (SSDFs) have existed for decades, they proved insufficient to address software supply chain attacks. Cue the market, with vendors of all stripes jumping in to fill the gap with everything from new security frameworks to specific point solutions to one-size-fits-all platforms.

Integrating multiple best-in-class point solutions can be time and resource consuming, and require extensive maintenance to upkeep as newer versions are released and integrations break. On the other hand, adopting a monolithic platform may bring with it numerous limitations since it’s unlikely to be flexible enough to address all use cases. 

There’s also the question of how much of the solution is proprietary, engendering lock-in versus those that follow open source principles. ActiveState, for example, takes a hybrid approach, offering a platform that supports open source standards designed to integrate seamlessly with existing software development processes.

With organizations facing a veritable tidal wave of choices, it’s no wonder that most of them are knee deep in analysis paralysis, unsure of where to even get started. This is why we created the Journey to a Secure Software Supply Chain ebook that can help you evaluate your current stance, and create a plan to improve it. Coupled with our upcoming Software Supply Chain Security Buyers Guide, organizations will be able to obtain a comprehensive view of the market landscape so they can pick and choose the best solutions at each stage in their journey.