Skip to content
Kodesec × Integrated-Systems.ai
KODESEC
Book a call

A08 · OWASP Top 10 · 3 min

Software and data integrity failures. Is it still what it claims to be?

Updates, files, scripts and saved data are trusted the moment they arrive. This is what happens when nobody checks the seal, and something changed on the way gets accepted as genuine.

I run a

In 10 seconds

Updates and data trusted without a check.

What it is

Your systems accept updates, files, scripts and saved data. If nothing verifies they're untampered and from the right source, a changed version is treated as the real thing.

Why you care

The change can be small: a swapped update, an edited price, an altered record. It runs or is believed with full trust, and can reach your names, addresses, phone numbers and purchase history or quietly change them.

What to do

Ask whether updates, builds and important data are verified before use, and who is able to change them.

For your business

What's at stake for you.

I run a

Who is affected

Your customers, and anyone who trusts you with their details.

What could leak

Names, addresses, phone numbers and purchase history.

Ask this first

“Are updates checked (signed) before they install, and who controls where they come from?”

Where it hides

Pick something your business trusts on arrival.

Every one of these is a package that someone could tamper with before it reaches you.

yourbusiness.com/updates/latest
What's here
Updates your systems and apps download and install, often automatically.
What goes wrong
Accepted without checking they're genuine, so a tampered update, or one from a hijacked server, installs with full trust.
Ask your team
Are updates checked (signed) before they install, and who controls where they come from?
Developers call it
Unsigned updates, missing code signing, insecure update channels

What it costs

Trusted by default, so damaging by default.

Full trust

A tampered update or file runs with your system's own permissions, which is more than an outsider would ever get.

Quiet

Small changes to a price, a record or a setting can go unnoticed until the damage is done.

Many at once

A poisoned update reaches every customer or system that installs it.

Hard to undo

If you can't prove what is clean, recovery can mean rebuilding from scratch.

For an online shop: one tampered update or altered record could expose or change names, addresses, phone numbers and purchase history.

Does this apply to you?

Tick what's true. Get your questions.

First

So the questions fit you

What kind of business do you run?

Real cases

The update was real. The contents weren't.

Compromised build, 2020

A signed update, with the attacker inside.

What it cost
It became one of the most studied breaches in history and fed into a May 2021 US executive order on improving cybersecurity, including software supply chain security.
The lesson
A signature proves who shipped the update, not that their build was clean. Verification only helps if the build itself is protected too.
Read the full story and sources

In 2020 attackers broke into SolarWinds' build system and inserted malicious code into updates of its Orion network-monitoring software. The updates were digitally signed by SolarWinds and went out to about 18,000 customers between March and June 2020. A much smaller number, including US government agencies and large companies, were then chosen for follow-up attacks. Security firm FireEye uncovered it in December 2020 after being affected itself.

It became one of the most studied breaches in history and fed into a May 2021 US executive order on improving cybersecurity, including software supply chain security.

Sources: SolarWinds statements, US CISA, Mandiant (FireEye).

Your part

Three decisions that are yours.

  1. 01Verify what you runRequire that updates, builds and key files are checked, signed or fingerprinted, before use, with no way to skip the check.
  2. 02Control who changes what shipsLimit and log who can alter your build and release process, and require a second person for changes to production.
  3. 03Be able to prove it's cleanKeep backups that can't be altered and test a restore regularly, so you can show what's genuine.
For your developer: the technical layer
  • Sign and verify artifacts and updates (code signing, tools such as Sigstore). Verify checksums and signatures of downloads and dependencies, and pin versions.
  • Protect the CI/CD pipeline: least privilege, separate build from deploy, protected branches, mandatory review, short-lived credentials. Record build provenance (for example SLSA) and keep an SBOM.
  • Use Subresource Integrity and a Content Security Policy for third-party scripts, or host critical scripts yourself.
  • Don't trust client state. Sign (HMAC) or encrypt cookies and tokens, validate token signatures and algorithms on the server, and keep sensitive state server-side.
  • Avoid deserialising untrusted data. Prefer simple formats such as JSON with strict schema validation and allow-listed types, and run parsers with low privileges.
  • Keep immutable, versioned backups with hash checks and an offline copy. Monitor file integrity on critical systems.
  • Log and alert on unexpected changes to builds, configuration and critical records.

Remember

Three things to keep.

  • Trust isn't verification. Check the seal before you accept anything.
  • A signature shows who shipped it, not that their build was clean. Protect the build too.
  • If you can't prove your backups and records are untouched, you can't fully trust them.

What OWASP says

The essentials, slide by slide.

A08 · owasp top 10 · 01/04

OWASP Top 10 · A08

software and data integrity failures

Source: OWASP Top 10:2025 (CC BY 3.0) ↗

OWASP is a non-profit that publishes the industry's standard list of web risks. Safety measures adapted from the OWASP Top 10:2025 (CC BY 3.0). The people and businesses in the examples are made up.