Software and data integrity failures happen when applications trust code, data, or artifacts without verifying where they came from or whether they've been tampered with. This category covers a lot of ground: unsigned software updates, insecure deserialization, compromised CI/CD artifacts, and any place where "we trust this" is implicit instead of verified.

Integrity failures often overlap with supply chain failures, which we covered in module three. The distinction is useful. Supply chain is about the attacker compromising something upstream of you. Integrity is about whether your own system notices. If you have strong integrity controls, even a compromised upstream source gets caught before it executes. If you don't, you're flying blind.

Let me walk through what integrity failures actually look like.

Untrusted external services with too much access. A company uses an external support provider. They map a subdomain, something like "support dot my company dot com," to the support provider's infrastructure. Because it's the same parent domain, cookies set on "my company dot com," including authentication cookies, get sent to the support provider on every request. Anyone with access to the support provider's systems can read those cookies and hijack user sessions. This isn't a malicious insider problem. It's a design problem. The trust relationship was wider than the architect intended.

Unsigned firmware. Home routers, set-top boxes, consumer-grade IoT devices often don't verify that firmware updates are signed by the manufacturer. An attacker with network access can push malicious firmware, and the device installs it without complaint. Once installed, there's often no detection mechanism and no remediation path other than waiting for the device's eventual replacement.

Untrusted package sources. A developer can't find the version of a library they need on the official package registry, and they download it from a random third-party site instead. There's no signature to verify. No checksum. No way to know whether the code is what it claims to be. The package runs with the same privileges as the application, so if it contains malicious code, the developer has just imported a backdoor into the codebase.

Insecure deserialization. This one is technical but worth knowing. A React front-end sends serialized Java objects back and forth with a Spring Boot microservice. An attacker notices the base 64 payload starts with the characters r-O-zero, which is the recognizable signature of a Java serialized object. They feed that payload to a tool like Java Deserialization Scanner, and they get remote code execution on the server. Deserialization of untrusted data is one of the most dangerous patterns in application security, and it keeps reappearing because it's convenient for developers.

So how do you defend against integrity failures? A few patterns.

First, sign everything and verify signatures. Software releases should be signed by the publisher. Your build pipeline should sign its artifacts. Deployment should verify those signatures. This is cryptographic integrity, and it's the single strongest defense against the entire category.

Second, use trusted repositories exclusively. Pull dependencies from official registries over secure connections. For higher-risk environments, host an internal mirror that you've vetted, and require all builds to pull from it.

Third, harden your CI/CD pipeline. Segregation of duties. Access control. Integrity controls on the code as it flows through build and deploy. The pipeline itself is production infrastructure, and an attacker who compromises it gets to ship malicious code to every customer.

Fourth, never deserialize untrusted data. If you absolutely must, apply an integrity check or digital signature to the serialized payload, so tampering can be detected before deserialization runs.

Fifth, for web pages that load third-party JavaScript, use sub-resource integrity hashes. SRI lets the browser refuse to execute a script if its content hash doesn't match what you declared in the HTML. Cheap to add, widely under-used.

Integrity failures are quiet when they happen and loud when they don't. Signed artifacts, verified deployments, and never trusting untrusted data are the patterns that turn this category from a catastrophic risk into a mostly-solved problem.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.