A08:2025 - Software or Data Integrity Failures: When Trusted Code Becomes a Trojan Horse

Understanding Software or Data Integrity Failures in 2025

Software or Data Integrity Failures continues at number eight in the OWASP Top 10:2025, with a slight clarifying name change from Software and Data Integrity Failures. This refinement emphasizes the category's focus on the failure to maintain trust boundaries and verify the integrity of software, code, and data artifacts at a lower, more granular level than Software Supply Chain Failures covered in A03.

While A03 addresses compromises upstream in dependencies and build systems the acquisition and distribution of third-party components A08 focuses on integrity failures within your own environment. This includes making assumptions related to software updates and critical data without verifying integrity, even when the supply chain itself remains intact. Unauthorized changes, tampered artifacts, unsigned binaries, and unverified data all fall under this category.

The category encompasses 36 Common Weakness Enumerations, with notable entries including CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes), and CWE-502 (Deserialization of Untrusted Data). Software and data integrity failures relate to code and infrastructure that does not protect against invalid or untrusted code or data being treated as trusted and valid.

What makes these failures particularly insidious is that they rarely cause functional errors. The application still works perfectly it just now operates on the attacker's terms. A compromised configuration file might quietly enable debug endpoints. A tampered serialized object could grant elevated privileges. The system functions flawlessly while serving malicious purposes.

The Anatomy of Integrity Failures

Software or data integrity failures manifest when applications fail to protect against integrity violations in several key areas.

• Unsigned or Unverified Software Updates
  • Many applications now include auto-update functionality where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations. Many home routers, set-top boxes, device firmware, and other embedded systems do not verify updates via signed firmware. Unsigned firmware is a growing target for attackers and is expected to only get worse.
  • This is a major concern because many times there is no mechanism to remediate other than to fix in a future version and wait for previous versions to age out. The window of vulnerability extends indefinitely for devices that never receive updates or where users don't apply them promptly.
• Insecure Deserialization
  • Deserialization vulnerabilities occur when untrusted input is processed by an application's deserialization routines, potentially allowing attackers to craft malicious serialized objects that execute arbitrary code upon deserialization. Objects or data that are encoded or serialized into a structure that an attacker can see and modify are vulnerable to insecure deserialization.
  • The classic example involves Java serialization where attackers notice signatures like rO0 (base64-encoded Java object marker) and use tools like Java Serial Killer to gain remote code execution. However, deserialization vulnerabilities affect virtually every programming language and serialization format—Python pickle, PHP serialize, .NET BinaryFormatter, Ruby Marshal, and more.
• Inclusion from Untrusted Sources
  • Applications that rely upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks without integrity verification create exploitable trust boundary violations. A company might use an external service provider for support functionality with DNS mapping like myCompany.SupportProvider.com to support.myCompany.com. This means all cookies, including authentication cookies set on the myCompany.com domain, will now be sent to the support provider. Anyone with access to the support provider's infrastructure can steal cookies and perform session hijacking attacks.
  • Loading JavaScript libraries from CDNs without Subresource Integrity checks allows a compromised CDN to inject malicious code into thousands of applications simultaneously. The convenience of external hosting becomes a single point of failure affecting your entire security posture.
• Insecure CI/CD Pipelines
  • An insecure continuous integration and continuous deployment pipeline can introduce the potential for unauthorized access, malicious code injection, or system compromise. Build systems like Jenkins are now prime targets, as demonstrated by the SolarWinds Orion attack where attackers compromised the build environment to inject malicious code that was signed and distributed as legitimate updates.
  • CI/CD pipelines that deploy binaries without signature verification allow tampered artifacts to reach production. Insufficient segregation between build stages, inadequate access controls, and missing audit logs create opportunities for attackers to modify code flowing through deployment processes.
• Improper Object Modification
  • CWE-915 describes improperly controlled modification of dynamically-determined object attributes, often called mass assignment or object injection vulnerabilities. Attackers manipulate request parameters to modify object properties that should be protected, potentially escalating privileges, bypassing security controls, or corrupting data.
  • A classic example involves user profile updates where an attacker adds an isAdmin=true parameter to the request, and the application blindly assigns this to the user object without validating which attributes should be modifiable. These vulnerabilities are invisible until runtime and can trigger unintended logic flows or privilege escalation.

