Simple: everyday language, with no technical background needed.
Understand it
Integrity failures occur when software or important data is trusted without adequate verification that it is authentic and unchanged.
Cedar’s updater receives a package over a transport connection but never checks its expected publisher or integrity. A substituted artifact can become trusted executable code.
Under the hood
Verify updates and serialized data at the trust boundary. An unkeyed hash detects changes only when the expected hash itself arrives through a trustworthy path. A signature also needs a trusted signer policy.
Practitioner perspective
Separate supply-chain inventory from integrity verification of a particular artifact. Plan key rotation and revocation, protect update metadata and avoid unsafe deserialization of untrusted objects. Authenticity does not prove that signed software has no vulnerabilities.
Watch it work
A fictional, simplified model. Select a component to inspect it, or follow the steps in order.
Explore the system
Update received
Cedar’s updater receives a package over a transport connection but never checks its expected publisher or integrity. A substituted artifact can become trusted executable code.
Read every step without animation
Failure path
- Update received. Cedar’s updater receives a package over a transport connection but never checks its expected publisher or integrity. A substituted artifact can become trusted executable code.
- No verification. Integrity failures occur when software or important data is trusted without adequate verification that it is authentic and unchanged.
- Code trusted. A checksum next to an untrusted download is not independent proof of authenticity.
The intended security boundary is not enforced.
Defensive path
- Trusted metadata. Verify artifacts against trusted publisher metadata before use.
- Signature verified. Verify updates and serialized data at the trust boundary. An unkeyed hash detects changes only when the expected hash itself arrives through a trustworthy path. A signature also needs a trusted signer policy.
- Policy-controlled install. Separate supply-chain inventory from integrity verification of a particular artifact. Plan key rotation and revocation, protect update metadata and avoid unsafe deserialization of untrusted objects. Authenticity does not prove that signed software has no vulnerabilities.
The improved path addresses the specific failure; verify it in your environment.
Attack view
Cedar’s updater receives a package over a transport connection but never checks its expected publisher or integrity. A substituted artifact can become trusted executable code.
Defender view
- Verify artifacts against trusted publisher metadata before use.
- Verify the expected allowed and denied outcomes in a controlled environment.
Common mistakes
- A checksum next to an untrusted download is not independent proof of authenticity.
- A valid signature proves a signing relationship, not that the signed behavior is safe.
Check your understanding
Active recall: explain this idea in 30 seconds
Integrity failures occur when software or important data is trusted without adequate verification that it is authentic and unchanged.
Now give an example and name one limitation. Revisit the explanation if you get stuck.
Primary sources
Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.
Content reviewed 2026-09-10. Framework reference: OWASP Top 10 2025. Read the editorial policy.