Today, software is built and delivered faster than ever, but that speed has come with a cost. The integrity of the software supply chain is now one of the most actively targeted areas in cyber security. High-impact incidents in recent years have shown how quickly a single compromised dependency, build step, or update mechanism can cascade through an entire ecosystem.

OWASP addressed these shifts in 2021 by introducing A08: Software and Data Integrity Failures, a category focused on software tampering, unverified components, and weaknesses in code and delivery pipelines.

Even with a new OWASP Top 10 on the horizon, A08 still remains highly relevant.

Attacks against the software supply chain often succeed not only because of code flaws, but also because of the underlying trust in components and pipelines. As organisations lean more heavily on open-source dependencies and automated CI/CD tooling, that foundation of trust is becoming increasingly difficult to protect.

What Is OWASP A08:2021 and Why Should It Matter To You?

OWASP A08:2021 brings attention to an important application security principle that software is only as trustworthy as the code, components, and processes that produce it. When those elements can be tampered with (or aren’t verified properly) you end up with what OWASP calls Software and Data Integrity Failures.

The category covers a broad range of scenarios:

Untrusted or unverified open-source libraries,
Unsigned software updates,
Dependency hijacking through malicious package uploads,
and build pipelines that can be altered by anyone with the right access.

You’ll notice many of these weaknesses have little to do with traditional coding flaws and far more to do with the systems that assemble, deploy, and update software.

The Modern Supply Chain Problem

Modern software is rarely built from scratch. Most applications now rely on a sprawling network of open-source libraries, container images, build tools, and automation scripts. These components are pulled into development pipelines automatically and at speed, which means many teams have limited visibility into what they’re actually shipping.

If you’ve ever added a new dependency with a single command and assumed it was safe, you should now understand how easily supply chain risk can slip through.

The sheer number of components involved is part of the problem. A standard application can include hundreds of direct dependencies and thousands more transitive ones. Each of these carries its own vulnerabilities, maintainers, and supply chain exposures.

Attackers understand this better than anyone. By compromising a single library, registry, or build configuration, they can quietly reach every environment downstream.

NIST’s supply chain guidance Special Publication 800-161r1 “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations” reinforces this point. Without transparency, provenance, and integrity checks, organisations are effectively trusting every component in the chain by default.

Common Root Causes of OWASP A08

Integrity failures often stem from security gaps in the way software is assembled, updated, and deployed. These issues rarely resemble traditional software vulnerabilities. Instead, they’re offshoots of the assumptions teams make about their components and automation.

Common root causes include:

Missing authenticity checks - Unsigned or unverified packages, updates, or container images make it impossible to confirm whether artefacts have been tampered with.
Weak CI/CD change control - Build agents or automation scripts running with broad permissions enable attackers to modify pipelines if a single credential is compromised.
Risky dependency ecosystems - Malicious package uploads, abandoned libraries, and look-alike package names (e.g., typosquatting) introduce opportunities for supply chain compromise.
Misconfigured registries and artefact stores - Poorly secured container registries or package repositories allow unauthorised changes.
Insecure Infrastructure-as-Code (IaC) or build scripts - Unvalidated templates or overly permissive automation can propagate errors or malicious changes across environments.

When you look at them side by side, it’s clear they all point to the same problem: too much trust built into the software delivery chain.

Practical Controls for Addressing A08

Reducing the likelihood of A08 failures requires a combination of technical controls and stronger assurance around how software is built and updated.

Practical controls include the following:

Control	What It Addresses	Security Benefit
Software integrity verification	Unsigned or unvalidated packages, updates, and container images	Ensures artefacts haven’t been tampered with and prevents untrusted code from entering the pipeline
CI/CD hardening	Over-privileged build agents, weak credential management, pipeline tampering	Reduces the blast radius if a build system or automation account is compromised
Dependency validation	Malicious or abandoned libraries, dependency confusion	Helps teams avoid risky components and identify vulnerabilities earlier in the lifecycle
Secured registries and artefact stores	Unauthorised changes to packages or images	Prevents attackers from modifying or replacing critical components inside trusted repositories
IaC and automation script review	Misconfigurations or malicious changes in templates and automation	Ensures infrastructure changes are intentional, validated, and traceable

How Blacklock Helps Organisations Reduce OWASP Top 10 A08 Risk

A key part of addressing A08 is having reliable visibility into the components, dependencies, and artefacts that flow through a software delivery chain. Blacklock helps organisations establish this assurance through a set of capabilities designed to uncover integrity risks early and verify remediation consistently.

SBOM Scanning for Component-Level Visibility

Blacklock’s SBOM Scanning service gives organisations a clear view of the libraries and dependencies inside their applications. By analysing SBOMs (Software Bill of Materials) against known vulnerabilities, licensing issues, and outdated packages, teams can quickly see where supply chain risk may enter the build process. This aligns directly with A08’s focus on untrusted and unverified components.

Continuous Dynamic Application Security Testing (DAST)

Blacklock integrates with CI/CD pipelines and automated workflows, enabling Dynamic Application Security Testing (DAST) scans to run whenever teams trigger them as part of their build or release process. This keeps visibility current and avoids reliance on manual, infrequent checks, which is one of the root causes of A08 failures.

Automated Security Validation

When teams update a vulnerable component, they can use Blacklock’s Agentic AI-powered Automated Security Validation re-tests to confirm the issue has been fully resolved. This provides a reliable closure loop, ensuring that fixes have the intended effect before they reach production.

Start Securing Your Software Supply Chain

If you’re looking to improve visibility into your software components and build pipelines, reduce supply chain risk, or understand how Blacklock can support your A08 mitigation efforts, our team is here to help. We work with organisations across New Zealand and Australia to build practical, evidence-based security assurance into their delivery pipelines. Contact us now.

Share this post