Real-World Attacks: The Cost of Integrity Failures

The consequences of software and data integrity failures extend far beyond theoretical risks, with devastating real-world impacts throughout 2024 and 2025.

• SolarWinds Web Help Desk: The Triple-Patch-Bypass Saga
  • SolarWinds Web Help Desk has become a case study in the difficulty of completely remediating deserialization vulnerabilities, suffering three consecutive critical flaws—each a bypass of the previous patch attempt.
  • In August 2024, SolarWinds released a hotfix for CVE-2024-28986, a critical deserialization remote code execution vulnerability with a CVSS score of 9.8. The vulnerability existed in the AjaxProxy component and allowed unauthenticated remote attackers to execute arbitrary code on affected installations. CISA added this flaw to its Known Exploited Vulnerabilities catalog following active exploitation.
  • In October 2024, Trend Micro's Zero Day Initiative discovered CVE-2024-28988, another 9.8-rated deserialization bug that bypassed the CVE-2024-28986 patch. The ZDI team discovered an unauthenticated attack during their research, demonstrating that the initial fix had not comprehensively secured the deserialization logic.
  • Then in September 2025, CVE-2025-26399 emerged—the third iteration of the same fundamental flaw. With a CVSS score of 9.8, this vulnerability represents a patch bypass of CVE-2024-28988, which itself bypassed CVE-2024-28986. The repeated bypasses indicate that the deserialization logic in AjaxProxy was not comprehensively secured, with each patch iteration failing to address all exploitable code paths or gadget chains.
  • The root cause lies in the AjaxProxy module processing serialized Java objects without proper validation. An attacker can craft malicious serialized payloads that, when sent to the component, trigger arbitrary code execution. Because the vulnerability is unauthenticated, no valid credentials are required to launch an attack, making it particularly dangerous for internet-exposed instances.
  • As Ryan Dewhurst, head of proactive threat intelligence at watchTowr, noted: SolarWinds is a name that needs no introduction in IT and cybersecurity circles. The infamous 2020 supply chain attack left a lasting mark on the industry. And now here we are with yet another patch addressing the very same flaw. Third time's the charm? Given SolarWinds' past, in-the-wild exploitation is highly likely.
  • The SolarWinds saga demonstrates a critical lesson: integrity failures at the code level particularly around deserialization are extraordinarily difficult to fix completely. Superficial patches that address specific attack vectors without fundamentally redesigning the vulnerable component lead to an endless cycle of discoveries and bypasses.
• The 3CX Supply Chain Attack: A Cascading Compromise
  • In March 2023, the world witnessed the first publicly documented case of one supply chain compromise triggering another a cascading, two-stage intrusion that affected 12 million users worldwide.
  • The attack began when an employee at 3CX, a VoIP software company serving over 600,000 customers, downloaded a trojanized, end-of-life version of X_TRADER trading software from Trading Technologies' legitimate website. This compromised installer, signed with Trading Technologies' valid digital certificate, deployed the VEILEDSIGNAL backdoor.
  • Once inside 3CX's environment, attackers associated with North Korean state-sponsored group Lazarus (tracked as UNC4736) stole corporate credentials and moved laterally to compromise both Windows and macOS build environments for the 3CX Desktop App. They injected malicious DLLs into the legitimate, signed software that was then distributed to 3CX's massive customer base through normal update mechanisms.
  • The trojanized 3CX Desktop App (versions 18.12.407 and 18.12.416) contained malicious code that ran SUDDENICON downloader, which retrieved additional command and control servers from encrypted icon files hosted on GitHub. The final payload was an information stealer targeting browser data, with subsequent targeting focused on victims in defense and cryptocurrency sectors where secondary payloads like Gopuram were deployed.
  • The attack chain demonstrated remarkable sophistication. The compromised X_TRADER and 3CXDesktopApp applications both used identical techniques: the same RC4 encryption key, SIGFLIP tool leveraging CVE-2013-3900, DAVESHELL for reflective loading, and identical hardcoded cookie variables. This level of consistency across a multi-stage campaign spanning different vendors reveals careful planning and execution.
  • What makes this attack particularly relevant to A08 is the integrity failure at multiple points. Trading Technologies failed to protect the integrity of X_TRADER downloads on their website. 3CX failed to verify the integrity of third-party software before execution on developer machines. The 3CX build process failed to detect modifications to compiled binaries. Customers failed to validate the integrity of updates beyond checking digital signatures—which were valid because the legitimate signing infrastructure had been compromised.
  • Mandiant researchers noted this was the first time one software supply chain attack led directly to another, creating a supply chain chain reaction. The campaign began in late 2022 and wasn't disrupted until security vendors publicly reported the compromise in March 2023—demonstrating how long integrity failures can persist undetected when compromised systems function normally.
  • Following the breach, 3CX underwent a comprehensive security transformation, implementing binary analysis from ReversingLabs, static analysis from Coverity, engagement with bug bounty programs, and wholesale changes to CI/CD pipelines. As ReversingLabs emphasized, software integrity and transparency are paramount to avoiding such devastating attacks.
