Verifiable Cleanliness for LLMs: Data-SBOM, CAP Protocol, and a Poison Stress Test

Verifiable Cleanliness for LLMs: A Baseline Framework for Supply-Chain Auditability and Poison Resistance Author：Jake Raser Contributors:ChatGPT Independent Researcher [email protected] 2025-10-25 0.Executive Thesis Problem. Enterprises are rapidly shipping open-source or hybrid LLM stacks with little to no end-to-end auditing of the training/fine-tuning data supply chain—even as mainstream security bodies now treat training-data poisoning and LLM supply-chain exposure as first-class risks. Finding (prior work). Recent large-scale experiments show poisoning attacks require a near-constant number of samples—on the order of ~250 documents—to backdoor models from 600M up to 13B (Souly, A,2025) parameters, and such backdoors can persist even after additional clean training. This collapses the assumed “make the dataset bigger to drown the poison” defense. Gap. Traditional software has SBOMs and CVE workflows; training data has no widely adopted equivalent. There is no standard, verifiable bill of materials for what a model ingested (NITA,2025). Contribution (this paper). We propose a Data-SBOM (DSBOM) schema, a CAP protocol (Cleanliness–Audit–Provenance), and a Poison Stress Test (PST) benchmark as the minimum viable path to verifiable cleanliness in open-source LLM pipelines. Timing. Major actors (OWASP, 2025) are already flagging AI supply-chain security and provenance as core controls; what’s still missing is an operational framework to implement them for training data. 1. Introduction (Why Now) Enterprises are adopting open-source LLMs at speed, but governance lags the risk surface. As organizations fine-tune community models and compose them with third-party artifacts, their exposure shifts from classic code vulnerabilities to data/component provenance and poisoning risks—now explicitly cataloged by OWASP under LLM supply chain and training-data poisoning (OWASP,2025). Beyond standards naming the problem, major cloud guidance stresses provenance records to mitigate data-poisoning and model-tampering (Google Cloud,2025), yet offers few concrete, reproducible controls tailored to model training pipelines. A technical shock to intuition. The latest empirical work demonstrates that poisoning efficacy does not scale with corpus size: introducing roughly 250 poisoned samples can backdoor models from 600M to 13B parameters, and the effect can survive further clean training. For defenders who implicitly relied on “more data” as dilution, this is strategically destabilizing. Why “data supply-chain” is not an abstraction (Stanford Internet Observatory.,2023).. Public incidents around large, web-scale datasets underline the practicality—and consequences—of insufficient data governance. Investigations have shown that widely used training sets can contain illegal or harmful material and lack traceable provenance, forcing emergency takedowns and leaving downstream models without a clean remediation path. In short: the data we train on is not automatically trustworthy, and when it isn’t, fixes are rarely targeted or auditable. What software security already solved—AI hasn’t. In classic software, SBOMs enumerate dependencies to enable patching, transitive-risk analysis, and accountable disclosure. No such, widely adopted artifact exists for training corpora: most model cards disclose little about where data came from, who contributed it, or how it was cleaned/deduplicated. The result is a governance vacuum at precisely the layer poisoning exploits. This paper’s objective. We reframe data-poisoning from a narrow technical exploit to a trust-chain governance problem for open-source LLMs, and we contribute a concrete, testable baseline: Data-SBOM (DSBOM): a minimal schema for training-data provenance (sources, licenses, dedup/cleaning logic, contributor metadata, cryptographic hashes/timestamps). CAP protocol: operational controls for Cleanliness (trigger/abnormality screening), Audit (end-to-end logging and reproducibility),and Provenance (signed, tamper-evident lineage). Poison Stress Test (PST): a standardized evaluation that quantifies poison susceptibility and residual persistence under clean-training continuation. Scope and audience. We target enterprises shipping open-source-based LLMs, platforms curating public models/datasets, and standards bodies considering AI supply-chain guidance. Our thesis is pragmatic: without verifiable cleanliness, there is no production-grade safety—and the controls to change that are implementable now, building on provenance practices already endorsed for AI supply chains. Structure. §2 maps the problem landscape from technical vulnerability to governance vacuum; §3 formalizes threat and terminology; §4 introduces the LLM Trust-Chain Vulnerability Model and an Auditability Score (A-Score); §5 defines metrics (e.g., TIGI, R-Persist); §6 specifies CAP and PST; §7 presents small-but-telling experiments; §8 surveys industry signals; §9 outlines a deployment and regulatory pathway; §§10–12 discuss economics, ethics, and limits; §13 concludes with actions for CISOs, communities, and regulators. 2. Problem Landscape: From Technical Vulnerability to Governance Vacuum 2.1 What the research already proves A decade of work in NLP and more recently, LLMs has established that small, carefully crafted training poisons can implant backdoors that fire on triggers while preserving normal performance. Early NLP results showed concealed poisons and hidden triggers (e.g., style-based) can reliably steer models, foreshadowing today’s LLM risks. The most recent large-scale study pushes this further: roughly ~250 poisoned documents suffice to compromise models from 600M to 13B (Souly et al,2025) parameters, i.e., poisoning cost is near-constant with model size—and the backdoor can persist after further clean training. This invalidates “just add more clean data” as a defense (Wallace et al,2021). Surveys now frame backdoors as a first-class LLM security issue: poisoning either the data or the weights enables trigger-driven control, with modern variants optimized for stealth and transfer. 2.2 Industry is waking up—but responses are fragmented Security bodies and cloud providers have begun to name the problem. OWASP’s “Top 10 for LLMs” explicitly calls out Training Data Poisoning and Supply Chain exposure (OWASP,2025). Google’s guidance on AI supply-chain security stresses provenance (recording where artifacts/data come from) because poisoning/model tampering cannot be mitigated by code review alone. Meanwhile, emerging work highlights model-artifact vectors (e.g., pickle-based model packaging paths missed by scanners) that live alongside data poisoning. Enterprises and security coalitions are publishing controls lists and risk primers, but these tend to emphasize application/runtime guardrails over training-data governance. The end result: good awareness, few operational, auditable controls for the training pipeline itself. 2.3 Why this is not abstract: public dataset incidents Real-world events show the cost of weak data governance. The LAION-5B episode—where researchers identified CSAM inside a widely used web-scale dataset powering popular image systems—led to takedowns and a subsequent “Re-LAION-5B” cleaning pass. Yet downstream models trained before the fix had no targeted, auditable remediation path, illustrating the gap between “we found bad data” and “we can prove we removed its influence.” 2.4 Our positioning Prior technical work proves feasibility; industry guidance names risks. What’s missing is a baseline governance mechanism for open-source LLM pipelines that makes “what went into the model” provable and stress-tests poisoning susceptibility before deployment. This paper fills that gap with a Data-SBOM (DSBOM), the CAP operational protocol (Cleanliness–Audit–Provenance), and a Poison Stress Test (PST) benchmark. 3. Threat Model and Terminology 3.1 Three properties the supply chain must make verifiable Cleanliness — absence (to practical assurance levels) of malicious or backdoor-bearing samples/labels and of systematic anomalies (e.g., trigger co-occurrence patterns) likely to implant targeted behaviors. Privacy — exclusion or controlled handling of sensitive/illegal content (e.g., PII, CSAM) with documented detection and response procedures. Provenance — cryptographically anchored lineage (source, license, transformation, contributor, timestamps, hashes) enabling trace-back and selective rollback. These map to existing governance expectations in NIST’s AI RMF (explicit calls to document training-data sources and provenance) and the EU AI Act’s Article 10 (data governance for training/validation/test sets), but are rarely implemented for open-source LLM training corpora (NITA,2021). 3.2 Supply-chain surface (nodes and flows) We model the open-source LLM pipeline as Data Source → Collection/Scrape → Cleaning/Dedup → Pre-training → Fine-tuning/Alignment → Distillation/Synthetic Data → Packaging/Distribution → Deployment → Feedback/Memory/RAG → (optional) Continual Training. Each hop has distinct attack apertures and audit needs; crucially, ad hoc, unlogged steps are common, which is why Google’s guidance emphasizes provenance logging over manual inspection. We classify three failure points: M-Points (Mutable): externally writable/replaceable stages (community dataset merges, contrib PRs, public corpora ingestion). U-Points (Untraceable): missing or unverifiable metadata (no hashes, no license/source, no contributor identity). I-Points (Irreversible): stages whose effects are hard to cleanly “undo” (pretraining weights, some RLHF phases, multi-gen distillation). 3.3 Adversary model Well-resourced actors (state/organized groups) aiming for durable, low-noise backdoors across open supply chains. Opportunistic actors/insiders targeting fine-tuning datasets, model artifacts, or agent memories/RAG corpora for exfiltration or sabotage. Recent security guidance and industry reports increasingly treat AI supply chains as first-class targets requiring provenance, signing, and continuous monitoring. 3.4 Attack surfaces and trigger classes Pretraining/Fine-tuning poisoning — inject small, stealthy patterns that bind behaviors to explicit triggers (tokens/phrases) or implicit triggers (linguistic styles/structures). Classic NLP work demonstrated concealed poisons and hidden-style triggers; modern LLM work shows the near-constant poison cost across model scales. Model-artifact supply chain — ship poisoned or booby-trapped model files (e.g., pickle deserialization gadgets) that execute on load or manipulate downstream training/usage; scanners miss nontrivial fractions of paths/gadgets. Deployment-time “memory/RAG” poisoning — indirect prompt injection plants instructions into agent long-term memory or seeded corpora, persisting across sessions and enabling exfiltration or policy bypass. This extends poisoning beyond training into operational knowledge bases. 3.5 What must be measurable Our subsequent sections operationalize these notions into: A-Score (Auditability): nodeand chain-level verifiability metric tied to disclosed DSBOM fields and signed lineage. TIGI / R-Persist / S-Frag: effectiveness and persistence metrics capturing triggered information gain, post-clean-training residue, and subspace fragility under small poisons. Together with PST, they provide the missing pre-deployment acceptance test for open-source LLMs. Regulatory and standards fit. ISO/IEC 42001 places process obligations on AI lifecycle governance; the EU AI Act timelines now bring training-data transparency/provenance into scope for GPAI and high-risk systems. Our DSBOM/CAP/PST concretize how to meet these expectations for open-source pipelines. Why privacy is part of “cleanliness.” Incidents like LAION-5B’s CSAM exposure show that illicit/sensitive content is not hypothetical; provenance and screening are needed before training, and selective rollback paths are needed after discovery. 4. The LLM Trust-Chain Vulnerability Model (LCVM) 4.1 Graph of the supply chain We model an open-source LLM pipeline as a directed acyclic graph�=(�,ℰ) whose nodes are lifecycle stages and whose edges are data/model transformatio DataSource→Collection/Scrape→Cleaning/Dedup→Pretraining→ Finetuning/Alignment→Distillation/Synthetic→Packaging/Distribution→ Deployment→Feedback/Memory/RAG→ContinualTraining Each node �∈� carries three operational attributes: Mutability :��∈{0,1}：externally writable/replaceable surface. Provenance level ��∈[0,1]: fraction of required lineage fields present and verifiable. Reversibility ��∈[0,1] : fraction of the node’s effect that can be selectively rolled back (e.g., by filtering traces, replaying training, or swapping data slices). We call out three failure classes: M-Points (Mutable):��=1, i.e., stages where adversaries can inject/replace artifacts (e.g., community dataset merges, public corpora ingestion, PR-based data contributions). U-Points (Untraceable): ��<��, i.e., lineage/metadata insufficient for selective rollback (no hashes, no license/source, no contributor identity). I-Points (Irreversible): ��<��, i.e., effects are hard to unlearn (e.g., pretraining weights, parts of RLHF, multi-generation distillation). Intuitively: M is where an attacker gets in; U is why we cannot find them; I is why we 6.1 CAP: Cleanliness – Audit – Provenance C — Cleanliness (content hygiene). Screening: pre-train/finetune corpora undergo automated checks for malicious triggers (lexical patterns, stylometric templates), anomaly co-occurrence graphs, deduplication collisions, and sensitive/illegal content (PII/CSAM) with documented rules and thresholds. Quarantine & replay: suspicious slices are isolation-trained to estimate their marginal effect; only slices with acceptable deltas (see §5 metrics) graduate into the canonical corpus. Red-team suites: periodic trigger fuzzing across prompt templates to catch implicit/style backdoors. A — Audit (tamper-evident lineage and logging). Immutable logs: write-once logs for who/what/when at each node (data pull, filtering job, training run), with signed build manifests and attestations bound to artifacts (datasets, checkpoints) (SLSA provenance / attestations). Determinism budget: containerized, seed-fixed pipelines with version-pinned dependencies; variance budgets (acceptable non-determinism) must be declared. Minimum viable traceability: every release includes a Data-SBOM (DSBOM) excerpt: source URLs or dataset identifiers, license/terms, dedup/cleaning rules, contributor identity class (org/user/anonymized), hashes/timestamps. P — Provenance (cryptographically anchored origin). Attestations: in-toto/SLSA-style attestations for data processing and training steps; Sigstore/cosign signatures (Sigstore / cosign) for artifacts (corpora shards, tokenizer, checkpoints) (SLSA / in-toto attestations,2023). Secure updates: distribution channels hardened with TUF-style multi-role signing, rollback protection (TUF-style update hardening), and threshold keys; revocation lists for tainted datasets/checkpoints. > Rationale. OWASP explicitly lists Training Data Poisoning and Supply Chain as top LLM risks; CAP makes those risks auditable and enforceable at the training layer rather than only at application/runtime. 6.2 PST: a reproducible pre-deployment gate PST is a standardized acceptance test that quantifies a model’s susceptibility to small-budget poisoning and the persistence of backdoors after “clean continuation,” while checking that A-Score (auditability) meets a minimum bar (see §5). Inputs. Trigger suite: balanced set of explicit (tokens/phrases) and implicit (style/syntax) triggers across tasks/languages. Attack budget: K∈{250,500} poisoned samples injected at specific nodes (source, finetune, continual). (Budget follows recent evidence that poisoning cost is near-constant w.r.t. model size. ) Remediation plan: fixed clean-training budget U and CAP steps to apply after detection. Outputs. Core metrics: TIGI, R-Persist (half-life, AUR, plateau), S-Frag, FAR, and chain A-Score (§5). Pass/fail policy (MVP). Trigger containment (TIGI ≤ τ or half-life ≤ τ without plateau), FAR ≤ τ, and A-Score ≥ 0.5 for general use (≥0.7 for safety-critical). Reproducibility. Fixed seeds, deterministic containers, signed artifacts; publish scripts, masked triggers, hashes, and compute budget to keep PST repeatable across orgs. Change gates: PST must be rerun on any material change to data, weights, alignment, tokenizer, or serving stack. Fit to standards. PST provides the missing, operational mechanism to realize provenance/traceability expectations in NIST AI RMF and cloud guidance that warns explicitly about data provenance, poisoning, and versioning gaps. 7. Small but Telling Experiments We design low-cost, high-signal studies to demonstrate (i) constant-cost poisoning and (ii) the predictive value of auditability (A-Score). We pre-register hypotheses and release code/containers for full reproducibility. 7.1 Models, data, and injection points Backbones: Llama-2-7B/13B and Mistral-7B (open weights, widely used), citing official reports. Corpora: web-scale English subsets drawn from The Pile, C4, and RedPajama (documented webtext corpora with known provenance/quality issues and rich metadata for ablations). Injection points: (a) source-stage poison into pretraining shard; (b) fine-tune poison during domain adaptation; (c) continual-learning poison (simulating post-deploy updates). Deployment-layer extension (optional): memory/RAG poisoning via indirect prompt injection to show operational persistence beyond training. 7.2 Pre-registered hypotheses H1 (Constant-cost attack). With K∈{250,500} poisoned samples and identical triggers, TIGI at u=0 will be non-decreasing as model size increases from 7B to 13B, consistent with near-constant poisoning cost. H2 (Persistence). After clean continuation up to U steps, R-Persist shows half-life h1/2>1,000 or a non-zero plateau for at least one I-Point injection (pretraining or alignment), indicating hard-to-erase backdoors. H3 (Auditability predicts resilience). Across N popular open models, A-Score negatively correlates with poisoning success (e.g., TIGI/FAR), producing a clear risk partition (A<0.4 high-risk; 0.4–0.7 medium; ≥0.7 acceptable). H4 (Operational spillover). For agents with persistent memory or RAG, indirect prompt injection seeds instructions that persist across sessions (Unit 42: indirect prompt injection) and re-surface post-remediation, illustrating that poisoning is not only a training-time threat. 7.3 Triggers, budgets, and controls Triggers: explicit lexical strings, paraphrastic patterns, and style/format cues (implicit). Budgets: K=250,500 poisons; clean continuation U chosen to reflect typical enterprise finetuning compute. Confound controls: identical optimizer/batch schedulers; temperature-matched sampling; prompt-template variants; multilingual subset to test cross-lingual robustness. 7.4 Metrics and endpoints (per §5) Primary: TIGI(0), h_{1/2}, AUR, plateau flag, FAR, S-Frag, chain A-Score. Secondary: clean-task deltas (MMLU-like slices), recovery after quarantine/replay. 7.5 Expected “killer findings” (decision-useful) A. Constant-cost poisoning (primary). Show that 7B and 13B exhibit comparable TIGI under the same K , despite 13B seeing far more clean tokens—mirroring the near-constant sample result reported by Souly et al. (2025). C. A-Score predictive power (policy-relevant). On a panel of widely used HF models, plot A-Score vs TIGI/FAR; expect strong negative correlation and a high-risk zone for A<0.4. > Together these isolate a governance lever (raise A-Score) and a threat reality check (bigger ≠ safer against small-budget poisoning). 7.6 Reproducibility commitments Open artifacts: code (MIT), Dockerfiles, config/seed files, masked trigger lists, and signed data slices/checkpoints via Sigstore/cosign. Determinism: fixed seeds; pinned dependencies; per-run manifests using in-toto/SLSA attestations. Compute disclosure: per-experiment wall-clock and GPU type/count; target <$500 per ablation for external replication. Challenge protocol: if third-party TIGI is <50% of our report under matched settings, we publish a correction note and updated scripts. 7.7 Ethics and safety No real PII/CSAM triggers; synthetic or masked artifacts only; red-team triggers kept private or hashed to reduce misuse. Disclosure policy: if we uncover live poisoned artifacts in public corpora, we follow coordinated disclosure and, where relevant, dataset maintainers’ processes. 8.ndustry Landscape Scan: Evidence of Awakening Takeaway. Vendors and standards bodies are beginning to name data/model poisoning and AI supply-chain risks, and a first wave of tools, guidance, and incidents is forcing concrete countermeasures—yet adoption remains uneven and concentrated in early movers. 8.1 Standards & guidance are explicit about provenance/supply chain OWASP elevates Training Data Poisoning and Supply Chain to top risks for LLM applications, making poisoning and third-party artifacts first-class concerns rather than edge cases(OWASP,2025). Google’s recent guidance frames provenance—tamper-evident origin/lineage—as a central control for data poisoning and model tampering, and links AI supply-chain security to established mechanisms (SLSA, Sigstore, TUF) (Google cloud,2025). NIST AI RMF (and companion materials) explicitly call for maintaining training-data provenance and documenting sources to support traceability and accountability across the lifecycle (NIST,2024). Implication. The language of provenance and chain security is now mainstream; what’s missing is an operational, testable method to implement it at training time (our CAP/PST/DSBOM aim to fill that gap). 8.2 Incidents & disclosures are reshaping data governance LAION-5B CSAM exposure → Re-LAION-5B (2024): independent research documented CSAM links within a widely used web-scale dataset; LAION responded with a cleaned re-release and safety notes. The episode evidenced how weak provenance and unverifiable lineage complicate downstream remediation for models already trained on tainted data. Implication. “Find-and-fix after training” is neither targeted nor auditable without pre-training screening and traceable data slices (DSBOM). 8.3 Tooling and platform defenses are emerging—but fragmented Model-artifact scanners: Security vendors have begun shipping model scanners (e.g., Protect AI Guardian/ModelScan) that detect unsafe deserialization and embedded code in model files; press and vendor reports tie these to real findings in public hubs. Pickle hardening & scanning: Research and industry reporting show pickle remains a major risk surface; platforms now add pickle scanning and promote safetensors as a safer default. Cloud/SecOps coverage: Security blogs and reports aimed at enterprises now include AI supply-chain abuse patterns and detection guidance, indicating a shift from theory to SOC playbooks. Implication. Existing tools skew toward artifact/runtime checks; training-data governance (provenance, attestation, stress-testing for poisoning) remains the thinnest layer—precisely where our framework intervenes. 8.4 Signals from hyperscalers & auditors Secure AI Framework (SAIF) and Google publications advocate adapting SLSA/in-toto/Sigstore/TUF patterns to AI pipelines—i.e., bring software supply-chain discipline to data/model artifacts. ISO/IEC 42001 (AI management systems) gives organizations a governance scaffold that can host DSBOM/CAP/PST controls as auditable processes. Net. The ecosystem recognizes the problem and is building pieces of the solution. What’s missing is a minimal, end-to-end baseline that organizations can adopt now—this paper’s DSBOM + CAP + PST. --- 9. Governance Framework & Implementation Roadmap Objective. Translate “awareness” into operational controls that (i) make training-data lineage provable, (ii) detect/contain small-budget poisoning, and (iii) align with emerging standards and regulation. 9.1 Enterprise playbook (CISO/CIO) Phase 0 — Policy & scope (2–4 weeks). Adopt AI lifecycle governance aligned to ISO/IEC 42001; designate data owners for each pipeline node and explicitly scope open-source model/data ingestion. Declare DSBOM a required release artifact for any training/finetune. (Map DSBOM fields to your risk register and vendor/on-prem data sources.) Phase 1 — Controls (6–10 weeks). C — Cleanliness. Automate PII/CSAM and trigger/anomaly screening before pretraining or finetuning; quarantine suspicious slices and run isolation training to estimate marginal impact. (Post LAION-5B, this is table stakes) (Stanford Internet Observatory,2023) A — Audit. Implement immutable logs and per-run manifests; require signed dataset shards/checkpoints (Sigstore/cosign) and in-toto/SLSA attestations for data processing and training runs (Sigstore / cosign). P — Provenance. Harden update/distribution via TUF-style protections (threshold signing, rollback prevention); maintain revocation lists for tainted datasets or weights. Phase 2 — Gatekeeping (continuous). Institutionalize PST as a pre-deployment gate: publish TIGI/R-Persist/S-Frag/FAR results with every release; block if thresholds fail; rerun PST on any material change (data, weights, tokenizer, alignment, serving). (This operationalizes NIST AI RMF expectations on provenance and monitoring.) (NIST,2024). Phase 3 — Audit & disclosure. Report chain A-Score and per-node auditability in internal model cards; include DSBOM excerpt in partner disclosures. Establish 72-hour incident protocol: publish trigger/impact scope and LCVM node of origin; within 90 days provide third-party verification of CAP coverage (mirroring best-practice incident windows). (Policy alignment: EU AI Act Article 10 on data governance; ISO 42001 continuous improvement.) 9.2 Community & platform responsibilities Model hubs: require Provenance fields in model cards and signed artifacts by default; surface A-Score/DSBOM badges in UI to incentivize adoption (similar to SLSA levels in software registries). (This tracks with Google/OWASP guidance to make provenance first-class) Dataset maintainers: publish hash lists, license/collection notes, and change logs; provide revocation manifests for downstream selective rollback. Security vendors: extend scanners beyond pickle/runtime to include data-slice attestations and PST harnesses, not just artifact signatures. (First-gen tools like Guardian/ModelScan show feasibility on the artifact side.) 9.3 Regulatory & assurance pathway (minimum viable rules) Risk-based triggers: For systems with ≥1M MAU or processing sensitive data, mandate pre-deployment PST and a minimum A-Score (e.g., ≥0.5). Disclosure: Require release-time DSBOM excerpts and attestation bundles (in-toto/SLSA) for training/finetune runs; on incidents, 72-hour public notice with LCVM node and CAP steps. Alignment: These measures concretize NIST AI RMF calls for provenance/traceability and align with EU AI Act Article 10 obligations for data governance without prescribing specific datasets or models. 9.4 Costs and incentives Cost curve shift: Standardizing DSBOM, CAP automation, and PST flattens the defender cost curve (from bespoke audits to reusable checks) and raises marginal payoff (fewer undetected poisons, faster rollback). Market incentives: Expose A-Score in procurement/partner checklists; treat PST pass as due-diligence for vendors—mirroring how SBOM/SLSA proofs reshaped software supply chains. 10. Economics and Game-Theoretic Analysis "created_at": {"type": "string", "format": "date-time"}, "producer": { "type": "object", "properties": { "org": {"type": "string"}, "contact": {"type": "string"}, "signing_key": {"type": "string"} } }, "global_license": {"type": "string"}, "tokenizer": {"type": "string"}, "slices": { "type": "array", "items": { "type": "object", "required": ["slice_id","source","license","hash","transform_chain"], "properties": { "slice_id": {"type": "string"}, "source": { "type": "object", "properties": { "type": {"type": "string", "enum": ["crawl","dump","contrib","synthetic"]}, "uri": {"type": "string"}, "timestamp": {"type": "string", "format": "date-time"}, "contributor": {"type": "string"} } }, "license": {"type": "string"}, "pii_status": {"type": "string", "enum": ["none","filtered","redacted","unknown"]}, "safety_flags": {"type": "array", "items": {"type": "string"}}, "dedup_rule": {"type": "string"}, "blacklist_refs": {"type": "array", "items": {"type": "string"}}, "hash": {"type": "string"}, "transform_chain": { "type": "array", "items": { "type": "object", "required": ["name","version","params","input_hash","output_hash","attestation"], "properties": { "name": {"type": "string"}, "version": {"type": "string"}, "params": {"type": "object"}, "input_hash": {"type": "string"}, "output_hash": {"type": "string"}, "attestation": {"type": "string"} } } } } } }, "signatures": {"type": "array", "items": {"type": "string"}} } } A.2 Example (YAML excerpt) dataset_id: corpora/news-english-v2 version: 2025.10.01 created_at: 2025-10-01T12:03:17Z producer: {org: ExampleAI, contact: [email protected], signing_key: cosign:AAA...} global_license: CC-BY-4.0 tokenizer: tokenizer@sha256:9f1c... slices: - slice_id: crawl-2024q4 source: {type: crawl, uri: s3://bucket/crawl/2024q4.parquet, timestamp: 2025-09-15T00:00:00Z} license: "crawl-terms" pii_status: filtered safety_flags: [csam_scan:clean, profanity:allowed] dedup_rule: "minhash@v2(k=7, J>=0.92)" blacklist_refs: ["domain:blacklist.txt", "url:bad_urls.txt"] hash: sha256:2ab9... transform_chain: - name: normalize version: v1.3 params: {lower: true, strip_html: true} input_hash: sha256:2ab9... output_hash: sha256:77de... attestation: intoto:eyJ... signatures: - cosign:MEUCIQD... > Alignment: DSBOM provides the provenance/traceability artifacts expected by NIST AI RMF and anticipated by cloud supply-chain guidance (SLSA/in-toto, Sigstore). --- Appendix B — CAP Enterprise Checklist (MVP) Use. Run pre-training, pre-finetune, pre-release. Each item is Yes/No; failure on any “★” item blocks the stage. B.1 Cleanliness (C) ★PII/CSAM detectors executed on all slices; thresholds/version recorded. ★Trigger/anomaly scans (lexical + stylometric) executed; hit list quarantined. Dedup completed (rule + version logged); near-dup threshold set. Isolation-train on quarantined slices; marginal deltas < policy bounds. Red-team fuzzing over prompt templates; regressions triaged. B.2 Audit (A) ★Immutable per-run logs (who/what/when) retained ≥ N days. ★Deterministic pipeline: container image hash + seeds pinned. ★Build/training manifests signed; dependency lockfiles archived. DSBOM excerpt generated and attached to model card. Recovery plan: last audited checkpoint identified. B.3 Provenance (P) ★in-toto/SLSA attestations for data transforms & training runs. ★Artifacts (slices, tokenizer, checkpoints) signed (Sigstore/cosign). ★Distribution hardened (TUF-style roles, threshold keys, rollback protect). Revocation process defined for tainted data/weights (hash lists published). > Reference: CAP operationalizes OWASP LLM supply-chain risks and Google provenance controls at the training layer. --- Appendix C — PST Trigger Suite (Minimal) Goal. A balanced set that captures explicit and implicit backdoors, across tasks and templates, while limiting dual-use. C.1 Categories Explicit lexical triggers: rare token strings / phrase combos unlikely in clean corpora. Paraphrastic triggers: semantically equivalent paraphrases to test lexical generalization. Stylometric triggers (implicit): punctuation rhythms, capitalization patterns, spacing motifs, Markdown glyph patterns. Structural triggers: instruction prefixes/suffixes, YAML/JSON scaffolds with specific key orders. Cross-lingual triggers: short bilingual fragments to test transfer. C.2 Packaging and hygiene Triggers distributed as hashed masks with deterministic generators (seed → concrete form). Per-task prompt templates (QA, instruction-following, safety refusals) with template rotation to reduce overfitting. “Safe output” or neutral target bindings to avoid misuse (e.g., print token id rather than sensitive content). C.3 Coverage metrics Trigger coverage (%) by task/language; False Activation Rate (FAR) on non-trigger inputs; per-template TIGI deltas with 95% CI. Release: containerized harness with fixed seeds and signed artifacts. --- Appendix D — Metric Implementation Details Environment. Containerized (e.g., OCI image), pinned deps, deterministic seeds; manifests and outputs signed (Sigstore). D.1 TIGI Compute baseline distribution ��⋆(⋅∣�)on a clean checkpoint. For each template/language and trigger mask, sample �, materialize t(x)=1 , compute ���(��∥��⋆). Normalize by the mean KL on a matched non-trigger control set. D.2 R-Persist Define clean-continuation schedule (optimizer, LR, steps �); record manifests. Track TIGI(u) , compute half-life ℎ1/2, AUR, and plateau flag. Report along with compute budget and wall-clock (replication cost transparency). D.3 S-Frag Extract hidden states Φℓ(x) for clean vs. trigger batches. Compute CKA; report ΔCKA and principal-angle spread; approximate �Δ���  / �� via small Kgrid (e.g., 50, 100, 250, 500). D.4 A-Score Map checklist items (Appendix B) to [0,1] rubric; weight M-Points/I-Points higher; compute harmonic mean over critical paths (§4.3). Publish per-node ��and overall A⋆with DSBOM excerpt. D.5 Acceptance policy (defaults) Trigger containment: TIGI(0) ≤0.20��ℎ1/2 ≤1,000 with no plateau Spillover: FAR ≤1% . Auditability: A⋆≥ (general) / ≥0.7 (safety-critical). Appendix E — Proof Sketch for Theorem 4.1 (Vulnerability Inequality) We consider a two-player game on a chain of n nodes. The attacker chooses poison (P) or abstain (A); the defender chooses audit level �⋆∈[0,1]. Payoffs: Attacker: . ��=1[�]⋅(�[��(�⋆)]−��) Defender: . ��  =−1[�]⋅�[�(�⋆)]−��  (�,�⋆) Assumptions (supported by prior and industry guidance): 1. Near-constant attack cost Ca=O(1) for small K(≈250–500). 2. Linear-in-n defense cost ��(�,�⋆)=Θ(�⋅�⋆)(each node must be instrumented/signed/attested per OWASP/NIST/Google provenance requirements). 3. For small�⋆,��[�]/��⋆is modest (weak marginal reduction without gates), and ���  /��⋆is sizable (setup cost). Then for A⋆, the attacker’s best response is P (since �[��]≫��), and the defender’s best response is low audit (since marginal defense ��� exceeds avoided loss��[�]). Hence a low-audit Nash equilibrium with high vulnerability �(�,�⋆→ 0). Introducing standardized artifacts (DSBOM), automation (CAP), and gates (PST) reduces ���/��⋆and increases��[�]/��⋆, shifting the equilibrium toward audited operation. --- Appendix F — Incident Disclosure Templates (Optional) F.1 72-hour public notice (one-page). What: trigger description (hashed/masked), affected versions (hashes), LCVM node of origin. Impact: tasks affected, activation conditions, estimated user/request exposure. Interim controls: mitigations applied (e.g., blocklists, rollback). Next steps: remediation plan and expected PST re-test date. F.2 90-day postmortem (audit-ready). Root cause: CAP checklist deltas; missing DSBOM fields; failed PST indicators. Fixes: node-level CAP improvements; updated DSBOM; A-Score before/after. Verification: third-party attestation; PST pass report attached. Reference OWASP Gen AI Security Project. (2025). LLM03: Training data poisoning. OWASP. https://owasp.org/www-project-top-10-for-large-language-model-applications/?utm_s ource Souly, A., Rando, J., Chapman, E., Davies, X., Hasircioglu, B., Shereen, E., ... & Kirk, R. (2025). Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples. https://arxiv.org/abs/2510.07192 National Telecommunications and Information Administration (NTIA). (2021). The Minimum Elements For a Software Bill of Materials (SBOM). NTIA. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom?ut m_source Google Cloud. (2025). Same same but also different: Google guidance on AI supply chain security. Google Cloud https://cloud.google.com/transform/same-same-but-also-different-google-guidance-aisupply-chain-security?utm Stanford Internet Observatory. (2023). Investigation finds AI image-generation models trained on child sexual abuse material / related reports. Stanford FSI. https://fsi.stanford.edu/publication/investigation-finds-ai-image-generation-models-tra ined-child-abuse?utm_source=chatgpt.com Wallace et al., Concealed Data Poisoning Attacks on NLP Models (ACL 2021) https://aclanthology.org/2021.naacl-main.13.pdf?utm_source=chatgpt.com National Institute of Standards and Technology (NIST) — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile： https://www.nist.gov/publications/artificial-intelligence-risk-manage ment-framework-generative-artificial-intelligence SLSA Project. (2023). In-toto and SLSA (attestation primer). https://slsa.dev/blog/2023/05/in-toto-and-slsa Sigstore (Cosign). (n.d.). Cosign docs . https://docs.sigstore.dev/cosign/ ; https://github.com/sigstore/cosign The Update Framework (TUF). (n.d.). TUF documentation. https://theupdateframework.io/ Unit 42, Palo Alto Networks. (2025). When AI Remembers Too Much – Persistent Behaviors in Agents' Memory. https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons -ai-longterm-memory/ NIST. (2024). Artificial Intelligence Risk Management Framework: Generative AI Profile (NIST AI 600-1). https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf Stanford Internet Observatory. (2023). Investigation finds AI image-generation models trained on child sexual abuse material. https://cyber.fsi.stanford.edu/publication/investigation-finds-ai-ima ge-generation-models-trained-child-abuse SLSA Project. (n.d.). SLSA specification & provenance. https://slsa.dev/spec/v1.0/ https://slsa.dev/attestation-model Sigstore (Cosign). (n.d.). Cosign docs / Sigstore quickstart. https://docs.sigstore.dev/cosign/ https://docs.sigstore.dev/quickstart/quickstart-cosign