Accueil / retour à la liste

Software and Data Integrity Failures

8) Software and Data Integrity Failures

What it is

This means your system trusts code or data without verifying it is genuine and untampered.

Simple idea:

  1. Your app downloads/runs something.
  2. It assumes it is safe.
  3. No strong integrity check is done.
  4. Attacker swaps it with malicious content.
  5. Your system runs attacker content as if it were trusted.

Easy mental model

Think of medicine delivery:

  1. You receive a pill bottle.
  2. If seal is broken and label can be faked, you should not trust it.
  3. If you take it anyway, risk is high.

Integrity controls are that “seal.”

Common examples

  1. Installing dependencies/updates without signature verification.
  2. CI/CD pipeline can be modified by unauthorized users.
  3. Build artifacts are not signed.
  4. Auto-update pulls from insecure source.
  5. Webhooks/events are accepted without verifying sender signature.
  6. Insecure deserialization of untrusted data.
  7. Package registry account takeover publishes malicious version.

Step-by-step attack examples

Example A: Malicious package update (supply chain)

  1. Your app depends on package abc.
  2. Attacker compromises maintainer account or package repo.
  3. Attacker publishes poisoned version.
  4. Your pipeline auto-updates and installs it.
  5. Build succeeds and deploys.
  6. Malicious code runs in production.

Example B: CI/CD pipeline tampering

  1. CI runner or pipeline config is weakly protected.
  2. Attacker changes build script.
  3. Script injects backdoor into release artifact.
  4. Artifact is deployed to customers/internal systems.
  5. Everyone trusts it because it came from “official pipeline.”

Example C: Insecure deserialization

  1. App accepts serialized object from user/session/message queue.
  2. App deserializes it directly into executable object graph.
  3. Crafted payload triggers unexpected code path.
  4. Attacker gets code execution or privilege escalation.

Tricky concepts explained

1) Integrity vs confidentiality

  1. Confidentiality = keep data secret.
  2. Integrity = keep data unmodified and authentic.

You can have encrypted data (confidential) that is still fake/tampered if integrity checks are missing.

2) Hash vs digital signature

  1. Hash tells you “content changed or not.”
  2. Signature tells you “who created it” plus “not changed.”

Important:

  1. If attacker can replace both file and hash file, plain hash check is useless.
  2. Signature with trusted public key is much stronger.

3) Provenance

Provenance means traceable origin:

  1. Who built this artifact
  2. From which source commit
  3. In what trusted environment

Without provenance, incident response is blind.

4) Deserialization risk

Deserialization turns bytes/text into objects. If format allows complex objects and attacker controls input, dangerous methods/chains may execute.

How to prevent it (practical order)

  1. Require signed packages/artifacts and verify signatures in CI and deploy stages.
  2. Use pinned versions and lockfiles; avoid uncontrolled auto-updates.
  3. Protect CI/CD with least privilege, branch protection, mandatory reviews, and MFA.
  4. Isolate build runners and protect secrets (short-lived tokens, no plaintext secrets in logs).
  5. Sign build artifacts and verify before deployment.
  6. Verify webhook/event signatures and reject unsigned or invalid requests.
  7. Avoid native deserialization of untrusted data; use simple formats (JSON) with strict schema validation.
  8. Restrict who can publish internal packages; require MFA for registry maintainers.
  9. Keep SBOM/provenance records for each release.
  10. Monitor for unusual dependency, pipeline, and artifact changes.

Detection checklist

  1. Can we prove every deployed artifact came from trusted CI?
  2. Are artifacts/package updates signature-verified?
  3. Are pipeline changes tightly controlled and audited?
  4. Do we block unsigned webhooks/events?
  5. Do we deserialize any untrusted object formats?
  6. Can we trace production binary back to exact commit and build job?

Business impact

  1. Large-scale backdoor insertion.
  2. Full production compromise from “trusted” updates.
  3. Silent long-term persistence by attackers.
  4. High blast radius because poisoned builds affect many systems.