A08 · Software or Data Integrity Failures

A08

OWASP Top 10 · 2025

Software or Data
Integrity Failures

The certificate was valid. The signature checked out. The software was malicious. Trust is not the same as verification.

// 3CX — 2023 — the first cascading integrity compromise

In March 2023, security vendors detected that 3CX's desktop phone application — used by 600,000 companies and 12 million daily users — was distributing malware. The software was digitally signed with a valid certificate. Every integrity check passed. The malicious code was embedded in the legitimate build by attackers who had compromised 3CX's build servers. But that compromise started somewhere else: a single employee had downloaded a tampered financial trading application, X_TRADER, months earlier. It was the first documented case of one supply chain attack causing another — a cascading integrity failure.

Late '21

X_TRADER compromised

Apr '22

3CX employee downloads it

Late '22

Build servers compromised

Mar '23

Malicious app distributed

Mar '23

Detected by EDR vendors

↑ click any event to see what happened ↑

// classify the failure

3CX had code signing. They had a build pipeline. The software was signed with a valid certificate. What was the integrity failure?

🔑 Weak signing key

The code signing certificate used a short key that attackers were able to forge or brute-force.

🏗️ Build environment trusted blindly

The build servers were compromised, but the pipeline had no way to detect that the build input had been tampered with.

📦 Missing dependency audit

A malicious third-party library was introduced through an unreviewed dependency update.

🌐 Insecure distribution

The download server was compromised and served a different binary than what was built.

// find the integrity failure

A CI/CD pipeline configuration. Artifacts are built, signed, and deployed. One step trusts its input without verification. Click the line.

build-pipeline.yml

// attack path — click each node to trace the cascade

Five systems. Each one trusted the previous without independent verification. Click any node to see how the integrity failure propagated.

📦 X_TRADER

compromised late 2021

💻 Employee PC

downloaded apr 2022

🏗️ Build Servers

lateral movement

📱 3CX DesktopApp

trojanized + signed

🏢 600K Customers

12M daily users

↑ click any node to trace the attack path ↑

Verify at every boundary.

missing

added

Integrity isn't one check — it's verification at every trust boundary. The build environment, the artifacts, the distribution, the client-side verification.

🎯 the one habit

Add SRI to CDN scripts. Verify checksums before deployment. Never assume a valid signature means the content is safe — verify what went in, not just who signed it.

Node.js

Python

Java

build-pipeline.yml

click the dot

// knowledge check

1 / 3

Your web application loads a JavaScript analytics library from a third-party CDN. How do you verify its integrity?

A — Check that the CDN uses HTTPS — encrypted transport guarantees the file hasn't been tampered with

B — Add a Subresource Integrity (SRI) hash to the script tag so the browser rejects modified files

C — Verify the CDN provider's reputation and only use well-known providers like Cloudflare or AWS

// knowledge check

2 / 3

What makes A08 (Integrity Failures) different from A03 (Supply Chain Failures)?

A — A08 covers only deserialization attacks, while A03 covers everything else in the dependency chain

B — A03 covers upstream compromise of dependencies. A08 covers integrity failures within your own environment

C — A08 is the newer category introduced in 2025, while A03 has existed since the 2017 OWASP Top 10 list

// knowledge check

3 / 3

A Java application deserializes user-provided data using ObjectInputStream. What's the primary risk?

A — Arbitrary code execution — the attacker crafts a serialized object that runs commands on deserialization

B — Data corruption — the deserialized object will have incorrect field values that break application logic

C — Memory exhaustion — large serialized objects consume all available heap space and crash the JVM

// self-check complete

// the mental model

carry this into your next pipeline review

A valid signature proves the signer signed it. It doesn't prove the signer wasn't compromised. Integrity requires verification at every trust boundary — not just at the front door.

A08 · Software or Data Integrity Failures

Scope in 2025

Unsigned updates · CDN trust · insecure deserialization · CI/CD tampering

▶

A08 holds #8 in 2025 with 14 CWEs mapped, 501K occurrences, and 3,331 CVEs. Key CWEs: CWE-829 (inclusion from untrusted sphere), CWE-494 (download without integrity check), CWE-502 (deserialization of untrusted data), CWE-915 (mass assignment). The scope explicitly covers integrity failures at a lower level than A03's supply chain focus — your own build, update, and serialization trust boundaries.

First fix

Verify every artifact's integrity before execution — SRI, checksums, signatures

▶

For app developers: Add integrity attributes (SRI hashes) to all CDN-loaded scripts. Never deserialize untrusted data with native serializers (Java ObjectInputStream, Python pickle) — use allowlists or prefer JSON/protobuf. Validate all external data before processing. For platform teams: Verify checksums of Docker images before deployment. Sign build artifacts and verify signatures before distribution. Implement build isolation and provenance attestation. Both sides own integrity.

A08 vs A03

A03 = upstream (dependencies) · A08 = your environment (builds, updates, data)

▶

A03 covers compromises in upstream dependencies and build systems — the xz Utils backdoor, malicious npm packages. A08 covers integrity failures within your own environment — trusting build artifacts without verification, deserializing user-controlled data, loading CDN scripts without SRI, accepting updates without signature checks. The 3CX case spans both: the upstream X_TRADER compromise is A03, but 3CX's failure to verify the software on the employee's machine and to protect its build servers is A08.

// check your integrity boundaries today

Five things you can verify right now.

CDN scripts have SRI hashes

Every <script> from a CDN should have an integrity attribute. Check your HTML head.

Docker images pinned by digest

Using :latest or :v3? Pin to sha256 digest. Tags are mutable.

Build server access controls

Who can access your build servers? Are they isolated from developer workstations?

No native deserialization of user input

Are you using ObjectInputStream, pickle, or Marshal on untrusted data? Switch to JSON.

Auto-update verification

Does your application verify update signatures before applying them?

0 / 5