OWASP Top 10 A08 Guide: Software or Data Integrity Failures (2025): Verifying Code, Updates and Data

Applications routinely run code and act on data they never verified: an update from a server, a script from a CDN, a serialised object from a client, an artefact from a build cache. A08:2025 Software or Data Integrity Failures is the OWASP Top 10 category for code and infrastructure that let untrusted code or data be treated as trusted. It covers unsigned updates, plugins and libraries pulled from untrusted sources, CI/CD pipelines without integrity checks, insecure deserialisation and cookies trusted without validation. This guide goes deeper than the OWASP Top 10 Guide on what the 2025 category contains, the controls that close it, the signing keys and pipeline credentials it depends on, and how to evidence it. It is for application security engineers, platform and build engineers, and assessors.

Key takeaways

• Same rank, one-word rename. The 2025 edition calls the category "Software or Data Integrity Failures" (previously "Software and Data Integrity Failures"), still at number 8, with 14 CWEs mapped.
• A08 is the application's trust decision, A03 is the supply chain. OWASP places A08 at a lower level than A03:2025 Software Supply Chain Failures: it is about whether this code verifies what it loads, executes or deserialises.
• Verify before use, every time. Signatures or hashes on updates, packages, artefacts and third-party scripts, checked by the consumer, are the core control.
• Deserialisation remains a remote code execution path. CWE-502 is a notable CWE in the category; do not deserialise native formats from untrusted sources, and restrict types before parsing, not after.
• Integrity rests on identities. Signing keys, publishing tokens and CI/CD credentials are non-human identities; if they leak, signatures prove nothing.

What it is and who it applies to

OWASP describes A08:2025 as failure to maintain trust boundaries and verify the integrity of software, code and data artefacts. Its focus is assuming that software updates and critical data are trustworthy without checking. The published statistics for the category are 14 CWEs, a maximum incidence rate of 8.98%, an average incidence rate of 2.75%, average coverage of 45.49%, 501,327 total occurrences and 3,331 CVEs. OWASP names CWE-829, CWE-915 and CWE-502 as notable.

It applies to anyone who ships or runs software that loads something from outside its own trust boundary: web applications including third-party JavaScript, services that accept serialised objects, products with auto-update, CI/CD pipelines that pull dependencies and artefacts, and device firmware.

The boundary with A03 matters for ownership. A03 covers the wider ecosystem of dependencies, build systems and distribution; A08 is the specific check the application or pipeline fails to make. See the OWASP Top 10 A03 Guide and the Software Supply Chain Security Guide.

Structure and key requirements

The 14 mapped CWEs group into five patterns.

OWASP's prevention list, with the implementation detail from the referenced cheat sheets and ASVS 5.0:

• Signatures and hashes: use digital signatures or similar mechanisms to confirm software or data comes from the expected source and has not been altered. Verify on the consumer side, against a key or identity pinned in advance, not one supplied with the download. See the Code Signing Security Guide.
• Trusted repositories: restrict package managers such as npm and Maven to trusted repositories; higher-risk environments can host a vetted internal mirror. ASVS V15.2.4 requires third-party components and their transitive dependencies to come from the expected repository.
• Review: require review of code and configuration changes so a single person or token cannot introduce a malicious change.
• Pipeline segregation: enforce segregation, configuration and access control in CI/CD so integrity holds through build and deploy. See the CI/CD Security Guide.
• Serialised data: do not accept unsigned or unencrypted serialised data from untrusted clients without an integrity check or signature that detects tampering or replay. ASVS V1.5.2 requires an allowlist of object types or restriction of client-defined types.
• Third-party web resources: ASVS V3.6.1 covers externally hosted client-side assets; the browser mechanism is Subresource Integrity, an integrity attribute carrying a sha256, sha384 or sha512 hash, with crossorigin set for cross-origin loads. A mismatch blocks the resource with a network error.
• Mass assignment: ASVS V15.3.3 requires limiting the fields a controller will bind, which closes CWE-915.

Deserialisation by language

The OWASP Deserialization Cheat Sheet gives specific settings. Prefer pure data formats such as JSON for anything crossing a trust boundary, and restrict types before the parser runs; checking the type afterwards is too late because code may already have executed. See the Insecure Deserialisation Guide.

Identity and NHI requirements

Every integrity control in A08 depends on a credential. A signature is only as trustworthy as the key that made it, and a pipeline's review gate is only as strong as the tokens that can bypass it. That makes signing keys, package publishing tokens and CI/CD service identities the assets to protect first.

• Signing keys: keep private keys in an HSM or managed key service, limit who and what can request a signature, and log every signing operation. Keyless signing with Sigstore removes the long-lived key: Cosign obtains a short-lived certificate from Fulcio bound to an OIDC identity, and the signature is recorded in the Rekor transparency log, so verifiers check the expected signer identity rather than a key file. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Publishing tokens: replace long-lived registry tokens with OIDC-based publishing from the build platform where the registry supports it, and scope any remaining token to one package. See the npm Tokens Security Guide.
• Pipeline identities: give each pipeline its own short-lived federated identity, keep secrets out of environment variables visible to every step, and separate build from deploy credentials. See the CI/CD Pipeline Identity Security Guide.
• Server-side signing secrets: the keys that sign cookies, tokens and serialised state are integrity controls too. Store them in a vault (ASVS V13.3.1) and rotate them; a leaked cookie-signing key turns CWE-565 protection into nothing.

