Software and data integrity failures—ranked A08 in the OWASP Top 10—are no longer edge cases. They’re an escalating threat across modern web ecosystems, as attackers increasingly target the gray areas between secure code and secure deployment.
For security teams, the challenge is validating trust in the applications they’re tasked with protecting. For developers, the question is whether the components, pipelines, and behaviors they’re shipping are safe and verifiable. The answer lies in runtime validation—something only dynamic application security testing (DAST) can provide.
What integrity failures actually are
These failures occur when an application uses software or data that has been tampered with or introduced from an untrusted source. They’re often invisible to static testing tools and can include compromised third-party packages, CI/CD pipeline breaches that modify build artifacts, misconfigured systems that allow unauthorized change, and vulnerable serialization routines, to name just a few.
These are not traditional code-level bugs but flaws in how software is assembled, delivered, or trusted.
OWASP CWEs that signal software and data integrity risks
Here are some key CWEs tied to A08 that dynamic scanning can help detect:
CWE-502 (Deserialization of untrusted data): In many cases, DAST can identify whether crafted payloads lead to unsafe behavior.
CWE-494 (Download of code without integrity check): Behavior-based DAST can flag unusual execution patterns after updates.
CWE-915 (Improper object modification): Often invisible until runtime, these can trigger unintended logic flows or privilege escalation.
Why integrity failures matter for dev and security teams alike
For development teams, integrity issues can introduce major risks even when processes appear sound. 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 the source code, making detection difficult. Additionally, flawed serialization or update routines can open the door to logic manipulation or even remote execution, leaving applications vulnerable to targeted attacks.
Security teams face a different but equally critical set of challenges. 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. Moreover, without testing deployed behavior, it becomes nearly impossible to identify and manage supply chain risks effectively.
A DAST-first approach focuses everyone on the only thing that ultimately matters: what’s really running and whether it can be exploited.
Real-world examples of integrity failures
The 3CX breach (2023)
A trusted update for the 3CX VoIP app was compromised at build time and signed before distribution. Tens of thousands of customers installed the backdoored update. Source code security couldn’t have prevented this, but DAST, with its runtime scanning and behavior analysis, could potentially have flagged anomalous activity from the compromised build.
Codecov pipeline attack (2021)
Attackers modified a Bash script used in CI workflows to exfiltrate credentials. The code change passed unnoticed for weeks. Developers did nothing wrong—but without validation at the artifact level, the breach went undetected.
Event-Stream npm hijack (2018)
An abandoned dependency was updated with malicious logic targeting Bitcoin wallet users. The package was downloaded millions of times before being discovered.
Each of these incidents illustrates how trust in the software lifecycle can be exploited—and how those exploits evade traditional scanning tools.
The hidden danger: Failure without failure
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, and improperly handled deserialized objects may trigger subtle but harmful changes to internal logic—all without any outward signs of malfunction or vulnerability.
This is why runtime testing is essential. Static scanners can’t detect what’s changed at the behavioral level—but DAST can.
What DAST-first means for joint dev-sec responsibility
A DAST-first strategy doesn’t eliminate other tools but rather aligns the organization around what’s observable and actionable.
For development teams, DAST serves as a safeguard against introducing behavioral risks during changes or deployments. By getting results generated with proof-based scanning, developers can quickly determine whether an identified issue is real, avoiding time wasted on false positives. Running scans in staging environments ensures that potential problems are addressed early, before they can reach production.
For security teams, DAST provides assurance that the software running in production remains secure, even after moving through complex automated pipelines. Instead of dealing with overwhelming volumes of alerts, they receive verified vulnerability reports they can act on with confidence. DAST also makes it possible to detect subtle behavioral anomalies—such as data exfiltration or tampering—that might be invisible to static tools.
Together, both teams can shift from passive risk identification to active risk management.
Checklist for reducing software integrity risks
- Secure and monitor your CI/CD pipelines:
- Restrict access to build and deployment tools
- Sign and verify artifacts at every stage
- Use ephemeral environments to reduce persistent attack surfaces
- Use trusted and monitored third-party components:
- Source you code from reputable repositories
- Maintain and monitor your own internal mirrors for high-risk packages
- Perform SBOM tracking to flag unapproved libraries
- Integrate DAST into your development workflow:
- Scan staging environments as part of QA
- Use runtime insights to guide unit and integration tests
- Feed DAST results into developer tooling with proof-of-exploit to accelerate remediation
- Look for signs of tampering at runtime:
- Unexpected data flows, authentication bypasses, or unlogged activity are red flags
- Monitor APIs, serialized data, and update paths with dynamic tools
- Leverage DAST to catch violations in business logic that static analysis can’t model
Ensuring software integrity requires engineering and security collaboration
Software and data integrity failures are not just another vulnerability category but rather a warning that our assumptions about trust and safety in the SDLC are outdated. Security teams need evidence. Developers need clarity. DAST delivers both—provided your DAST tool of choice provides accurate and actionable results.
Adopting a DAST-first approach based around proof-based results from tools like Acunetix and Invicti completely changes the way you think about application security:
- Developers see less noise in their security tickets and gain confidence that they’re fixing real issues.
- Security teams cut down on manual work and improve posture with runtime visibility and automated validation.
- The organization as a whole reduces risk by focusing on actual, exploitable threats, not theoretical or non-existent vulnerabilities.
You can’t prevent every vulnerability—but with the DAST-first approach, you can catch what matters before attackers do.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
