Software or data integrity failures can start with the tiniest change: sometime ago, engineers at a company I supported pushed a very small update to production. Nothing major – just a regular release. But soon after, customers began reporting odd errors. Alerts didn’t show malware or a known attack. Everything seemed normal on the surface.
When we looked deeper, we found the issue:
A single npm dependency had automatically updated to a version with almost the same name. One letter was different. That tiny change caused:
- New code to run that no one reviewed
- A hidden script to collect sensitive usage data
- The CI/CD pipeline to trust a malicious package as if it were safe
No red flags. No warnings. The final software wasn’t the same software developers approved.
This is what OWASP A08:2025 – Software or Data Integrity Failures is all about:
Something trusted is changed behind the scenes – and nobody notices.This is exactly what software or data integrity failures look like in real life.
What Are Software or Data Integrity Failures in Simple Words?
Your business expects code and data to remain safe from tampering.
An integrity failure is when that trust is broken.
Examples:
- A build system pulls an unsafe file
- A script from a third-party website is replaced
- A configuration changes during deployment
- Software updates aren’t checked properly
Even small hidden changes can lead to major security incidents.
Real Examples (That Could Happen Anywhere)
Example 1 – Lookalike Dependency Tricked the Pipeline
- Build system updated a dependency without approval
- Attackers added a hidden script to steal information
- No alarms because the change happened after code review
Lesson: Final product must match the reviewed code
Example 2 – “Safe” JSON Leads to Server Takeover
- App loads preferences from the database
- Developer used a risky function that can execute code
- Hacker edits that data → gains control of the server
Lesson: User-controlled data can be dangerous if not checked.
Example 3 – Firmware Updates Without Verification
- IoT devices downloaded updates over insecure HTTP
- Man-in-the-middle replaced firmware with a backdoor
- Thousands of home devices were silently compromised
Lesson: Updates must always be secure and verified.
Why Old Security Thinking Isn’t Enough
| Old belief | Why it fails today |
|---|---|
| “We sign the code.” | Attackers target the build system, not the developers. |
| “We check hashes.” | You might be checking the wrong file (source vs release). |
| “We use HTTPS.” | Internal systems often skip certificate checks. |
| “We pin dependencies.” | Tools still auto-update transitive dependencies. |
Attackers go upstream now – supply chain, build pipeline, updates, storage.
How to Defend Against Software or Data Integrity Failures
| Protection | What It Prevents |
|---|---|
| Reproducible builds | Any change in final output gets blocked. |
| Sign the actual build artefacts | Verifies the exact code users receive. |
| Subresource Integrity in browsers | Ensures scripts aren’t replaced. |
| Safe data handling | No more automatic code execution from files. |
| No unexpected dependency changes | CI breaks when versions drift. |
| Validate firmware / containers | Only trusted images run. |
| Runtime hash monitoring | Detects if files change after deployment. |
These reduce the risk of invisible modifications.
Quick Integrity Checklist (Easy to Start)
Follow these steps to stop software or data integrity failures before they hit production.
- Every build must be verified before release
- Final output must match what was reviewed
- Unsafe deserialization functions removed
- External scripts have hash checks
- Devices use secure boot and signed updates
- Rollbacks only allow approved versions
Share this checklist with DevOps and development teams.
Where to Insert Integrity Checks in the Pipeline
Developers → Reviewed code → Signed commit
↓
CI Build → Confirm exact output → Sign build result
↓
Artefact Storage → Safe logs of signatures
↓
Deployment → Verify before installing anywhere
↓
Runtime → Watch for any unexpected changesSecurity must follow the whole journey of the code.ach step prevents software or data integrity failures from sneaking in.
What to Expect in the Future
- AI coding tools might introduce risky code accidentally
- Quantum computers will force stronger signing methods
- Old backups and archived code could be modified years later
We must protect both new software and historical releases.
Key Takeaways
- Code integrity failures often look like normal bugs
- Small changes can cause big impact
- Security must follow the entire software pipeline
- Don’t assume trust – verify it
- If your software can change without you noticing – attackers already have a way in.
