Software and data integrity failures are increasingly common and dangerous cybersecurity vulnerabilities, recognized as web application security risk category A08:2021 in the OWASP Top 10. These failures occur when critical application updates, dependencies, or data pipelines are not properly validated or protected, opening the door to tampering, unauthorized changes, or supply chain attacks.
With attackers increasingly targeting CI/CD pipelines, open-source components, and update mechanisms, it’s more important than ever to secure your web app’s code and data integrity. This article goes through the dangers of software and data integrity failures and shows how a defense-in-depth approach that also incorporates a continuous vulnerability scanning process can minimize the risk of compromise.
Software and data integrity failures happen when systems don’t adequately protect against unauthorized changes to code, configuration, or data. This could mean an application downloads a malicious software update, runs tampered scripts, or unquestioningly accepts altered input from an untrusted source.
At their core, these issues result from trusting components or processes without verifying their integrity. This makes it possible for attackers to manipulate software behavior, inject malicious code, or compromise sensitive operations.
While there’s a lot of practical overlap between the two risk categories and they both relate to the software supply chain, they focus on different core concerns. In short, A08:2021 is about tampering and trust issues, while A06:2021 is about exposure due to neglect or outdated components.
More specifically, software and data integrity failures involve issues where software updates, critical data, or CI/CD pipelines are not properly protected against integrity violations. This category focuses on trust boundaries being breached, such as unauthorized access to build processes, compromised dependencies, or misconfigured deployment systems that allow malicious changes.
In contrast, the Vulnerable and Outdated Components category refers specifically to the use of libraries, frameworks, or other software modules that are known to have security flaws or are no longer supported. This category is about the inherent risks of running components with known vulnerabilities (often due to lack of visibility or asset management), not necessarily a breach of integrity during their use.
Probably the most notorious example is the SolarWinds supply chain attack. After infiltrating the development pipeline, attackers inserted malicious code into a trusted software update for a network monitoring tool, which was then distributed to thousands of organizations, including government agencies. The compromised update gave attackers remote access to critical systems and went undetected for months.
More recently, the Polyfill security crisis saw a third party buy the CDN used to distribute a trusted and popular JavaScript library and use it to serve a version containing malicious code to websites that relied on that library. More general examples include:
Unlike simple misconfigurations, these failures affect the trust model of your entire software lifecycle. If attackers can tamper with code, data, or deployment processes, they can:
These types of attacks are hard to detect and can have far-reaching consequences that go far beyond a “regular” data breach, especially when third-party components or automation tools are involved.
The key to mitigation is reducing trust in unverified sources and ensuring robust validation across your software delivery lifecycle. This means applying security controls not just at the perimeter or in production but throughout the entire build and deployment process.
These problems are especially dangerous because they’re often overlooked or simply not present during traditional testing.
To prevent integrity failures, organizations must focus on visibility, validation, and control across their code, data, and the entire software pipeline. Key security measures include:
Most integrity failures surface only when applications are running. Static security tools like SAST or SCA might detect some issues, but they can’t prove whether exploitable vulnerabilities are actually present—unlike dynamic application security testing (DAST). For integrity violations that introduce security misconfigurations or other vulnerabilities to serve as backdoors, taking a DAST-first approach helps minimize risk by testing what you’re actually running, including any vulnerable components that you might not be aware of.
When used as part of a comprehensive zero-trust application security program, a DAST scanner can help you identify many cases where:
On Invicti’s DAST-first platform specifically, proof-based scanning is used to automatically confirm many exploitable vulnerabilities to cut through false positives and focus your teams’ efforts where they matter most. Instead of reacting to theoretical risks flagged in build time, you address actual threats in runtime—where attackers live.
Software and data integrity failures strike at the heart of trust in modern development. As applications become more complex and reliant on automation, third-party code, and cloud infrastructure, the risk of tampering increases.
To stay ahead of threats, your application security strategy must validate not only what’s in your code but also how that code behaves in the real world. A DAST-first approach supported by software inventory best practices and extensive automation enables you to find and fix the issues that attackers can actually exploit.