data-integrity-failures
Software and Data Integrity Failures Skill
Data integrity failures happen when an application processes serialized data, pipeline steps, or software updates without verifying they have not been tampered with. An agent writing a deserialization handler or a CI pipeline script does not automatically ask whether the data or the script could have been modified by an attacker.
What to Check Before Writing Integrity-Sensitive Code
1. Deserialization of untrusted data
Python's pickle, Java's ObjectInputStream, PHP's unserialize, and Ruby's Marshal.load can execute arbitrary code when given crafted input. These must never be used on data from an untrusted source. Use JSON, protobuf, or a schema-validated format instead.
Untrusted sources: user uploads, external APIs, message queues where producers are not under your control, cached data that could be poisoned.
2. CI/CD pipeline integrity
Pipeline scripts that curl | bash, pip install from unverified sources, or clone from branches without pinning are integrity risks. Pipeline steps should use pinned dependency versions, hash verification where possible, and signed artifacts.
3. Dependency integrity verification
Package installs should use lockfiles with hash verification. npm ci (not npm install) in pipelines. pip install with --require-hashes in production builds.
4. Deserialized data as code path Any flow where deserialized data influences what code executes (dynamic imports, eval, command construction) must treat the deserialized input as untrusted and validate it strictly.