Software and Data Integrity Failures is the risk that code or data is trusted without verifying it has not been tampered with, and it ranks number eight on the OWASP Top 10 (2021). This category was brand new in 2021, created to capture the software supply chain era: automatic updates that install unsigned code, build pipelines that anyone can inject into, and applications that deserialize untrusted data straight into live objects. It also absorbed the former Insecure Deserialization category. The unifying idea is that integrity, not just confidentiality, must be proven, because an attacker who can substitute your code or your data controls your application as surely as one who steals a password.
What OWASP A08 actually covers
The category covers three closely related failures. The first is using software from untrusted sources or updating it without verifying integrity, such as an auto-updater that downloads a new binary over an insecure channel or without a signature check. The second is insecure deserialization, where an application reconstructs objects from attacker-controlled bytes and thereby lets the attacker instantiate arbitrary types or trigger code during the process. The third is compromised continuous-integration and continuous-delivery pipelines, where the path from source to production can be tampered with to inject malicious changes. The mapped weaknesses include CWE-502 (deserialization of untrusted data), CWE-345 (insufficient verification of data authenticity), and CWE-494 (download of code without integrity check).
Why it is a new and rising category
A08 exists because the industry's threat model shifted. For years the assumption was that your own build and your own dependencies were trustworthy and the danger lived at the network edge. A wave of supply chain attacks demolished that assumption, and OWASP responded by ranking the category eighth on incidence data while noting that it carried one of the highest weighted impact scores in the entire list. When integrity fails, it fails at scale: a single tampered update or poisoned build reaches every customer at once, which is why the category punches far above its position number.
Real-world examples
The SolarWinds SUNBURST incident of 2020 is the defining A08 event. Attackers compromised the build pipeline for the Orion network-management product and inserted a backdoor into a legitimately signed update, which then flowed to roughly eighteen thousand organizations through the normal, trusted update channel. Nothing about the delivery looked wrong because the malicious code rode inside an artifact everyone had been trained to trust. On the deserialization side, CVE-2017-9805 is a classic: the Apache Struts REST plugin deserialized untrusted XML through XStream, letting a remote attacker achieve code execution simply by posting a crafted payload. Both cases share the A08 fingerprint, which is that the system verified who was speaking or that the format parsed, but never verified that the content itself was safe to trust.
Vulnerable versus fixed code
Insecure deserialization is the most reproducible A08 flaw, and Python's pickle module is the canonical trap.
# VULNERABLE: pickle executes arbitrary code during load
import pickle
def load_profile(raw_bytes):
# attacker-controlled bytes -> arbitrary code execution
return pickle.loads(raw_bytes)
# FIXED: parse a data-only format that cannot instantiate code
import json
def load_profile(raw_bytes):
# json produces plain data structures, never live objects
return json.loads(raw_bytes.decode("utf-8"))
The vulnerable version is dangerous because pickle is not a data format, it is an object-construction language, and reconstructing an object can invoke methods that an attacker chooses. Switching to a data-only format such as JSON removes the code-execution primitive entirely. When you genuinely must deserialize rich objects, sign the payload and verify the signature before parsing, and restrict which types may be reconstructed rather than accepting anything on the wire.
Prevention checklist
- Verify digital signatures on all software updates, packages, and downloaded code before installing or executing them.
- Never deserialize untrusted data into live objects; prefer data-only formats like JSON and validate against a schema.
- Pull dependencies only from trusted repositories, and pin versions with lockfiles to prevent silent substitution.
- Harden your CI/CD pipeline: enforce least privilege, review pipeline configuration changes, and protect signing keys.
- Generate and check a software bill of materials so you know exactly what your build produced and shipped.
- Use subresource integrity for third-party scripts loaded in the browser.
- Ensure unsigned or unverified data does not flow to clients without an integrity check.
- Separate the systems that build artifacts from the systems that sign them so one compromise is not enough.
How Safeguard helps
Integrity failures are supply chain failures, and that is Safeguard's core. The SCA engine generates a complete software bill of materials from your build, maps every direct and transitive component against current advisories, and flags dependencies pulled from untrusted or tampered sources, which is exactly how deserialization-gadget libraries and poisoned packages get caught before they ship. When a vulnerable component is found, Auto-Fix opens a reviewable pull request that resolves the full dependency graph rather than a single manifest line, and Griffin AI explains why the change matters and whether the flaw is reachable in your code. For teams weighing a consolidated platform against point tools, our comparison hub lays out how integrity, SBOM, and remediation fit together in one workflow.
Frequently Asked Questions
What is insecure deserialization in plain terms?
It is trusting a stream of bytes enough to rebuild program objects from it. Serialization turns objects into a portable format, and deserialization reverses that, but some deserializers can construct any type and run code during the process. If those bytes come from an attacker, they effectively hand the attacker a way to run their own logic inside your application, which is why formats like Python pickle or unrestricted Java object streams are dangerous on untrusted input.
How is A08 different from A06, Vulnerable and Outdated Components?
A06 is about running components with known, published vulnerabilities, whereas A08 is about failing to verify integrity at all, even for code that has no known CVE. A tampered but otherwise current dependency, an unsigned update, or a poisoned build pipeline are A08 problems because the issue is unverified trust rather than a known flaw. In practice the two overlap heavily, and a strong supply chain program addresses both together.
Why was SolarWinds so hard to detect?
Because the malicious code arrived through the trusted update channel inside a properly signed artifact. Defenders had been taught that a valid signature meant the code was safe, but the compromise happened upstream in the build pipeline, before signing, so the signature certified tampered code. It is the clearest argument for separating build from signing, monitoring pipeline integrity, and treating your own supply chain as an attack surface.
Can a software bill of materials prevent integrity failures?
An SBOM does not stop tampering by itself, but it is the foundation that makes detection possible. Knowing exactly which components and versions your build produced lets you verify them against advisories, spot unexpected or unsigned additions, and respond quickly when a dependency is later found to be compromised. Without that inventory you cannot even ask whether what you shipped is what you intended.
Ready to see and verify everything in your build? Start scanning at app.safeguard.sh/register, or read the setup guide at docs.safeguard.sh.