What breaks when teams reuse serialized JSON across CI/CD jobs without validation?

Why This Matters for Security Teams

Serialized JSON is often treated as a harmless interchange format, but in CI/CD it can become a trust boundary. Once one job emits JSON and a later job consumes it without validation, the pipeline can inherit malformed fields, unexpected types, and attacker-controlled values as if they were legitimate build inputs. That matters because build systems frequently use JSON for test selection, deployment metadata, policy decisions, and release coordination.

The core risk is not just parsing failure. It is logic abuse. A pipeline may continue running with a wrong environment name, a spoofed artifact reference, or a crafted object shape that changes how downstream scripts behave. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls maps well here because integrity, input validation, and separation of duties are all relevant to preventing untrusted data from being promoted across stages.

Security teams often underestimate this because the JSON is not coming from an obvious external user, yet the earlier job may already have ingested branch content, pull request material, generated artifacts, or third-party outputs. In practice, many security teams encounter this only after a later job has already consumed the JSON and changed deployment behaviour, rather than through intentional validation.

How It Works in Practice

The safest pattern is to treat JSON passed between jobs as untrusted data until it is parsed, schema-checked, and constrained to an expected contract. That means validating field names, value types, allowed ranges, and object nesting before any downstream step uses the content to make decisions. If the JSON describes build artifacts, environment targets, or release controls, the validation layer should reject missing required keys and unexpected properties rather than silently defaulting them.

In well-run pipelines, teams use a narrow contract between stages: one job produces a signed or checksum-verified artifact, the next job validates structure, and only then does a deployment or policy job consume it. This matters because JSON is often reused through environment variables, files, cache entries, or job outputs, and each transport mechanism changes the risk profile. If validation is absent, a later shell step, parser, or automation hook may interpret attacker-influenced JSON as trusted control data.

• Validate against a schema before use, not after a failure.
• Reject unknown keys when the data is meant to be strict.
• Separate data payloads from execution parameters.
• Keep job outputs immutable once produced.
• Log validation failures so tampering is visible in the pipeline trail.

For identity-sensitive pipelines, the issue can intersect with trust in service accounts, signing material, and workflow approvals, which is why identity guidance such as NIST SP 800-63 Digital Identity Guidelines is useful when job-to-job trust depends on verified provenance rather than convenience. These controls tend to break down when multiple build tools rewrite the same JSON object in different formats because field drift and implicit coercion bypass the original validation assumptions.

Common Variations and Edge Cases

Tighter validation often increases pipeline friction, requiring organisations to balance delivery speed against the cost of stricter contracts. That tradeoff is real, especially when teams rely on generated JSON from build tools, templating engines, or test harnesses that do not emit perfectly stable structures.

There is no universal standard for every JSON exchange pattern yet, so current guidance suggests using schema enforcement where the data drives control flow and using simple pass-through only for low-risk, non-decision data. Edge cases include sparse JSON from optional feature branches, multi-language pipelines that serialise numbers and booleans differently, and legacy jobs that expect permissive parsing. In those environments, the safest compromise is to normalise the JSON at the boundary, then validate it again before any privileged action.

This becomes especially important when JSON carries references to artifacts, tokens, or deployment targets, because a small shape mismatch can redirect the pipeline to the wrong resource or bypass a safeguard entirely. For teams operating in regulated delivery environments, pairing data validation with change control and traceability is usually the best practice, even if the exact enforcement point differs by toolchain.

Related resources from NHI Mgmt Group

• What breaks when CI/CD runners are reused across jobs?
• How should security teams govern machine credentials across cloud and CI/CD environments?
• How should security teams build a cryptographic inventory across cloud and CI/CD systems?
• How should security teams govern CI/CD jobs that publish security policy?