The Silent Field Loss: Why a Green CI Pipeline is Lying to You

As an independent security researcher, I spend a lot of time auditing open-source cryptographic implementations and supply chain toolings.

During a recent audit, I stumbled upon a terrifying realization: Your CI is green, your schema validation passes, but the data might be silently disappearing.

Here is the story of how we caught a silent field loss in a standard cryptographic data format, and why "structural validity" does not equal "semantic completeness."

The Problem: Structural Validity vs. Semantic Loss

When migrating to Post-Quantum Cryptography (PQC), organizations rely on standardized formats like CycloneDX CBOM (Cryptographic Bill of Materials) to track algorithms.

During our audit, we used a popular open-source Python library to parse and re-emit a CBOM document. The document carried several optional fields.

# The schema-valid 1.7 JSON input
{
  "algorithmProperties": {
    "algorithmFamily": "ECDH",
    "ellipticCurve": "P-256",
    "parameterSetIdentifier": "256",
    "primitive": "key-agree"
  }
}

After a simple parse -> emit round-trip, we validated the output against the official schema. It passed.

But when we printed the output, it looked like this:

{
  "algorithmProperties": {
    "curve": "P-256",
    "parameterSetIdentifier": "256",
    "primitive": "key-agree"
  }
}

algorithmFamily was gone. No exceptions, no warnings. The document is still valid, but the data is lost.

Why? Because the underlying Python library simply hasn't modeled that specific field yet. Schema validation only checks if the structural format is legal; it doesn't check if the parser actually consumed and retained the semantic content.

The Solution: Negative Control Testing

To catch this "silent field loss," traditional unit tests are useless because they test your own assumptions. You need Negative Control Testing and an Independent Oracle.

1. The Negative Control: We wrote a script that explicitly constructs a document with these fields, parses it, and asserts their survival. If the field is dropped, the test deliberately fails. This catches the defect.
2. The Independent Oracle: For cryptographic implementations, we don't just test against ourselves. We cross-verify byte-by-byte (public keys, ciphertexts, shared secrets) against an independent reference implementation.

The Delivery Gate: Bytes over Trees

The same principle applies to deployment. A while ago, git reset --hard returned 0, and our CI checks were all green. But the public server was serving a file that was slightly shorter than what was in the commit. Why? The .gitattributes normalized line endings (CRLF to LF), silently destroying the cryptographic hashes.

We fixed this by building a black-box delivery gate that fetches the public URL and compares the raw bytes against the git cat-file object.

A green pipeline is a statement about the tree; only a request to the wire is a statement about the wire.

Why I Built This

I am a 16-year-old independent researcher. I built this open-source auditing toolchain because the PQC migration is facing a 2030/2035 deadline. If the underlying evidence chain is broken, the cryptography is worthless.

We published a technical preprint on Zenodo documenting this (DOI: 10.5281/zenodo.23808518), and the entire toolchain is open-sourced.

If you are working on PQC migration or supply chain security, I would love to hear your thoughts. How do you handle semantic validation in your CI pipelines?

• Check out the open-source repo: github.com/Lennonhaha/fibemate
• Read the academic preprint (DOI): 10.5281/zenodo.23808518

Let's make our evidence chains verifiable.