The Codecov breach joins both halves: a cloud storage key exposed through a Docker image build error let an attacker alter the Bash Uploader script for about two months, and that script then sent CI environment variables, including tokens and keys, to the attacker. A customer found it by comparing the script with its published checksum.

Implementation steps

1. Map what you load. List every update channel, third-party script, dependency source, artefact store and endpoint that accepts serialised data. Record for each whether integrity is verified today.
2. Fix deserialisation first. Search code for the sinks in the table above, replace native formats at trust boundaries with JSON, and add type allowlists where native formats must stay. This is the fastest route to removing remote code execution risk.
3. Add Subresource Integrity to third-party scripts. Generate hashes for pinned versions, add integrity and crossorigin, and self-host scripts that change without notice. MDN documents an Integrity-Policy-Report-Only header to find scripts lacking integrity metadata before enforcing.
4. Lock dependency sources. Point package managers at an internal mirror or approved registries, commit lock files with hashes, and fail builds on unexpected sources.
5. Sign and verify artefacts. Sign container images and release artefacts in the pipeline and verify signatures at deployment through an admission controller or deploy step. Start in audit mode, which logs unsigned artefacts, then enforce per environment, beginning with production.
6. Generate provenance. Aim for SLSA Build Level 2 (signed provenance from a hosted build platform) and then Level 3 (hardened builds where user-defined steps cannot reach signing secrets). SLSA v1.2 is the approved current specification and adds a Source track.
7. Protect the pipeline. Require reviewed merges to protected branches, pin third-party actions to commit hashes, and restrict who can change pipeline definitions.
8. Verify updates in products. Ship auto-update with signature verification against a pinned key, and reject downgrades.
9. Roll back safely. Keep signature enforcement switchable per environment with a documented break-glass path that is logged and time-limited, so a broken signing service does not block an emergency fix.

Small versus large organisations: a small team gets most of the value from removing native deserialisation, adding SRI, committing lock files and using the build platform's built-in OIDC publishing and signing. A large organisation should run an internal registry, enforce signature verification at admission across clusters, and track SLSA levels per product, with a central team owning signing infrastructure.

Evidence and assessment

Detection and metrics. Monitor signature verification failures at deployment, SRI and integrity-policy violation reports, new dependency sources appearing in builds, changes to pipeline definitions, signing operations outside normal pipelines and deserialisation errors in application logs. ATT&CK techniques to tune detections against include T1195.002 Compromise Software Supply Chain, T1195.001 Compromise Software Dependencies and Development Tools, T1553.002 Code Signing and T1554 Compromise Host Software Binary. Useful KPIs:

• Percentage of production deployments with verified signatures.
• Percentage of external scripts protected by SRI or self-hosted.
• Number of native deserialisation sinks reachable from untrusted input (target zero).
• Percentage of builds at SLSA Build Level 2 or higher.
• Long-lived publishing and signing credentials remaining (trend to zero).

Mapping to other frameworks

Common pitfalls

• Checksums published but never checked. Downloading a script with curl and piping it to a shell skips the verification step entirely. In the Codecov breach the published checksum would have caught the change on day one.
• Reviewing the repository, not the release. In the XZ Utils backdoor the malicious build macro and payload were in the release tarballs, not the git source most reviewers read. Build from verified source, or compare release artefacts with the tagged source.
• Verifying against a key shipped with the download. If the public key or hash comes from the same server as the file, an attacker who controls one controls both. Pin keys or signer identities in advance.
• Type checks after deserialisation. Casting the result to an expected class does not help; gadget chains run during parsing.
• Unpinned third-party actions and scripts. Referencing a tag or "latest" lets an upstream change run in your pipeline or page. Pin to commit hashes or integrity hashes. See the GitHub and GitHub Actions Security Guide.
• Signing keys with broad access. A key reachable from every build job, or stored as a pipeline variable, gives any compromised step the ability to sign malware.

Practitioner checklist

• Inventory update channels, third-party scripts, dependency sources and endpoints that accept serialised data.
• Remove native deserialisation of untrusted input; where unavoidable, enforce type allowlists before parsing.
• Add Subresource Integrity with crossorigin to every third-party script and stylesheet, or self-host.
• Restrict package managers to approved registries and commit lock files with hashes.
• Sign images and release artefacts and enforce verification at deployment, starting in audit mode.
• Produce signed build provenance and track SLSA Build levels per product.
• Pin third-party pipeline actions to commit hashes and require reviewed merges.
• Hold signing keys in an HSM or use keyless signing; replace long-lived publishing tokens with OIDC.
• Bind controller fields explicitly to stop mass assignment.
• Alert on signature failures, new dependency sources and signing outside the pipeline.

Standards and references

• OWASP: A08:2025 Software or Data Integrity Failures
• OWASP: Deserialization Cheat Sheet
• OWASP: Application Security Verification Standard 5.0
• OpenSSF: SLSA Specification v1.2
• Sigstore: Overview
• MDN: Subresource Integrity
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Compromise Software Supply Chain

Related NHI Mgmt Group resources: OWASP Top 10 Guide · OWASP Top 10 A07 Guide · SBOM Guide · Top 10 CI/CD Security Risks · Code Signing Security Guide