• The SolarWinds Orion Supply Chain Attack
  • While technically falling under A03 Software Supply Chain Failures due to its compromise of the development pipeline, the original 2020 SolarWinds Orion attack deserves mention as it demonstrates the catastrophic scale of integrity failures.
  • Nation-state actors compromised SolarWinds' build and update processes. The company had secure build and update integrity processes, but these were subverted, and for several months, the firm distributed a highly targeted malicious update to more than 18,000 organizations, of which around 100 were affected. This is one of the most far-reaching and significant breaches of this nature in history.
  • The attack succeeded because organizations trusted digitally signed updates from a reputable vendor without additional verification. The integrity failure wasn't in SolarWinds' design—the security processes were sound—but in their implementation and the lack of runtime verification that could have detected anomalous behavior even in signed software.

Detection Challenges: The Invisibility Problem

Unlike injection vulnerabilities or authentication failures that often produce observable errors, insecure design issues and integrity failures are the hardest to detect because they don't disrupt normal operations.

• Why Traditional Tools Miss Integrity Failures
  • Static Application Security Testing tools analyze source code but cannot detect integrity failures that manifest at runtime. SAST can identify potentially unsafe deserialization calls, but cannot determine whether the data being deserialized is trusted or untrusted in the deployment context. Software Composition Analysis identifies known vulnerabilities in dependencies but doesn't detect tampering or unauthorized modifications to those dependencies after they've been vetted.
  • Vulnerability scanners look for known CVEs and misconfigurations but cannot identify custom malware injected into otherwise legitimate code. Web Application Firewalls monitor traffic patterns but cannot distinguish between legitimate update mechanisms and compromised ones when both use valid protocols and signatures.
• The Need for Runtime Verification
  • This is why runtime testing is essential. Static scanners cannot detect what has changed at the behavioral level, but Dynamic Application Security Testing can. According to Acunetix security research, DAST provides the only way to validate trust in applications through runtime validation, detecting compromised third-party packages, CI/CD pipeline breaches, misconfigured systems allowing unauthorized change, and vulnerable serialization routines.
  • One of the most insidious aspects of software integrity breaches is that they don't usually cause functional errors. The application still works, but it's now operating on the attacker's terms. A compromised dependency might quietly transmit telemetry data. A manipulated update routine could create an unauthorized user account. Improperly handled deserialized objects may trigger subtle but harmful changes to internal logic—all without outward signs of malfunction.
  • Behavior-based DAST can flag unusual execution patterns after updates, identify whether crafted payloads lead to unsafe behavior in deserialization, and detect unintended logic flows or privilege escalation from improper object modification. These behavioral signatures only appear at runtime.

Prevention: Building Integrity into Your Systems

Preventing software and data integrity failures requires comprehensive security measures throughout the development and deployment lifecycle.

