A training pipeline restores a cached preprocessed feature shard - what integrity risk does that add?

## Why this is a supply-chain question, not an ML question Pipelines that train models look like ordinary build pipelines with a different payload. Raw data is read, a preprocessing stage produces feature shards - fixed, expensive-to-compute chunks of transformed data - and a training stage consumes them. Because preprocessing is slow, shards are cached: the pipeline computes a key from the raw-data pointer plus the preprocessing code version, and if an entry exists it restores it rather than recomputing. That is the same structure as any build cache, so the same rule applies: **the cached input's trust level equals whoever can write the key**. What differs is the payload and, crucially, the failure signature. ## The failure signature is what makes it dangerous A poisoned code cache usually produces something you could in principle inspect - a binary that differs from a cold build. A poisoned feature shard produces: - a training job that completes normally; - a schema that still validates, because the tampering is in values and labels, not structure; - aggregate metrics that can sit inside their normal band, because a small fraction of altered rows moves them little; - a model whose behaviour differs only on inputs the attacker cares about. Nobody reviews a shard the way a pull request is reviewed. There is no diff, no reviewer, and typically no recorded expected hash. The asset at risk is the model itself - the organisation's model IP and the correctness of every decision it makes - and the compromise persists into every artifact derived from that model until someone retrains from clean data. ## Who can write it Two realistic positions. First, a legitimate insider: a data engineer with write access to the feature store or cache bucket, which is normal and usually broadly granted, since "writing processed data" is their job. Second, a compromised preprocessing job: it holds the credential that writes shards, so anything that achieves code execution inside it - an untrusted transform library, a notebook-derived step, a dependency install hook - inherits the ability to write any shard, including ones for pipelines it has nothing to do with. Neither position requires touching the training code, the model registry or the deployment path. That is the point: the weakest link is the unreviewed intermediate. ## Controls, ordered by what they actually buy 1. **Restrict who may write.** The cache should be writable by the pipeline's own workload identity and by nothing else. Human write access to a path that feeds training is the finding, not the mitigation. 2. **Content-address the shard and record it with the run.** Have the producing job compute a digest of each shard and register it as part of the training run's inputs. Then the question "what data was this model trained on?" has a byte-exact answer instead of a path and a timestamp. This also turns a later tamper into a detectable event rather than an unanswerable one. 3. **Verify on restore.** The consuming job recomputes the digest and compares against the recorded value - and, as always, that recorded value must live where the writer of the shard cannot rewrite it. 4. **Recompute and compare, on a sample.** Periodically rebuild one shard from raw data with the same code version and compare it to the cached entry. This is the only routine check that catches a tamper nobody reported, and it is cheap when sampled. 5. **Keep evaluation data out of the cached path.** If the same write access covers both the training shards and the held-out set used to judge the model, the attacker can poison the training data and adjust the yardstick. Separate credentials, separate storage, separate lifecycle. 6. **Prefer recompute for small or high-stakes stages.** Caching is a cost decision. Where a stage is cheap or the model is high-impact, recomputing removes the entire question. ## The rule that generalises **Restore only what you could reproduce, and only from a writer you would trust to produce it.** If deleting the cache would change the model, the cache is not a cache - it is an unversioned, unreviewed input to a production system, and it must be treated with the controls you would apply to source code: restricted writes, recorded identity, and a way to prove what was consumed. ## What an interviewer is listening for That you spotted the silence of the failure, that you named a realistic writer rather than a movie attacker, and that your controls distinguish *preventing* the write from *detecting* the tamper - because in this domain detection is genuinely hard, which is why the write restriction and the recorded digest do most of the work.