New OWASP No.3: Software Supply Chain Security

Modern software isn’t built from the ground up anymore because that’s inefficient; these days it’s assembled. Developers put apps and websites together using various interdependent components and processes, which together we call the software supply chain. 

This convergence of so many resources is what makes this approach so powerful and versatile, but it’s also what makes it so vulnerable to attackers. 

In this post, we look at what you can do to keep your software supply chain safe and how Reflectiz can help.

The Threat

Attackers no longer need to compromise your application directly. Compromising what it depends on is often easier and far more effective. This is how North Korean threat actors managed to steal $1.5 billion worth of Ethereum in what’s been widely reported as the biggest crypto heist ever.

The global nonprofit community OWASP (the Open Worldwide Application Security Project) recognizes the risk and is actively helping developers, security professionals, and organizations to minimize the inherent dangers in building projects this way. The fact that it has added Software Supply Chain Failures to its proposed 2025 Top 10 list of the most significant vulnerabilities (straight in at number 3) reflects the seriousness of the risk.

What’s in the Software Supply Chain?

The list of components, processes, and systems involved in producing and delivering software will include: 

• Source code and version control systems 
• Open-source and third-party dependencies 
• Build tools, CI/CD pipelines, and scripts 
• Artifact repositories and package registries 
• Deployment platforms and runtime environments 

That offers a lot of potential targets, and a weakness at any point in this chain can compromise the final product, even if your own code is secure.

Common Software Supply Chain Threats

Supply chain attacks typically fall into four broad categories:

Source Code Compromise 

This is where attackers introduce unauthorized or malicious code into repositories by using stolen credentials, compromised accounts, or misconfigured access controls.

Dependency Attacks 

These poison third-party libraries, and then the hosted code is pulled into applications, sometimes intentionally (typosquatting, dependency confusion) and sometimes accidentally. While you can use software composition analysis to help identify known risks at build time, it cannot detect when trusted dependencies change their behaviors or introduce new risks once they’re running in production. This is an increasingly common attack technique that Reflectiz is designed to detect.

Build and Pipeline Attacks 

CI/CD systems, build agents, or plugins are compromised, allowing attackers to inject malicious artifacts at scale.

Deployment and Runtime Tampering 

Artifacts are altered after build, or runtime environments are manipulated to introduce backdoors or exfiltrate data.

Foundational Security Principles

Before we look at specific tools or techniques, it’s worth mentioning the core principles that strong supply chain security rests on:

Least Privilege and Strong Identity Controls

• This means only granting users and systems the permissions required to perform their role
• Enforcing multi-factor authentication everywhere
• Separating duties between developers, reviewers, and release managers
• Never storing secrets in source code or configuration files

Identity compromise is one of the most common entry points for supply chain attacks (because all humans are fallible eventually). Using these techniques makes it harder for attackers to get into your system via social engineering, and if they do, it means you won’t have given them the ‘keys to the kingdom’, and you’ll have a much better chance of containing the damage.

Logging, Monitoring, and Auditability

• Log activity across source control, CI/CD, and artifact repositories 
• Monitor for suspicious behavior such as unexpected builds or releases 
• Retain logs centrally so incidents can be investigated effectively 

If you cannot see what is happening in your supply chain, you cannot secure it. Comprehensive client-side supply chain visibility is a unique core benefit of using Reflectiz. It actively maps and then monitors the client-side website supply chain, so it can scrutinize third and fourth-party dependencies for any signs of compromise (and misconfiguration), in post-deployment runtime environments.

Security Automation 

• Manual checks don’t scale well, so it’s important to automate checking wherever possible. Use:
• Static application security testing (SAST) 
• Software composition analysis (SCA) 
• Secret scanning 
• Policy enforcement in pipelines 
• Vulnerability monitoring (e.g., using tools like OWASP Dependency-Check or retire.js) 

Automation reduces human error and ensures consistency, but remember that it also complements human oversight for policies and exceptions.

Securing Source Code and Repositories

Source code is often the earliest and easiest place for attackers to introduce malicious changes. 

Enforce Code Review and Branch Protection

• Require peer reviews for all changes (including manual checks for open-source components) 
• Protect main and release branches from direct commits 
• Require passing security checks before merges 

Code review is not just about quality; it’s also a critical security control. 

Harden Version Control Systems

• Regularly audit repository settings and permissions 
• Monitor for unusual activity, such as force pushes or disabled protections 
• Remove inactive users and stale access 
• Use tools like Legitify to detect misconfigurations in platforms like GitHub or GitLab 

Secure Developer Environment