• Implement Digital Signatures and Verification
  • Use digital signatures or similar mechanisms to verify software or data is from the expected source and has not been altered. This applies to software updates, dependencies downloaded from package repositories, plugins and extensions, configuration files, and serialized data transmitted between systems.
  • For software updates, implement code signing with certificates from trusted certificate authorities. Generate checksums or cryptographic hashes for all artifacts. Verify signatures before installation or execution. Maintain a chain of custody for signing keys with strict access controls.
  • Beyond simply checking that a signature is valid, verify the expected signer. An attacker with a compromised certificate can create valid signatures that your system will accept. Maintain a whitelist of authorized signing certificates and alert on deviations.
• Secure Your CI/CD Pipeline
  • Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes. Implement the following controls:
  • Segregate build environments from development and production. Use separate credentials and access controls for each stage. Implement mandatory code review before merging to protected branches. Require multi-factor authentication for all build system access. Maintain comprehensive audit logs of all build activities and artifact changes. Use immutable artifact repositories where published builds cannot be modified. Generate and verify build attestations using frameworks like SLSA and in-toto to prove what was built, on which system, and by whom.
  • The principle is trust nothing without verification. Even code that passes through your CI/CD pipeline should be verified at deployment time to ensure no tampering occurred between build and release.
• Handle Serialization Securely
  • Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form of integrity check or digital signature to detect tampering or replay of the serialized data. Better yet, avoid serialization of sensitive data entirely when possible.
  • When serialization is necessary, use safe serialization formats like JSON that cannot execute code. Implement integrity checks using HMAC or digital signatures to detect tampering. Encrypt serialized data containing sensitive information. Validate all deserialized data against expected schemas. Implement allowlists of classes that can be deserialized. Consider using safe serialization libraries designed to prevent code execution.
  • For languages particularly vulnerable to deserialization attacks like Java, Python, PHP, and .NET, consider replacing dangerous serialization mechanisms entirely. Java should avoid ObjectInputStream, Python should avoid pickle with untrusted data, PHP should validate serialize/unserialize operations, and .NET should deprecate BinaryFormatter in favor of safe alternatives.
• Verify External Dependencies
  • Use libraries and dependencies only from trusted sources. Verify integrity using package checksums, signatures, or software bill of materials. Implement Subresource Integrity for third-party JavaScript loaded from CDNs. Pin dependency versions rather than using floating version ranges that could silently introduce compromised updates.
  • Maintain a software bill of materials documenting all components, their versions, and their sources. Regularly scan dependencies for known vulnerabilities using SCA tools. Monitor for unexpected changes in dependency behavior or network traffic.
  • When downloading dependencies, use package managers' built-in verification rather than direct downloads from websites. npm, pip, Maven, and other package managers support signature verification and integrity checks—use them consistently.
• Implement Runtime Monitoring and Anomaly Detection
  • Deploy application monitoring that can detect unusual behaviors indicating compromise. This includes unexpected network connections to external hosts, privilege escalation attempts, unusual file system access patterns, creation of unauthorized user accounts or processes, and deviation from established baselines of normal application behavior.
  • DAST tools continuously test deployed behavior to identify exploitable vulnerabilities and compromised components. Unlike SAST and SCA which provide point-in-time assessments, runtime monitoring provides ongoing validation that deployed systems behave as expected.
  • Behavioral analysis can detect when legitimate signed software begins exhibiting malicious behavior—such as the 3CX Desktop App making unexpected network connections or the SolarWinds Orion module accessing systems it shouldn't.
• Regular Security Assessments
  • Conduct regular security assessments including penetration testing focused on integrity controls, red team exercises simulating supply chain compromises, code reviews specifically examining update mechanisms and deserialization, and assessment of CI/CD pipeline security.
  • These assessments should attempt to answer: Can we inject malicious code into our build pipeline? Can we tamper with artifacts between build and deployment? Can we modify production configurations or binaries? Are deserialization endpoints protected against malicious payloads? Do our update mechanisms properly verify signatures and integrity?
  • External assessments provide an adversarial perspective that internal teams often miss. Fresh eyes may identify integrity gaps that have become normalized through familiarity.

