Software or data integrity failures happen when an application trusts code, updates, or data without verifying where they came from or whether they were altered in transit. Testing for OWASP A08:2025 Software or Data Integrity Failures means proving, not assuming, that your CI/CD pipeline, deserialization logic, and auto-update mechanisms reject tampered inputs before they execute.
TL;DR
- Testing software or data integrity failures means manually attacking CI/CD pipelines, deserialization endpoints, and auto-update mechanisms, not scanning for signatures.
- Unsigned software updates and insecure deserialization remain the two highest-impact entry points under OWASP A08:2025 in 2026 engagements.
- PCI DSS 4.0, SOC 2, and ISO 27001 all require evidence that update and build-pipeline integrity controls were tested, not just documented.
- Scanners flag deserialization sinks but cannot prove exploitability; gadget chain viability depends on the target runtime classpath.
- AppSecure's hacker-led testing chains integrity gaps into remote code execution and supply chain compromise scenarios during every engagement.
Why This Matters
A08:2025 sits at the intersection of application security and supply chain risk. When an application deserializes untrusted data, pulls an unsigned dependency, or applies an update without verifying its source, an attacker does not need to breach your perimeter. They need to compromise something you already trust.
The 2020 SolarWinds compromise and the repeated npm and PyPI package-hijacking incidents since then trace back to the same root failure: no cryptographic verification of what was being installed or executed. Regulators noticed. PCI DSS 4.0, SOC 2 Type II audits, and ISO 27001 surveillance reviews now expect assessors to confirm that build pipelines and update mechanisms were tested for tampering resistance, not merely documented in a policy binder.
For engineering leaders, the business impact is direct. An integrity failure in a CI/CD pipeline gives an attacker a foothold in every downstream deployment, not one application instance. A single unsigned artifact promoted to production reaches every customer running that release. That is why manual penetration testing, not automated scanning, is the only reliable way to validate this category — a principle that also governs software supply chain failures testing, the adjacent OWASP category sharing much of the same attack surface.
The cost asymmetry is what makes A08 a board-level concern in 2026. Fixing an unsigned build pipeline costs a sprint. Remediating a compromised release that shipped to 4,000 tenants costs incident response, forensic retention, customer notification, and in regulated sectors, mandatory supervisory reporting.
What OWASP A08:2025 Software or Data Integrity Failures Covers
A08:2025 addresses any scenario where an application assumes integrity instead of verifying it. That includes insecure deserialization of untrusted objects, CI/CD pipelines lacking signed commits or protected branches, auto-update clients fetching binaries over unauthenticated channels, and third-party libraries pulled without checksum or signature validation.
CI/CD pipeline
- Integrity Failure: Unsigned build artifacts
- Typical Root Cause: No commit signing, unprotected build agents
Deserialization endpoints
- Integrity Failure: Object injection
- Typical Root Cause: Native deserializers on untrusted input
Auto-update mechanisms
- Integrity Failure: Malicious update injection
- Typical Root Cause: HTTP delivery, no signature check
Package management
- Integrity Failure: Dependency confusion
- Typical Root Cause: No internal registry priority, no lockfile pinning
Data pipelines
- Integrity Failure: Unverified data ingestion
- Typical Root Cause: No checksum or hash validation on ETL inputs
Plugin and webhook loaders
- Integrity Failure: Runtime code injection
- Typical Root Cause: External code executed without provenance checks
How A08 Differs From Neighboring Categories
A08:2025 is frequently confused with two other OWASP entries, and the distinction changes how you scope the test.
Cryptographic failures concern weak, missing, or misapplied encryption. Integrity failures concern whether tampering is detectable at all. An application can use TLS 1.3 everywhere and still accept an unsigned update — encryption in transit proves confidentiality, not provenance.
Injection categories concern malformed or hostile input parsed by an interpreter. Integrity failures often involve payloads that are perfectly well-formed. The serialized object is valid; the failure is trusting who sent it.
Where Integrity Assumptions Hide
Most integrity failures are inherited rather than written. A team adopts a deployment tool that caches artifacts without verifying them, a mobile SDK that self-updates, or an ETL job that ingests partner files by FTP. None of these appear in application source code review, which is why attack surface mapping has to extend past the repository.
How to Test for Software and Data Integrity Failures
Manual testers approach A08:2025 as a trust-boundary problem. Every point where code, configuration, or data crosses from an untrusted party — a contributor, a package registry, an update server, an API consumer — into a trusted execution context is a candidate for testing.
Step 1: Scope and Prerequisites
Define what is authorized before testing begins: the CI/CD pipeline including build agents, artifact repositories and deployment scripts; any deserialization-capable endpoints; the update or patch delivery mechanism; and third-party dependency management.
Obtain explicit written authorization covering production-adjacent systems such as build servers. These sit outside standard web application scope in most statements of work, and testing them without written permission is out of bounds. Confirm rollback procedures with the platform team before any pipeline tampering test runs.
Step 2: Attack Surface Mapping
Map every location where the application accepts serialized objects, executes fetched code, or applies updates:
- API endpoints accepting serialized payloads (Java
ObjectInputStream, PHPunserialize(), Pythonpickle, .NETBinaryFormatter) - Build pipeline stages: source checkout, dependency resolution, artifact signing, deployment approval
- Auto-update clients embedded in desktop, mobile, or IoT software
- Webhook and plugin architectures loading external code at runtime
- Data ingestion jobs pulling files or feeds from partners and vendors
- Container image pull policies and registry trust configuration
Cookie values, hidden form fields, cache entries, and message queue payloads are common deserialization carriers that never appear in an API specification. Decode every opaque token you encounter; base64 blobs beginning with rO0 (Java) or AAEAAAD (.NET) are immediate leads.
Step 3: Test Cases and Exploitation Techniques
Deserialization
- Manual Technique: Inject crafted gadget chains matched to the target classpath
- Business Impact if Exploited: Remote code execution on application server
CI/CD pipeline
- Manual Technique: Attempt unsigned commit merge, tamper with build cache
- Business Impact if Exploited: Malicious code shipped to all customers
Auto-update
- Manual Technique: Intercept update check over unauthenticated channel
- Business Impact if Exploited: Silent malware delivery to installed base
Dependency resolution
- Manual Technique: Register a package matching an internal name on a public registry
- Business Impact if Exploited: Code execution inside the build environment
Digital signatures
- Manual Technique: Strip or replace the signature on an update package
- Business Impact if Exploited: Update accepted without valid provenance
Artifact promotion
- Manual Technique: Modify a binary between build and deploy stage
- Business Impact if Exploited: Untested code reaching production
Every test case should be attempted manually with a working proof of concept, never flagged from a scanner signature. Automated tools routinely miss deserialization gadget chains because exploitability depends on the exact classes loaded in the target classpath, which only a tester who has mapped the runtime environment can determine.
Step 4: Evidence Capture
Document the exact payload, the injection point, the response indicating successful tampering — a shell callback, a modified file hash, an unauthorized deployment — and a screenshot or packet capture showing the bypass.
Evidence must demonstrate the full chain from injection to impact, not a triggered stack trace. An error message proving a deserializer ran is a finding worth reporting; a callback proving code executed is a finding engineering will prioritize this sprint.
Step 5: False-Positive Checks
Before reporting, confirm three things. The deserialization sink is genuinely reachable with attacker-controlled input, not behind an authentication layer the tester already held credentials for. The update mechanism has no out-of-band signature check performed after download. Pipeline tampering was not blocked by a control the test bypassed accidentally, such as reusing a cached artifact rather than triggering a fresh build.
A finding that survives all three checks is exploitable. A finding that fails any of them is a hardening recommendation, and labeling it correctly preserves credibility with the engineering team.
Step 6: Remediation Verification and Retesting
After the team patches — typically by migrating to safe serialization formats, enforcing signed commits, or adding cryptographic signature verification on updates — retest the original proof of concept. Then test a reasonable variant. Fixes that block one specific payload while leaving the sink reachable are common and give false assurance to compliance teams.
CI/CD Pipeline Integrity: The Highest-Value Target
CI/CD pipelines deserve dedicated attention because a single compromise propagates to every deployment downstream. Testers should attempt to merge unsigned commits, modify build scripts through misconfigured branch protection, and inject malicious dependencies through unpinned version ranges.
What Testers Look For in Build Systems
Build agents frequently hold production credentials, cloud roles, and signing keys in environment variables. A tester who can execute arbitrary commands during a build step — through a modified test script, a malicious dependency, or a pull request from a fork that triggers CI — inherits every one of those secrets.
Check whether pull requests from forks run with full pipeline privileges, whether the pipeline definition file itself is protected from modification in the same commit that runs it, and whether artifact repositories accept uploads from any authenticated agent rather than only from designated build identities.
Continuous Validation Beats Annual Testing
Organizations shipping multiple releases per week cannot validate pipeline integrity once a year and call the control tested. The pipeline changes faster than the audit cycle. Teams should integrate penetration testing into CI/CD pipelines so integrity checks run against the current deployment architecture rather than the one documented eleven months ago.
Compliance Mapping for A08 Findings
PCI DSS 4.0
- What It Requires: Change and integrity management for CDE components
- What Assessors Check: Evidence of signed builds, tested rollback controls
SOC 2 (CC7, CC8)
- What It Requires: Change management and system monitoring
- What Assessors Check: Documented testing of deployment pipeline integrity
ISO 27001 (A.8.19, A.8.32)
- What It Requires: Secure development and change control
- What Assessors Check: Test evidence tied to risk register entries
NIST SSDF (PW.4, PS.2)
- What It Requires: Verify software integrity before deployment
- What Assessors Check: Signature verification records, SBOM validation
DORA (ICT risk management)
- What It Requires: Resilience of ICT change processes
- What Assessors Check: Testing evidence for third-party and update dependencies
An auditor reviewing SOC 2 or ISO 27001 evidence in 2026 expects a dated penetration test report showing the pipeline and update mechanism were actively attacked. A policy stating that signatures are required is not evidence. Absent an attack narrative and a result, the control is recorded as unverified regardless of how the documentation reads.
What Compliance Teams Should Request From Testers
Ask for findings mapped to specific control identifiers, a stated scope covering build infrastructure by name, and retest results with dates. Reports that describe deserialization generically without naming the endpoint tested are not audit evidence — they are a summary.
Common Findings and Business Impact
- Unsigned build artifacts — an attacker with one compromised developer credential pushes code straight to production with no cryptographic barrier.
- Native deserialization left enabled — a known gadget chain in a bundled library becomes remote code execution with no additional exploitation work.
- Auto-update over plain HTTP — any network-position attacker delivers malware disguised as a routine patch to the entire installed base.
- No SBOM or dependency pinning — a single typosquatted package enters the build undetected and executes during install.
- Missing checksum validation on ingestion pipelines — manipulated partner data flows into production analytics or billing calculations.
- Shared build credentials across environments — a staging pipeline compromise grants production access laterally.
Each finding carries operational cost beyond the code fix: incident response hours, forensic log retention, customer notification obligations under breach disclosure law, and regulatory reporting in financial services and healthcare.
Software and Data Integrity Testing Checklist
- Signed commits enforced on all protected branches
- Deserialization of untrusted data disabled or replaced with schema-validated formats
- Auto-update mechanism enforces signature verification over an authenticated channel
- Dependency resolution pinned to internal registries with checksum validation
- SBOM generated and reviewed for every release
- Build agents isolated from production credentials and signing keys
- Fork-originated pipeline runs execute with reduced privileges
- Artifact provenance and rollback logging retained and reviewed
- Data ingestion jobs validate hashes before processing
- Retest performed and documented after each remediation cycle
How AppSecure Tests for Software and Data Integrity Failures
AppSecure's hacker-led penetration testing treats A08:2025 as a chaining problem, not a checklist item. Testers map the full path from an exposed deserialization sink or an unsigned update channel through to code execution and lateral movement, the same way a real adversary would.
This is manual attack-path discovery combined with business-logic abuse testing and privilege-boundary analysis: confirming not just that a gadget chain exists, but that it produces a working exploit against the specific application runtime and reaches something the business cares about. For SaaS platforms shipping frequent releases, integrity testing pairs with source code review services for SaaS platforms, because integrity failures often originate in code paths a static scanner never marks as reachable.
AppSecure reports findings with reproducible proof of concept steps, control mapping for the frameworks in scope, and a retest included after remediation.
Get your integrity controls tested
Manual, hacker-led testing of CI/CD pipelines, deserialization paths, and update mechanisms.
FAQ
What is OWASP A08:2025 Software or Data Integrity Failures?
A08:2025 covers vulnerabilities where an application fails to verify the integrity of code, updates, or data before trusting it. This includes insecure deserialization, unsigned CI/CD pipelines, and unauthenticated auto-update mechanisms.
How is A08 different from software supply chain failures?
Supply chain failures focus on third-party components and dependency provenance. A08 covers the broader integrity problem across CI/CD pipelines, deserialization, and update mechanisms, including but not limited to supply chain sources.
Can automated scanners detect software and data integrity failures?
Automated scanners rarely confirm exploitable deserialization gadget chains or CI/CD tampering paths. Exploitability depends on the exact runtime classpath and pipeline configuration, which requires manual analysis.
What is insecure deserialization and why does it matter?
Insecure deserialization occurs when an application reconstructs objects from untrusted input without validation. Attackers inject malicious object chains that execute code on the server, often without authentication.
Does PCI DSS 4.0 require testing for integrity failures?
PCI DSS 4.0 requires change and integrity management for cardholder data environment components. Assessors expect tested build and deployment pipeline controls, not policy documentation alone.
How often should CI/CD pipeline integrity be tested?
Test the pipeline whenever the deployment architecture changes materially and at minimum annually. Teams shipping multiple releases per week should validate integrity controls continuously.
What does a penetration tester check in an auto-update mechanism?
Testers check whether updates are delivered over an authenticated encrypted channel and whether the client cryptographically verifies a signature before applying the update. Stripping the signature should cause the update to fail closed.
How does SOC 2 map to software integrity testing?
SOC 2 criteria CC7 and CC8 require documented change management and system monitoring. Assessors expect penetration test evidence showing the deployment pipeline was actively tested for tampering resistance.
What is dependency confusion and how is it tested?
Dependency confusion occurs when a build system resolves a public package sharing a name with an internal one. Testers validate registry priority configuration and package resolution order in the build environment.
Who owns remediation for A08 findings?
Platform and DevOps teams typically own CI/CD pipeline fixes, while application developers own deserialization and update client remediation. Both should be coordinated through a shared retest cycle.
One Last Thing
Most teams patch the deserialization bug the tester found and stop there, leaving the CI/CD pipeline that shipped the vulnerable code completely unverified. The fix addresses the symptom. The trust boundary that allowed the code to ship unsigned is still open, and it will ship the next bug just as quietly.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.webp)
