Securing the software supply chain is a complex task. For one, it spans the entire software development lifecycle (SDLC). For another, generative AI coding tools and modern development practices are increasing software complexity. The result: Development teams are in the hot seat.
Feeling developers' pain, the Open Worldwide Application Security Project (OWASP) has created a software supply chain security cheat sheet to help teams secure their SDLC. Organized along several practice areas, the OWASP guide starts with general steps — then gets specific on core areas of concern, including source code security, dependency and deployment threats, third-party risk, and final build testing.
Here are five key action items from the OWASP supply chain security cheat sheet.
[ Download: 2025 Software Supply Chain Security Report | See the SSCS Report Webinar ]
1. Secure your development platform
An important general practice cited in the cheat sheet is access control. Compromised accounts, particularly privileged ones, represent a significant threat to software supply chains, the cheat sheet explains. Account takeover can allow an attacker to perform a variety of malicious acts, including injecting code into legitimate dependencies, manipulating CI/CD pipeline execution, and replacing a benign artifact with a malicious one.
Jeff Williams, CTO and co-founder of Contrast Security, said the software development environment is "incredibly important to supply chain security."
"If an attacker can access any part of it, from a developer’s laptop to a build server to the code repository, they can inject their malicious code into the product. Once it’s in place, malicious code is incredibly difficult to identify, far harder than simple inadvertent security mistakes. The attacker may go to great lengths to obfuscate their backdoor."
—Jeff Williams
Joe Nicastro, field CTO of Legit Security, said to think of access control as the bouncer at the door of your software supply chain.
"If just anyone can get in — whether it’s a rogue developer, a compromised account, or an outsider with bad intentions — you’re inviting trouble. Strong access controls, like multifactor authentication and least-privilege access, make sure that only the right people and systems can modify code, builds, or version control systems."
—Joe Nicastro
Without a bouncer, attackers can sneak in, plant malicious code, or even hold your entire software pipeline hostage, Nicastro said.
The OWASP cheat sheet also addresses source code threats. These types of threats focus on violating the integrity of source code, which is then built and deployed or potentially consumed by other software projects, the document explains. Key to managing source code threats is securing the development platform.
Integrated development environments (IDEs), development plugins, and similar tools can help assist the development process. However, like all pieces of software, these components can have vulnerabilities and become an attack vector, the cheat sheet notes. Thus, it is important to take steps not only to ensure that these tools are used securely, but also to secure the underlying system, said Martin Jartelius, CISO of Outpost24.
“Securing the development platform is non-negotiable — compromised tools lead to compromised code. This means enforcing strict access controls on IDEs, version control systems, and CI/CD pipelines, ensuring only authorized users can modify or push code.”
—Martin Jartelius
Jartelius said developer workstations must be hardened with endpoint security, up-to-date patches, and strict software installation policies to prevent malware or supply chain attacks. “Secure configurations, encrypted storage, and network segmentation further reduce exposure. Continuous monitoring for anomalies and enforcing signed commits help maintain integrity. Ultimately, a secure development environment isn’t just about tools — it’s about creating a controlled, resilient ecosystem that attackers can’t easily exploit,” he said.
Contrast Security's Williams said many organizations don’t do much to lock down developer environments. "Developers often do their work with root privilege, allowing them to install software, change settings, and even modify the operating system,” he said.
Williams added that developers often download hundreds of open-source projects and execute them, cloning repositories and build projects, and they are likely to download many tools and utilities as part of their work.
"Any of this software could completely take over their environment, change their code, introduce backdoors, commit changes, and steal IP. So, while painful, organizations need to take control of their development environments, stop allowing promiscuous tool and library use, and strengthen OS security.”
—Jeff Williams
2. Leverage AppSec testing automation
Another general security practice recommended in the cheat sheet is leveraging security automation. For complex software supply chains, automation of security tasks, such as scanning, monitoring, and testing, is critical, OWASP noted. While not a replacement for manual reviews and other actions performed by skilled professionals, automation is capable of detecting, and in some cases responding to, vulnerabilities and potential attacks with a scale and consistency that is hard to achieve through manual human intervention, said Ben Cotton, open-source community lead at Kusari.
“The automation of tasks reduces the chances for human error. Automation works faster, more consistently, and scales to larger environments than humans.”
—Ben Cotton
Cotton said that with machine-readable policy, organizations can programmatically enforce requirements and guardrails. However, this doesn’t reduce the need for security professionals. "Humans are needed to craft the policies, supervise the actions of automation, and handle exceptional cases. In other words, automation takes care of the mundane tasks so that humans can focus on the unusual,” he said.
3. Assess your third-party resources
To mitigate dependency threats, the OWASP cheat sheet recommends thoroughly assessing all third-party services, products, and software components incorporated into the software supply chain. That process can be very challenging to organizations, especially given the limitations of legacy application security testing (AST) tooling.
Mike McGuire, senior security solutions manager at Black Duck Software, said the biggest challenge in managing third-party risk is visibility.
“The average commercial codebase depends on 911 open-source components. Over half of these dependencies are transitive, meaning there are numerous dependencies being introduced into applications inadvertently. Depending on how these dependencies are introduced, it can be difficult to identify and track them and complete tasks like providing accurate SBOMs [software bills of materials] to consumers.”
—Mike McGuire
Another challenge is the rapid nature of software development, McGuire said. “Dependencies can be very frequently updated, introducing new security vulnerabilities, which requires continuous monitoring and an efficient prioritization approach to stay on top of.”
Security teams also must grapple with limited access to source code, McGuire said. That's because most third-party components are closed source, making code audits out of the question. "Security teams then have to rely on some sort of binary analysis or trust their vendor’s SBOMs and security attestations, which can be inaccurate themselves because they too face these same challenges,” he said.
4. Trust your sources
To mitigate software build threats, the cheat sheet suggests verifying provenance and assuring that sufficient metadata is generated. Having assurance that a software supply chain component comes from a trusted source — and has not been tampered with — is an important part of software supply chain security, the OWASP guide notes.
The provenance should be generated by the build platform (as opposed to a local development system), be very difficult for attackers to forge, and contain all details necessary to accurately link the result back to the builder, OWASP noted.
Melody (MJ) Kaufmann, an author and instructor at O'Reilly Media, said that tracking provenance and metadata helps teams trace vulnerabilities quickly, identifying affected components during security incidents.
“It also supports compliance with SBOM requirements, ensuring transparency, streamlining audits, and reducing regulatory risks.”
—Melody (MJ) Kaufmann
But determining provenance can be challenging, and its effectiveness is questionable, Williams said. “The problem is that it’s difficult to set up and manage, and it’s only available for a tiny fraction of the open-source universe,” he said.
“Ultimately, it doesn’t really stop malicious code; it just signs it. So imagine an attacker breaks into a developer laptop, inserts a backdoor into the code, and commits it to the repo. The build pipeline kicks off and builds, packages and tests the release, digitally signing and ensuring the provenance of the now-Trojaned software component. What did that help?”
—Jeff Williams
5. Scan the final build binary
One of the cheat sheet’s key recommendations is to scan the final build binary and deploy reproducible builds of packages before release. Software teams should not simply assume that the final result is secure. Binary analysis can help detect exposed secrets and unauthorized components or content — and verify integrity. OWASP said the final build scans should be performed by both suppliers and consumers.
Binary composition analysis detects hidden vulnerabilities, malware, or unauthorized changes in the final build, ensuring integrity before deployment, OutPost24's Jartelius said. And reproducible builds add a critical verification step.
“Reproducible builds add another layer of security by verifying that source code and compiled binaries match, preventing stealthy injections. Together, they aim to make tampering obvious and protect against supply chain attacks that manipulate the build process.”
—Martin Jartelius
Williams said that binary and runtime composition analyses are important, since they reflect exactly what software made it into the binary — and ultimately into production. "Surprisingly, the results from these techniques may be very different from what is generated at build time," he said.
"Studies show that only 38% of open-source libraries included in the binary actually run in production. The rest of this code is just unused parts, included to support unused features of other libraries."
—Jeff Williams
Complexity makes supply chain security essential
For protectors of software supply chains, Williams gives this advice: "The software supply chain is extremely complex. Rather than hyper-focusing on crazy movie-plot threats, it’s best to start a systematic program to reduce your exposure over time. Stick to well-known libraries and create a culture of keeping them up to date. Focus on the ones that are actually in use in production."
"Train your developers to keep an eye out for suspicious code that might have a malicious purpose, and ensure that all code must be reviewed by another developer before it’s accepted. And definitely establish strong authentication and access control to development resources, and install malware detection software on all development machines."
—Jeff Williams
ReversingLabs’ director of product management, Charlie Jones, noted recently in an Open Source Security Foundation blog post how the attack surface within software supply chains has grown exponentially. Because of this, it has become even more difficult for organizations to manage risks that stem from open-source, proprietary, and commercial off-the-shelf software (COTS). To address these risks head on, Jones urged in his post that organizations should look beyond traditional AST tooling to tactical binary analysis to properly secure their supply chains.
“Compromises such as those of VoIP provider 3CX highlight the gaps in software supply chain security — and the need for a new approach to supply chain risk management.”
—Charlie Jones
