OWASP Top 10 – A08: Software and Data Integrity Failures

The eighth item in the OWASP Top 10 is Software and Data Integrity Failures. This category covers a wide range of issues related to trusting software, updates, configurations, or data without proper integrity checks.

It includes everything from supply chain attacks to insecure CI/CD pipelines, misconfigured update systems, and unverified data sources. At first, it seemed very technical, but the more I read, the more I realized how critical and relevant it is for real-world software development.

Below are my learning notes and key takeaways

What Are Software and Data Integrity Failures?

This vulnerability arises when a system relies on the integrity of software or data but doesn’t properly verify or protect that integrity.

For example, if a system:

Automatically installs software updates without signature verification,
Executes scripts or binaries from untrusted sources,
Applies configurations from unauthenticated files or URLs…

…then an attacker could manipulate these sources and inject malicious behavior into the application — often without triggering alarms.

Why Is This Dangerous?

These attacks often don’t break the system — they exploit the way it’s supposed to work.
Software supply chain attacks often stem from this category.
CI/CD pipelines, auto-update mechanisms, external config sources — all of them are high-risk entry points if not properly protected.
The worst part: they’re hard to detect because the application appears to function normally, just with compromised behavior.

The goal is silent compromise — the attacker changes the behavior without breaking the system.

Real-World Scenarios I Studied

1. Supply Chain Compromise in a Major Software Vendor

An attacker injected malicious code into a legitimate software update distributed to customers. Once the update was installed, backdoor access was silently granted across thousands of systems.

2. Malicious Code in Open Source Packages

A widely-used package in a public repository was modified to include malicious scripts. Developers unknowingly imported the updated version into their CI/CD workflows.

3. External JS via Script Tags

Some websites load JavaScript directly from external CDNs without integrity checks. If the CDN is compromised, every site using that script is exposed.

4. Unverified Inputs in CI/CD Pipelines

A pipeline pulls config files or environment variables from an external location without authentication or validation. An attacker who gains access to that source can alter deployments.

When Are You at Risk?

If software updates are installed without verifying digital signatures.
If CI/CD workflows run code or scripts from uncontrolled sources.
If third-party libraries or dependencies are pulled dynamically and blindly.
If config files are edited outside of version control and not validated before use.
If file downloads or imports happen automatically with no integrity verification.

How to Prevent These Issues

1. Verify Software Updates

Use digitally signed packages whenever possible (e.g., GPG, SHA256 checks).
Avoid auto-updating from unsigned or unauthenticated sources.

2. Secure CI/CD Pipelines

Audit who can modify or push changes to your build processes.
Treat pipeline scripts, secrets, and environment files as code — version, protect, and monitor them.
Log every step and verify outputs before deploying.

3. Validate Third-Party Scripts and Dependencies

If loading JS from a CDN, always use the integrity attribute and set crossorigin.
Pin exact versions of dependencies in package managers (npm, pip, etc.).

4. Use File Integrity Checks

Use hashes to verify the contents of files before using them — especially from untrusted sources.
Implement checks for config files, templates, or uploaded content.

5. Track All Code and Scripts in Version Control

Avoid “just drop this script in” practices. Everything that runs in production should be versioned and reviewable.

Best Practices

Practice	Why It Matters
Use signed and verified updates	Protects against supply chain compromise
Limit CI/CD access and audit changes	Prevents unauthorized modifications
Use `integrity` for external scripts	Detects CDN tampering
Test pipeline outputs before deployment	Detects malicious code injection during builds
Apply file integrity monitoring	Catches unexpected changes to critical assets

How to Test for It

CI/CD Pipeline Security Review: Who can push, build, and deploy? Are logs and approvals enforced?
File Integrity Monitoring: Are critical files being modified unexpectedly?
Third-party Dependency Audit: Where do libraries come from, and are they validated?
Package Hash Verification: Are downloaded artifacts checked before use?

Who’s Responsible?

Developers:

Be cautious about importing libraries or code from external sources.
Use validated, reviewed, and versioned dependencies in build processes.

DevOps Engineers:

Ensure CI/CD systems are hardened and secure.
Implement change control, logging, and access restrictions.

Security Teams:

Monitor for unusual behaviors in pipeline outputs and config files.
Periodically audit dependencies and update processes.

This topic taught me something important:

Code isn’t just what you write — it’s also where it comes from.

As projects grow, dependencies multiply. CI/CD pipelines automate everything. And every “convenient shortcut” (like skipping a signature check or trusting a file source blindly) becomes a potential breach point.

If you don’t enforce software and data integrity, an attacker doesn’t need to break in — you’ll install them yourself.