Framework Adoption: SLSA and Beyond

Several frameworks provide structured approaches to software and data integrity.

• Supply-chain Levels for Software Artifacts
  • SLSA (Supply-chain Levels for Software Artifacts) is a security framework providing a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. It defines multiple levels of increasing security maturity:
  • SLSA Level 1 requires documentation of the build process. Level 2 adds tamper resistance to the build service. Level 3 requires extra resistance to specific threats. Level 4 provides the highest level of confidence by including two-person review of all changes.
  • Organizations should assess their current SLSA level and work toward higher levels incrementally. The framework provides concrete steps for improving build integrity regardless of starting point.
• NIST Secure Software Development Framework
  • The NIST SSDF provides practices for building secure software throughout the development lifecycle. It emphasizes preparing the organization by defining security requirements, ensuring adequate resources and training, and implementing secure development practices, protecting the software from vulnerabilities through secure coding, code review, and testing, producing well-secured software by generating comprehensive documentation, maintaining build and artifact integrity, and securing distribution, and responding to vulnerabilities discovered in deployed software through coordinated disclosure, patching, and lessons learned.
  • The framework integrates well with SLSA and other security standards, providing comprehensive coverage of the software development lifecycle.
• Software Bill of Materials
  • Maintaining an accurate, up-to-date SBOM provides visibility into all components comprising your software. This enables rapid identification of affected systems when vulnerabilities are disclosed, detection of unauthorized component modifications, validation that dependencies come from expected sources, and assessment of compliance with licensing requirements.
  • SBOMs should be generated automatically as part of the build process and signed to prevent tampering. They should include direct dependencies and transitive dependencies, version information with hashes, source repositories and download locations, and known vulnerabilities present in each component.

Development Team Responsibilities

Addressing software and data integrity failures requires organizational cultural changes alongside technical controls.

• Security as a Development Priority
  • Development teams face unique challenges. Malicious code can slip in unnoticed through third-party dependencies or pull requests, especially in fast-paced collaborative environments. A compromised build system might deploy unsafe versions to production without altering source code, making detection difficult. Flawed serialization or update routines can open doors to logic manipulation or remote execution.
  • Organizations must foster cultures where security is a first-class concern, not an impediment to velocity. This means allocating time for security activities in sprint planning, recognizing and rewarding security contributions, empowering developers to raise security concerns, and providing training on secure coding practices and emerging threats.
  • The self-responsibility of developers is often underappreciated. Foster a culture of awareness, responsibility, and proactive risk mitigation where developers understand they are the first and most important line of defense.
• Secure by Default, Secure by Design
  • Design systems to be secure by default, requiring explicit action to disable security controls rather than requiring explicit action to enable them. Update mechanisms should verify signatures by default. Serialization should use safe formats by default. External dependencies should require integrity verification by default.
  • This principle shifts security from an opt-in feature developers might forget to enable to an opt-out protection that requires deliberate action to disable, making security the path of least resistance.

Security Team Perspectives

Security teams face their own set of challenges with integrity failures.

• Limitations of Traditional Tools
  • Traditional tools like SAST and SCA are limited in scope and often fail to detect integrity issues that only manifest at runtime. This makes it difficult to distinguish between theoretical risks and actual exploitable vulnerabilities, especially when triaging alerts. Without testing deployed behavior, it becomes nearly impossible to identify and manage supply chain risks effectively.
  • A DAST-first approach focuses teams on what actually matters: what's really running and whether it can be exploited. For security teams, DAST enables validation of deployed configurations and behavior, detection of anomalous runtime activity, assessment of actual rather than theoretical vulnerabilities, and continuous verification rather than point-in-time assessment.
• Risk-Based Prioritization
  • Not all integrity failures carry equal risk. Security teams must assess which systems are most critical to protect, which attack vectors are most likely given the threat landscape, which remediation efforts provide the most risk reduction, and which vulnerabilities are actually exploitable vs. theoretical.
  • This requires understanding the business context, not just technical severity. A critical CVSS score in a component only accessible from trusted networks carries less urgent risk than a medium severity flaw in an internet-facing update mechanism.