• Keep developer machines and IDEs patched 
• Limit and audit third-party plugins 
• Install endpoint security and perform threat assessments 
• Educate developers about phishing and credential theft 

Compromised developer accounts often open the door to compromised repositories.

Managing Dependency and Third-Party Risk

Modern applications often rely heavily on third-party code, so managing this risk is non-negotiable.

Assess Suppliers and Open-Source Projects

Before adopting a dependency, consider:

• Is the project actively maintained? 
• How quickly are vulnerabilities addressed? 
• Is there a transparent governance or security process? 
• Check factors like maintainer count, test coverage, and vulnerability reporting 

Not all open-source projects carry the same level of risk, so due diligence is key with this one.

Maintain a Software Bill of Materials (SBOM)

An SBOM is a complete inventory of all dependencies used in an application. 

• Generate SBOMs + attestations/provenance automatically during builds (in formats like CycloneDX or SPDX) 
• Keep them up to date 
• Use them to respond quickly to newly disclosed vulnerabilities 

Pin and Lock Dependency Versions

• Use lockfiles and version pinning 
• Avoid automatically pulling the latest versions into production 
• Review and test dependency upgrades deliberately 

This prevents unexpected or malicious changes from entering your builds.

Continuously Scan Dependencies

• Scan for known vulnerabilities throughout the SDLC (monitor sources like NVD, OSV, GitHub Advisory Database, or CISA KEV) 
• Apply SAST to open-source components where possible 
• Treat high-risk findings as release blockers 
• Monitor dependencies even after deployment 

Dependency risk does not end at release. Reflectiz directly supports post-deployment risk management by continuously monitoring live client-side dependencies in production, detecting new scripts, unexpected changes, and malicious behaviors that would otherwise go unnoticed.

Securing the Build and CI/CD Pipeline

CI/CD systems are a bit like the water supply: they deliver resources that everyone implicitly trusts. This is why they’ve become such high-value targets. Here is how to secure them:

Inventory and Harden Build Tooling

• Know exactly which tools, plugins, and scripts are used 
• Remove unused components 
• Patch and update build systems regularly 
• Segregate networks and use data loss prevention where needed 

Isolate and Protect Build Environments

• Restrict network access for build systems 
• Limit who can modify pipelines and scripts 
• Use dedicated service accounts with minimal privileges 
• Limit or eliminate user-controllable build parameters 

Treat Build Scripts as Source Code

• Store pipeline configurations in version control 
• Require reviews for pipeline changes 
• Log and audit pipeline executions 

Pipeline changes should be as visible and controlled as application code changes.

Use Ephemeral and Reproducible Builds

• Build artifacts in short-lived, clean environments 
• Avoid long-lived build agents 
• Aim for reproducible builds where the same input produces the same output  

This reduces the risk of persistent compromise.

Sign and Verify Artifacts

• Cryptographically sign build outputs using Sigstore/cosign  
• Protect signing keys with strong controls 
• Verify signatures before deployment 
• Use private artifact repositories to review before allowing internal use 

Generate and Verify Provenance

• Produce verifiable provenance metadata (e.g., following the SLSA framework) detailing how, when, and where artifacts were built 
• Use compliant builders and verifiers to ensure trust and detect tampering 

The key principle here is that signing and provenance establish trust and integrity.

Deployment and Runtime Security

Security does not stop when the build finishes.

Scan Final Artifacts

• Scan binaries and container images before release (including binary composition analysis) 
• Check for embedded secrets or unexpected components 
• Verify signatures and integrity 

Monitor Production Environments

• Detect unexpected changes to running systems 
• Alert on anomalous behavior 
• Protect runtime environments with least privilege and segmentation 
• Continuously monitor deployed software for new vulnerabilities 

Runtime visibility is essential for detecting supply chain attacks that bypass earlier controls.

 Key Takeaways

• Software supply chain security is an end-to-end discipline, not a single tool 
• Most attacks exploit identity, dependencies, or automation 
• Visibility, automation, and strong access controls are foundational 
• Assume compromise is possible, so design systems to detect and limit impact 

By embedding these practices throughout the software lifecycle, organizations can significantly reduce their exposure to a critical security risk that has gained new prominence. Tools and frameworks like SLSA, OWASP Dependency-Check, and runtime monitors like Reflectiz can further strengthen your defenses.

Conclusion

By focusing on the dynamic client-side attack surface, where many modern supply chain attacks (e.g., via CDN-hosted scripts or npm packages) ultimately execute, Reflectiz helps organizations achieve the kind of holistic, proactive defense that OWASP advocates, significantly lowering the risk of devastating breaches.