An AI security deployment needs a supply-chain policy, not just a capable model. In this GPT-6 Cyber campaign installment, the focus is defensive engineering around the agent: which artifacts enter its environment, who approved them, and how operators can withdraw them. This is a proposed reference design, not a report of a new model capability or intrusion.
OWASP places training data, third-party models, and deployment platforms within the LLM supply-chain risk surface.[1] Its guidance recommends component inventories, verifiable sources, signing, and integrity checks.[1] The useful operational question is therefore broader than “did we download the right weights?”: can the team identify and approve everything needed to reproduce this deployment?[1]
Start with an admission record, not a download count
OWASP warns that model cards provide information but do not guarantee model origin, and that supplier accounts can be compromised.[1] A popular repository is not the same thing as an independently verified delivery chain.[1] My recommendation is to maintain a small admission record for every approved release, with a named owner and an explicit rollback decision.
For a network-operations assistant, record the model revision, dataset snapshots, loader code, Python dependencies, container digest, and policy configuration. This proposed record extends OWASP's component-inventory approach into an operator-readable release manifest.[1] Keep it beside the deployment approval, rather than scattered across notebook history and chat messages.
Use an internal staging registry as the intake point, with separate permissions for uploading, reviewing, and promoting artifacts. This is a proposed implementation of OWASP's verifiable-source and integrity-check recommendations, not a claim that an internal registry automatically establishes trust.[1]
Review models and datasets before executing their loaders
Hugging Face's versioned Transformers v4.44.1 documentation advises reviewing custom model code and its author even though Hub uploads are scanned.[2] It documents trust_remote_code=True as the opt-in for custom code and strongly encourages a commit hash for the revision.[2] Treat that opt-in as a code-review decision, not a compatibility checkbox.[2]
For this reference design, reject unexplained loader changes and require reviewers to compare the exact proposed revision with the previously approved one. This follows the documentation's distinction between reviewing code and pinning the code that was reviewed.[2] Apply the same review discipline to dataset conversion scripts, templates, and preprocessing packages.
Hugging Face also explains that pickle deserialization can execute Python code and explicitly describes its scanning approach as not completely foolproof.[6] A clean scanner result should therefore be one input to admission, rather than permission to load an unfamiliar artifact in a privileged worker.[6] Prefer formats and loading paths that avoid executable deserialization where practical, while reviewing the surrounding code separately.[6]
Verify the signer you intended to trust
Sigstore's Cosign documentation shows keyless image verification using both an expected certificate identity and an expected OpenID Connect issuer.[3] Those are policy inputs: verification should identify the approved publisher, not merely accept any identity capable of producing a valid signature.[3] Because Cosign accepts expected identity and issuer as verification inputs, define both explicitly rather than inheriting an agent-selected identity.[3]
For example, an admission service could accept an image only when its signer matches the designated release workflow and its issuer matches the organization's chosen identity provider. This is a proposed application of Cosign's identity-and-issuer checks; the actual values must come from your publisher's documented signing process.[3]
Do not describe a successful signature check as proof that the model is safe. Cosign verifies signatures on artifacts; behavioral acceptance is a separate release decision.[3] Cosign's documented image-verification output includes claims about the image digest, not a model-behavior evaluation result.[3]
Check provenance against explicit expectations
SLSA's verification guidance checks the provenance signature against configured trust roots and compares the statement's subject with the artifact digest.[4] It then asks consumers to compare expected builder identity, canonical source repository, build type, and external parameters.[4] Merely attaching a provenance file is not equivalent to applying these checks.[4]
In this reference design, reject releases whose build came from an unapproved fork or whose parameters differ from the approved build contract. Those are direct applications of SLSA's expected-repository and expected-parameter checks.[4] Preserve the verification result with the artifact digest, not only with a mutable release name.
SLSA also cautions that Build L3 does not cover compromise of the build platform itself.[4] Keep that boundary visible in the risk review: provenance supports a defined trust decision; it does not remove the need to assess the trusted builder.[4]
Isolate dependency assembly from production access
Pip documents a secure-install approach using --require-hashes and --only-binary :all:.[5] In hash-checking mode, requirements and dependencies need hashes, and requirements must be pinned.[5] The documentation also distinguishes locally approved hashes from remotely supplied index hashes, which do not meet the same tampering-protection requirement.[5]
Use a reviewed, fully resolved requirements file in a disposable build worker, and promote the resulting artifact only after validation. This proposed workflow combines pip's pinned, hash-checked installation with a separate organizational approval boundary.[5] Pip documents that an omitted, unhashed dependency causes an error in hash-checking mode; treat that error as a failed release gate.[5]
Docker recommends multi-stage builds, trusted minimal base images, and digest pinning for reproducible base-image selection.[7] Its documentation also explains the trade-off: pinning prevents automatic movement to newer fixes, so updates need a managed process.[7] Rebuild and retest deliberately rather than treating an old approved digest as permanent permission to deploy.[7]
Practical release and incident checklist
Use the following as a proposed acceptance checklist, adapting the controls to your platform:
- Inventory: link the deployed release to its component manifest and named owner, following OWASP's inventory guidance.[1]
- Review: approve custom loader changes at a specific revision, following the versioned Transformers guidance.[2]
- Verify: check the intended signing identity and issuer before promotion.[3]
- Provenance: match the artifact digest and expected build inputs, rather than filing an unchecked attestation.[4]
- Dependencies: reject incomplete hash-checked requirements instead of weakening pip's enforcement.[5]
- Rebuild: schedule reviewed base-image updates and retain the previous tested digest for rollback.[7]
Prepare the incident path before a suspicious artifact appears. NIST SP 800-61 Rev. 3 integrates incident-response considerations throughout cybersecurity risk management and emphasizes preparation, detection, response, and recovery.[8] For this reference design, the first response is to stop promotion, preserve the suspect digest and logs, and identify deployments linked to that release.
Then isolate affected workers, revoke potentially exposed credentials through the responsible identity team, and rebuild from an independently approved baseline. These are proposed runbook steps consistent with NIST's integrated response-and-recovery approach, not evidence that a particular deployment has been compromised.[8] NIST describes the intended outcome as reducing incident impact while improving detection, response, and recovery effectiveness.[8]
Takeaway
The defensive goal is an explainable release decision. OWASP's supply-chain guidance, Cosign's signer checks, and SLSA's provenance verification cover complementary parts of that decision.[1][3][4] Keep artifact identity, code review, behavior testing, and operational recovery as separate gates, with evidence an on-call engineer can actually retrieve.
Sources
- [1] https://genai.owasp.org/llmrisk/llm032025-supply-chain
- [2] https://huggingface.co/docs/transformers/v4.44.1/custom_models
- [3] https://docs.sigstore.dev/cosign/verifying/verify
- [4] https://slsa.dev/spec/v1.2/verifying-artifacts
- [5] https://pip.pypa.io/en/stable/topics/secure-installs
- [6] https://huggingface.co/docs/hub/security-pickle
- [7] https://docs.docker.com/build/building/best-practices
- [8] https://csrc.nist.gov/pubs/sp/800/61/r3/final
Post a Comment