Lessons from Major Attacks

The major integrity failures of recent years provide clear lessons organizations can apply.

• From the SolarWinds Web Help Desk Triple-Bypass
  • Deserialization vulnerabilities are extraordinarily difficult to fix comprehensively. Patch bypasses are common when fixes address specific attack vectors without fundamentally redesigning the vulnerable component. Organizations should assume that deserialization endpoints will be repeatedly targeted and plan accordingly.
  • The lesson: Avoid deserializing untrusted data entirely when possible. When unavoidable, implement defense in depth with allowlists, monitoring, and runtime verification rather than relying solely on input validation.
• From the 3CX Cascading Attack
  • Trust nothing without verification, including software from reputable vendors with valid digital signatures. Verify the integrity of software before execution, even on developer machines. Implement behavioral monitoring that can detect compromise even when signatures are valid. Segregate build environments and limit what can run there.
  • The lesson: A single compromised developer machine can cascade into a massive supply chain attack. Endpoint security, privileged access management, and build environment isolation are critical controls.
• From the Original SolarWinds Orion Attack
  • Even organizations with mature security practices can be compromised through integrity failures. Build environment compromise can be extraordinarily difficult to detect. Monitoring should include behavioral analysis, not just signature-based detection. Organizations should implement zero-trust principles even for internal build systems.

The lesson: Trust but verify. Signed updates from trusted vendors should still be monitored for anomalous behavior at runtime.

The Path Forward

✅ Software or Data Integrity Failures at position eight in the OWASP Top 10:2025 represents an escalating threat as attackers increasingly target the gray areas between secure code and secure deployment. The category's distinction from Software Supply Chain Failures reflects the need for organizations to address integrity at multiple levels both in acquiring and distributing third-party components and in maintaining integrity of their own systems and processes.

✅ The challenge is that integrity failures don't usually cause functional errors. Applications work perfectly while serving malicious purposes. This invisibility makes detection extraordinarily difficult without comprehensive runtime monitoring and behavioral analysis.

✅ Prevention requires combining multiple complementary security controls: digital signatures and verification, secure CI/CD pipelines with segregation and access controls, safe handling of serialization and deserialization, verification of external dependencies, runtime monitoring and anomaly detection, regular security assessments and penetration testing, and adoption of frameworks like SLSA, NIST SSDF, and SBOM practices.

✅ Organizations must shift security left into pre-code activities like requirements and design, but also shift right into runtime verification and continuous monitoring. The traditional security testing paradigm of point-in-time assessments is insufficient for integrity failures that may only manifest under specific runtime conditions or after specific update operations.

✅ For development teams, this means treating integrity as a first-class design requirement, implementing secure defaults rather than opt-in protections, and fostering cultures of security awareness and responsibility. For security teams, this means adopting DAST-first approaches that validate deployed behavior, implementing risk-based prioritization, and moving beyond theoretical vulnerability lists to focus on exploitable issues.

✅ The repeated SolarWinds Web Help Desk patch bypasses demonstrate that superficial fixes for fundamental architectural weaknesses lead to endless cycles of discovery and remediation. The 3CX cascading attack shows how trust failures compound across organizational boundaries, turning one vendor's compromise into another's catastrophic breach.

✅ As applications grow more complex with microservices, cloud platforms, third-party integrations, and AI components, the attack surface for integrity failures expands. Organizations that fail to implement comprehensive integrity verification will find themselves compromised by attacks they never detected because the compromised systems functioned perfectly for the adversary.

✅ The future of application security requires treating integrity not as a post-deployment concern but as a fundamental requirement throughout software lifecycles. By verifying integrity at every stage from development through deployment to runtime—organizations can detect and prevent the silent compromises that leave systems working flawlessly while serving malicious masters.

✅ Build integrity in, verify continuously, and trust nothing without verification. These aren't just security best practices they're survival requirements in a landscape where software integrity failures enable attackers to compromise thousands of organizations with a single malicious update.