9 værktøjer til model-SBOM'er og sporbarhed

---

CycloneDX og ML‑BOM: standarden til at beskrive ML‑artefakter

CycloneDX er i dag en af de mest udbredte SBOM-standarder (Software Bill of Materials). Formatet - der findes i både JSON, XML og Protobuf - beskriver komponenter, deres relationer og metadata i et entydigt skema, der kan valideres og udbygges af eksterne værktøjer.
Hvor CycloneDX oprindeligt blev født til klassisk software, arbejder standardens arbejdsgruppe nu på en ML-BOM-profil, der kan beskrive hele ML-livscyklussen - fra datasæt og træningsmiljøer til færdige modelartefakter og pipelines.

Hvorfor cyclonedx til machine learning?

1. Interoperabilitet: Formatet er allerede understøttet af mere end 80 økosystem-værktøjer (CI/CD, DevSecOps, container-scannere osv.).
2. Udvidelses­venligt: Custom <properties> og nye type-felter gør det let at tilføje ML-specifikke begreber uden at bryde skemaet.
3. Graph-model: Det indbyggede dependencies-felt gør det muligt at kortlægge, hvordan en model er bundet til data, træningskode, base-images og hardwaredrivere.
4. Licens & compliance: CycloneDX bærer allerede licens- og copyright-felter, som kan genbruges til at dokumentere licensforpligtelser for både datasets og pretrained modeller - vigtigt mht. NIS2 og kommende EU AI Act.

Den spirende ml-bom-profil

Arbejdstitlen ML-BOM er indtil videre en profil oven på CycloneDX 1.6, der introducerer fire nye type-kategorier:

Nyt component-type	Beskrivelse
ml-model	Selve binæren (fx onnx, safetensors, pkl) eller pakkede weights.
ml-dataset	Trænings-, evaluerings- eller inference-data. Kan pege på DVC-remote, S3, Hugging Face m.m.
ml-pipeline	En orchestreret række skridt (Airflow-DAG, Kubeflow-pipeline) der genererer modelartefakter.
ml-runtime	Kørselstid (CUDA-driver, Triton-server, ONNX-Runtime) og tilhørende konfiguration.

Hver komponenttype kan detaljeres med properties som accuracy, precision, dataset_split, framework og hyperparameters. Alle felter valideres via en separat schema extension, så eksisterende CycloneDX-parseres kompatibilitet bevares.

Sådan opbygger du en ml-bom i praksis

1. Installér CycloneDX-CLI
   

   pip install cyclonedx-bomcyclonedx --help

2. Beskriv modelartefaktet
   

   cyclonedx \ --input-file ./models/resnet50.onnx \ --type ml-model \ --output-file resnet50-sbom.json

   CLI’en udregner SHA-256, finder filstørrelse og tilføjer en ml-model komponent.
3. Udvid med data og miljø
   Brug --component til at tilføje datasets og base-images:

   cyclonedx add-component \ --bom resnet50-sbom.json \ --name "ImageNet 1k" \ --type ml-dataset \ --version "2021-10" \ --properties split=train,license=MIT

4. Knyt afhængigheder
   

   cyclonedx add-dependency \ --bom resnet50-sbom.json \ --from resnet50.onnx \ --to "ImageNet 1k"

   Nu fremgår det eksplicit, at modellen er trænet på ImageNet.

Fin granularitet gennem skema­udvidelser

Hvis du har behov for endnu mere detaljer, fx at gemme hyperparametre eller GPU-arkitektur, udvider du blot BOM’en med egne <property>-felter:

"properties": [ { "name": "ml:framework", "value": "PyTorch 2.1" }, { "name": "ml:epochs", "value": "90" }, { "name": "ml:gpu", "value": "A100" }]

Fordi CycloneDX validerer navnerum, kan ml:-præfikset registreres officielt, hvilket gør BOM’en både maskin- og menneske-læsbar på tværs af organisationer.

Når sbom møder ci/cd

Når BOM’en er genereret, kan den:

• tjekkes ind i repo’et sammen med model-binær og træningskode,
• skubbes til OWASP Dependency-Track eller OpenSSF GUAC for compliance-scanning,
• signeres med cosign, så både artefakt og SBOM er kryptografisk bundet.

Resultatet er en maskinlæsbar kontrakt om modellens oprindelse, afhængigheder og licenser. Dermed bliver CycloneDX (med ML-BOM-profilen) et centralt knudepunkt for sporbarhed i hele AI-værdikæden - fra datasæt til produktion.

---

SPDX 3.0 for AI: interoperabel SBOM på tværs af værktøjskæden

SPDX har længe været den fællesnævner, når open-source-pakker skal beskrives, men i version 3.0 tager formatet et kvantespring mod en mere generisk, graf-orienteret informationsmodel, som passer perfekt til moderne AI-workflows.

Hvad er nyt i 3.0 - Og hvorfor vigtigt for ml?

• Graf-model: Alle enheder beskrives som Elements (Package, File, Data, m.fl.) forbundet af typed relations (GENERATED_FROM, DEPENDS_ON, DESCRIBES …). Det gør det muligt at modellere et træningsforløb lige så naturligt som et traditionelt software-build.
• Profiles & Namespaces: Man kan definere en “ML-profile” med ekstra egenskaber (f.eks. ml:framework, ml:parameterCount), uden at bryde interoperabiliteten.
• Unified Licensing: Flere licenser på samme artefakt beskrives med SPDX License Expressions - uundværligt når weights, kode og data har forskellige vilkår.
• Eksterne referencer: Hugging Face-model-IDs, OCI-digests, S3-urls m.m. kan knyttes på via ExternalReference, så samme SBOM kan bruges i både udvikling, compliance og drift.

Sådan kan en ml-sbom se ud i spdx 3.0 (json)

{ "SPDXID": "SPDXRef-DemoSBOM", "name": "fraud-detection-stack", "elements": [ { "SPDXID": "SPDXRef-Model", "type": "Package", "name": "bert-fraud-detector", "checksums": [{ "alg": "SHA256", "value": "4ab6…" }], "properties": { "ml:framework": "PyTorch", "ml:parameterCount": 108893440 }, "licenses": [ "LicenseRef-MIT-Model" ] }, { "SPDXID": "SPDXRef-Data", "type": "Data", "name": "transactions-2023-05", "checksums": [{ "alg": "SHA256", "value": "91be…" }], "licenses": [ "CC-BY-4.0" ] } ], "relationships": [ { "spdxElementId": "SPDXRef-Model", "relatedSpdxElement": "SPDXRef-Data", "relationshipType": "GENERATED_FROM" } ]}

Eksemplet viser, hvordan modellen (Package) relateres til det dataset, den er trænet på, og hvordan vi allerede kan gemme oplysninger, der senere skal bruges af både DevOps og jurister.

Værktøjer, der allerede taler 3.0

1. spdx-tools
   Python-sdkʼen (pip install spdx-tools) kan både parse, validere og emit SPDX 3.0 i JSON, YAML og Tag/Value. Ideel til CI-pipelines.
2. spdx-sbom-generator
   CLI der scanner language-pakkehåndterere (npm, pip, Maven, Go mod…) og udskriver 3.0-SBOM’er. Bruges til at dokumentere inference-containere eller trænings-images.
3. Hugging Face + custom scripts
   Et simpelt Python-skript kan hente modelkort (modelcard.json) og konvertere dem til SPDX-Data/Package-elementer med spdx-tools.

Bro mellem dev, compliance og drift

Fase	Problem	SPDX 3.0 løsning	NIS2 / AI Act fokus
Udvikling	Mange afhængigheder, uklar licens	SBOM genereres automatisk i CI; licenser valideres (MIT AND CC-BY-4.0)	Dokumentér “state-of-the-art” sikkerhed & IPR
Compliance	Skal vise, hvilke data og modeller der bruges hvor	Query på GENERATED_FROM-relationer giver audit-spor	AI Act krav - “konformitetserklæring”
Drift	Sårbar libcudnn i produktion	Syft/Grype finder CVE; SPDX relaterer libcudnn til kørende modell	NIS2 kræver hurtig afhjælpning

Hurtig start i din pipeline

1. Tilføj spdx-sbom-generator som step i GitHub Actions (job: generate-sbom).
2. Valider med spdx-tools Verify for at sikre 100 % schema-compliance.
3. Upload SBOM til artefakt-repo (JFrog/Artifactory) og til OWASP Dependency-Track for løbende overvågning.
4. Tilknyt SBOM-filens digest til OCI-image med cosign attach sbom - så følger beviset med helt til Kubernetes.

Med SPDX 3.0 behøver AI-teams ikke længere opfinde proprietære metadata-filer for at beskrive modeller og data; de kan i stedet stå på skuldrene af et veletableret økosystem, som både sikkerheds- og compliance-folk allerede har tillid til.

---

Syft + Grype: automatisk SBOM og sårbarhedsscanning af ML‑miljøer

Med Syft og Grype kan du få et et-to-slag til henholdsvis at katalogisere og risikovurdere hele dit ML-miljø - fra den Alpine-baserede micro-service til den tunge CUDA-container, der kører træning på multi-GPU-noder. Nedenfor ser du, hvordan værktøjerne spiller sammen, og hvordan resultaterne kan flettes ind i din samlede model-SBOM.

1. Generér en sbom med syft - Container, wheel eller mappe

# Container (trænings-image)syft ghcr.io/company/ml-training:1.2 \ -o cyclonedx-json \ --file sbom-training.json# Wheel (distribueret model)syft my_model-0.3.1-py3-none-any.whl \ -o spdx-json \ --file sbom-model.json# Lokalt virtualenv (Jupyter-miljø)syft /opt/venvs/lab_env \ -o cyclonedx-json \ --file sbom-lab.json

Syft kravler igennem:

• Base-OS lagene (Ubuntu, Alpine, RHEL) og sniffer APT/YUM/APK-pakker.
• Python-afhængigheder fra site-packages, inkl. pip-install’ede .whl-filer.
• Biblioteker i /usr/lib - BLAS, cuDNN, NCCL, OpenMPI m.m.

Uddata er en CycloneDX- eller SPDX-fil, der lister hvert artefakt med hash, version, licens og CPE/PURL.

2. Berig sbom’en med ml-metadata

Selve modellen kan beskrives som et <component type="ml-model"> i CycloneDX. Føj f.eks. følgende uddrag til sbom-model.json før den lægges i repoet:

{ "type": "component", "name": "fraud-detector", "version": "0.3.1", "purl": "pkg:mlmodel/[email protected]", "hashes": [{ "alg": "SHA-256", "content": "..." }], "evidence": { "classifier": "ml-artifact", "properties": [ { "name": "framework", "value": "PyTorch 2.1" }, { "name": "parameters", "value": "{epochs: 30, lr: 3e-4}" } ] }}

3. Scan sbom eller image med grype for cve’er

# Direkte på container-imagegrype ghcr.io/company/ml-training:1.2 \ --output json \ --file cve-training.json# Eller genbrug Syft-genereret SBOMgrype sbom:sbom-training.json \ --file cve-training.json

Fordele ved SBOM-input: scanningen er hurtigere, og du kan opbevare CVE-rapporten som artefakt sammen med modellen.

4. Knyt findings til model-sbom’en

Component	Version	CVE	Severity	Fix
libcudnn8	8.9.2	CVE-2024-12345	High	8.9.4
numpy	1.23.4	CVE-2023-09876	Medium	1.26.0
openssl	3.0.2	CVE-2023-2650	Critical	3.0.9

Tilføj tabellen som <vulnerability-bom> i CycloneDX eller som hasVulnerability relationer i SPDX 3.0. På den måde kan downstream-teams (MLOps, SOC, governance) slå op, hvilke modelversioner der medbringer libcudnn8 v8.9.2 og planlægge patches proaktivt.

5. Automatiser i ci/cd

1. Build-job kører Syft og uploader SBOM som artefakt.
2. Security-job trigges og kører Grype på SBOM’en.
3. Policy-gate: bloker release hvis severity>=High og fix er tilgængelig.
4. Upload både SBOM og CVE-rapport til f.eks. OWASP Dependency-Track eller OpenSSF GUAC.

Ved at gøre Syft + Grype til en fast makker i din ML-pipeline får du automatiseret synlighed, compliance og risikoreduktion - helt ned i det lag, hvor Tensor-cores møder Python-koden.

---

OWASP Dependency‑Track: styring af SBOM’er og politikker for modeller

Mens CycloneDX og SPDX giver selve strukturen til at beskrive ML-artefakter, er OWASP Dependency-Track motoren, der holder SBOM’erne i live, overvåger dem for nye trusler - og håndhæver de regler, din organisation sætter op.

Fra model-sbom til håndgribelige indsigter

1. Import i ét klik (eller API-kald)
   Upload en CycloneDX- eller SPDX-fil via UI’et, CLI’en eller REST-end-pointet /api/v1/bom. Dependency-Track opretter et projekt per SBOM, uanset om artefakten er:
   • Et Docker-image med pyTorch-runtime
   • En .whl-fil til inferens
   • Selve model-binæren - f.eks. .safetensors eller .onnx
2. Normalisering af data
   Komponent-identitet (PURL, CPE, hash) normaliseres, så den samme libcudnn.so genkendes på tværs af builds og teams.
3. Risikoscorer i realtid
   Dependency-Track abonnerer på NVD, GitHub SA, osv. - og matcher CVE’er mod dine komponenter. En ny CVE i openssl hæver straks risikoniveauet for alle modeller, der linker statisk til biblioteket.

Ml-specifik licens- og policy-styring

Funktion	Eksempel
Licensdetektion	Dependency-Track identificerer, at dataset-pakken common_voice bruger CC-BY-SA og markerer modellen som share-alike-pligtig.
Politikregler	Bloker GPL-3.0 i modelkode. Advar hvis CUDA-driver < 12.0 findes. Påkræv CVSS < 7.0 for produktion.
Arvekæde	Ændrer status én komponent fra tilladt til forbudt - alle afhængige modeller flagges.

Workflows, der virker til ml-teams

1. CI/CD-check
   I build-pipelines kalder du dt-cli:

   syft model-image:latest -o cyclonedx | \dt-cli --api http://track:8081 --token $DT_TOKEN \ upload --project "bert-finetuned" --version $GIT_COMMIT

   Builden kan fejle, hvis politisk gate returnerer HTTP 412.
2. Model-livscyklus
   Dependency-Track’s project versions matcher ML-modellens versioner (v0.3-alpha, 2024-05-29). Dashboards gør det nemt at følge:
   • Hvordan risiko ændrer sig fra v0.2 ➜ v0.3
   • Hvilke licenser der tilføjes, når du skifter tokenizer
3. Tværgående teams
   Tagging (f.eks. nlp, cv, research, prod) gør det let at filtrere - governance-teamet kan overvåge alle “prod”-tags for blocker violations.

Udvidelser, der giver endnu mere sporbarhed

• Webhook-integration: Push alerts til Slack/Jira når en model rammes af en kritisk CVE.
• Graf-visning: Dependency-Track 4.x har Neo4j-dreven visning, hvor du kan se sammenhænge mellem dataset-pakkers licenser og afhængige modeller.
• SBOM-diffs: Se præcis hvilke komponenter der ændrede sig mellem to modelversioner - uvurderligt når en performance-regression skal spores til en ny numpy.

Sådan kommer du i gang

1. Spin Dependency-Track op via Docker Compose (postgres + front-end + api).
2. Opsæt LDAP/SAML, så forskere og DevOps deler samme single sign-on.
3. Automatisér SBOM-upload i dine GitHub Actions / GitLab-jobs.
4. Definér dine første politikker - f.eks. “Ingen ukendt licens” og “Ingen CVSS > 8 i prod”.
5. Overvåg dashboardet, og brug rapporterne til både AI Act-dokumentation og NIS2-risikorapporter.

Med Dependency-Track som hub får du kontinuerlig overvågning af både klassiske softwarekomponenter og de nye ML-artefakter, der ellers let flyver under radaren - så din organisation kan levere modeller, der er sikre, lovlige og fuldt dokumenterede.

---

OpenSSF GUAC: grafer der forbinder SBOM, provenance og risiko

OpenSSF’s GUAC (Graph for Understanding Artifact Composition) binder resultater fra hele din supply-chain i én søgbar graf: SBOM’er, SLSA-/in-toto-attestationer, signaturer og sårbarhedsscanninger. I stedet for at gemme dokumenterne hver for sig omsætter GUAC metadataene til noder (artefakter, builds, pakker, deploys) og kanter (”produceret-af”, ”afhængig-af”, ”udsat-for CVE”, …). Resultatet er en live vidensgraf, der kan tilgås via GraphQL, REST eller Cypher - og som gør komplekse ML-forsyningskæder gennemskuelige på få sekunder.

Sådan samler guac dine data

1. Collectors lytter på OCI-registries, Git-repos, CI-log-streams, SBOM-feeds og CVE-databaser.
2. Ingester-pods parser CycloneDX, SPDX 3.0, in-toto-attestationer, cosign-signaturer, Grype-rapporter m.m.
3. Graph-backenden (ArangoDB eller Neo4j) lagrer alle relationer og versioner.
4. API-layer udsætter grafen til forespørgsler og webhook-events, så sikkerheds- og compliance-værktøjer kan reagere automatisk.

Eksempler fra ml-verdenen

Spørgsmål	Typisk forespørgsel	Business-værdi
Hvilke modeller arver den sårbare libcudnn.so 8.9.2?	{ artifacts(cpe:"cpe:/a:nvidia:libcudnn:8.9.2") {  dependsOn { … } } }	Muliggør targeted patch- eller rollback-plan i produktion.
Hvilke deployments bruger datasættet eu-faces-v3 (GDPR-restriktion)?	MATCH (d:Dataset {name:"eu-faces-v3"})-[:CONSUMED_BY]->(m:Model)-[:DEPLOYED_AS]->(svc:Service) RETURN svc	Sikrer licens- & privatlivsoverholdelse før gen-træning eller eksport.
Er alle modeller i staging bygget under SLSA 3+?	{ services(env:"staging") { model { build { slsaLevel } } } }	Automatiseret gate i CI/CD, så kun dokumenteret provenance når produktion.
Vis hele kæden fra pull request til running container	guac trace --artifact 3e4f... --output graph	Forenkler audits og incident response.

Eksempel-workflow for et ml-projekt

1. CI-pipelinens Syft job genererer en CycloneDX-SBOM for hvert træningsimage.
2. in-toto-go signer træningskørslen med hyperparametre og dataset-hashes.
3. cosign signerer både model-artefakt (.onnx) og SBOM.
4. GUAC Collector opdager de nye OCI-digests, henter SBOM, attestation og signatur og indtager dem.
5. Grype scanning føjes som vulnerability findings på de relevante noder.

Best-practices når du arbejder med guac

• Brug det samme digest som nøgle i SBOM, in-toto og signatur for at sikre entydige noder.
• Normalisér modelklassifikation (fx type=model, framework=pytorch) i SBOM’en, så grafsøgning bliver simpel.
• Planlæg TTL-strategi: gamle byggejobs kan slettes, mens nodes med deployments bevares.
• Opsæt policy-hooks: GUAC kan trigge Slack/webhooks når en ny CVE rammer en aktiv model.

GUAC er stadig ung, men flere cloud-udbydere tilbyder allerede hosted præ-view-instanser. Fordelen for ML-teams er klar: én sandhedskilde, hvor kode, data, modeller og runtime-risici er knyttet sammen - og hvor spørgsmål, der før krævede dage med logs og manuelt detektivarbejde, besvares på få millisekunder.

---

in‑toto + SLSA: dokumenteret trænings‑ og byggeproveniens

Når vi går fra klassisk software til machine-learning, udvides forsyningskæden markant: rå data, feature-engineering, træningskørsler på delte GPU-clustre og finpudsning på edge-devices er alle led, som en angriber - eller en auditør - bør kunne følge. Her kommer in-toto og SLSA (Supply-chain Levels for Software Artifacts) på banen som det dokumentations- og tillidslag, der binder model-SBOM’en sammen med håndfaste beviser.

1. In-toto: Kryptografisk kvittering for hvert ml-trin

1. Definér layoutet
   I et root.layout beskriver vi alle trin i pipeline-en - fx fetch_data, preprocess, train, eval og package_model. For hver step angives:
   • material rules: hvilke input-filer der må forbruges (fx et DVC-snapshot med bestemt hash).
   • product rules: hvilke artefakter der skal produceres (fx model.onnx).
   • expected command: den eksakte CLI (inkl. hyperparametre) som skal køres.
   • pubKeys: hvilke udviklere eller byggesystemer der må signere trinnet.
2. Opsaml link-attestationer
   Hvert trin genererer en .link-fil, som indeholder:
   • SHA-256 hashes af materialer og produkter.
   • Miljømetadata: GPU-driver-version, CUDA-hash, pip-freeze osv.
   • Tidsstempel og underskrift fra den private nøgle, der svarer til pubKey i layoutet.
3. Verificér kæden i CI/CD
   Kommandolinjen in-toto-verify \--layout root.layout \--layout-keys root.pub sikrer, at:
   • alle regler er overholdt
   • ingen uautoriserede filer eller nøgler har sneget sig ind
   • artefakt-hashene matcher dem, vi senere refererer til i SBOM’en

2. Slsa-niveauer til ml: Hvad kræves?

SLSA-niveau	ML-eksempel	In-toto artefakt
Level 1 (Provenance)	train.py køres manuelt på udvikler-laptop.	Én link-fil med build-script og model-hash.
Level 2 (Tamper-evidence)	Automatiseret GitHub Actions-workflow trækker data fra S3 og saver model i Artifactory.	Signeret layout, CI-identitet som nøgle, attestationer arkiveres.
Level 3 (Isolated builds)	Træning kører i isoleret Kubernetes-namespace på Dedikeret GPU-pool med hermetisk base-image.	Link-filer verificerer base-image-hash (Syft-SBOM) + data-snapshot-identitet.
Level 4 (Reproducible)	Bit-for-bit deterministisk træning med faste random-seeds; output kan genskabes af tredjepart.	Samlet in-toto kæde, der valideres af uafhængig builder. KRAV: dokumenteret data-version, hyperparametre og hardwarefingeraftryk.

Ved at kortlægge pipeline-en til SLSA-niveauerne kan organisationen måle sin modenhed og opstille policy gates: Kun modeller, der lever op til SLSA-3, må fx bruges i produktion efter 1. januar 2025.

3. Sådan bindes attestationerne til din model-sbom

1. Indlejring i CycloneDX
   I components.evidence kan du linke til *.link-filer eller lægge dem inline (Base64-encodet). Eksempel:

   { "type": "file", "name": "model.onnx", "hashes": [{ "alg": "SHA-256", "content": "ae34…" }], "evidence": { "origin": "in-toto", "proof": "https://rekor.example.com/entry/abcd1234" }}

   Nu kan enhver SBOM-consumer slå attestationen op og kryptografisk verificere artefaktet.
2. SPDX 3.0 / relationships
   Alternativt angives HAS_PROVENANCE-relation fra Package model.onnx til Artifact in-toto-bundle.tar.gz.
3. Signér det hele
   Brug cosign attach attestation \::\ til at lægge både SBOM og in-toto-bundles i container-registryen som OCI-artefakter. Dermed følger beviserne modellen til både staging- og produktions-clusters.

4. Fordele i praksis

• Auditerbarhed: Ved en NIS2-/AI-Act-inspektion kan du på én kommando dokumentere, hvilket dataudtræk og hvilke hyperparametre, der ligger bag en given release.
• Incident response: Finder du en sårbar numpy-version, spørger du blot: “Hvilke in-toto-attestationer refererer til den hash?” - og får listen over påvirkede modeller.
• Reproducerbar forskning: Kollegers PR’er afvises automatisk, hvis ikke verify-steppet kan genskabe bit-ækvivalent output.

in-toto og SLSA skaber altså krypterede, efterprøvelige fodspor for alt fra datadumps til træningsskemaer. Når disse fodspor kobles tæt til SBOM’en, får vi en fulddækkende forsyningskædehistorik, som følger modellen hele vejen fra Jupyter-notebook til production inference.

---

Sigstore (cosign/rekor): signering og verifikation af modeller og SBOM’er

En underskrevet model er ikke blot en pæn compliance-detalje; den er et konkret værn mod supply-chain-angreb, model-forbytninger og utilsigtet drift af ukendte binærfiler. Sigstore-økosystemet (cosign, rekor, fulcio m.fl.) gør det muligt at indføre kryptografisk integritet uden at jonglere med hjemmelavede PKI-løsninger og hemmelige nøgler på build-servere.

Fra rå fil til underskrevet artefakt

1. Byg modellen
   En trænings-pipeline producerer f.eks. model.onnx og en CycloneDX-SBOM model.sbom.json. Begge pushes til et OCI-register (harbor, ghcr.io, GCR osv.) som “blobs”:

   # skub ONNX som generisk artefaktoras push ghcr.io/acme/models/model:v1 \ --artifact-type application/onnx \ --file model.onnx# skub SBOM som separat tagoras push ghcr.io/acme/models/model:v1-sbom \ --artifact-type application/vnd.cyclonedx+json \ --file model.sbom.json

2. Signér med cosign
   Cosign kan køre key-less via OIDC (GitHub Actions-identitet, Azure-Workload-ID, SPIFFE m.m.). Signaturen bliver selv en OCI-artefakt, der refererer til digesten af den underskrevne fil.

   # key-less signingCOSIGN_EXPERIMENTAL=1 \cosign sign ghcr.io/acme/models/model:v1 --yes# signér SBOM'en separatCOSIGN_EXPERIMENTAL=1 \cosign sign ghcr.io/acme/models/model:v1-sbom --yes

   Resultatet er to nye tags (sig-artefakter) samt ét eller flere certifikater, som placeres i den offentlige transparency-log Rekor.
3. Rekor-logning
   Cosign poster automatisk et log-entry til Rekor, der indeholder:
   • SHA-256 hash af artefaktet
   • X.509-certifikat eller OIDC-token
   • Selve signaturen (ECDSA)
   Transparenslaget betyder, at enhver kan tjekke, om et givent digest tidligere er signeret og af hvem.

Verifikation i ci/cd og runtime

Trin	Eksempelværktøj	Kontrol
Pull-tidspunkt	cosign verify	Tjek signatur + certifikat i Rekor, før artefakt hentes til build-miljø.
CI-pipeline	GitHub Actions / GitLab CI	Nægt promovering til “prod”-branch hvis cosign verify fejler.
Deploy-tidspunkt	Sigstore Policy Controller, Kyverno, OPA-Gatekeeper	Admission webhook afviser pods, der refererer til usignerede modeller eller til modeller, hvis SBOM-tag ikke er signeret.

Politikker: “intet sbom - Intet deploy”

Ved at koble signaturen til SBOM-digesten via cosign-annotationer (-a sbom-digest=sha256:…) kan man formulere simple OPA- eller Kyverno-regler:

deny[msg] { some i input.review.object.spec.containers[i].image =~ "ghcr.io/acme/models/.+" not sigstore.valid_signature_with_sbom(input.review.object.spec.containers[i].image) msg := "Modelen er ikke signeret eller mangler verificeret SBOM"}

Reglen sikrer, at kun modeller, der både er:

• signeret af et betroet OIDC-subject (fx “github.com/acme/ml-pipeline@refs/heads/main”)
• linker til en verificeret SBOM-artefakt

kan køre i produktions-klyngen.

Bedste praksis

1. Underskriv alle binære ML-artefakter og deres SBOM’er - aldrig kun containere.
2. Brug key-less OIDC så build-nøgler ikke ligger og flyder.
3. Automatisér verifikation i både CI og Kubernetes admission-lag.
4. Log alt i Rekor; det giver gratis revisionsspor og beviser til audit (NIS2/AI-forordningen).
5. Kombinér cosign-signaturer med SLSA-attestationer for at dokumentere hvordan modellen blev bygget.

Sigstore-modellen rykker signering fra at være et manuelt, “PKI-tungt” specialhensyn til at være et integreret, automatiseret led i ML-livscyklussen - præcis det, der skal til for at kunne rulle modeller ud med høj hastighed og høj tillid.

---

DVC + Git‑LFS: versionsstyring og sporbarhed for data og modeller

Når datamængderne løber op i gigabytes, og model-binærerne fylder hundreder af megabyte, bryder klassisk Git hurtigt sammen. Kombinationen af DVC (Data Version Control) og Git-LFS giver et letvægts-alternativ til tunge artefakt-repositories - og skaber samtidig de entydige material-referencer, som en moderne model-SBOM kræver.

1. Git-lfs: Store filer, men samme commit-historik

• Pointer-filer i repoet – Git-LFS erstatter selve filindholdet med en lille tekstfil, som indeholder SHA-256-hash og filstørrelse.
• Indhold på remote – binærerne sendes til en LFS-server (fx GitHub LFS eller en self-hosted MinIO-bucket).
• Fordel: udviklere kan stadig branch’e, merge’e og bisect’e, mens kloner er hurtige, fordi de store filer hentes on demand.

2. Dvc: Deklarativ styring af data, modeller og pipelines

1. Track store artefakter
   

   # Track rå training-datadvc add data/raw/imagenet.tar.gz# Track færdigtrænet modeldvc add models/resnet50.safetensors

   DVC opretter .dvc-filer med SHA-256-hash + størrelse. Filerne lægges i Git, mens indholdet push’es til en DVC-remote (S3, Azure Blob, SSH, …).

2. Definér pipelines som kode
   

   dvc.yamlstages: preprocess: cmd: python prep.py --in data/raw --out data/clean deps: [data/raw, prep.py] outs: [data/clean] train: cmd: python train.py --data data/clean --out models/resnet50.safetensors deps: [data/clean, train.py] outs: [models/resnet50.safetensors] metrics: - metrics.yml

   Hver stage er fuldt deklarativ; hashes på deps og outs sikrer reproducérbarhed.

3. Eksperimenter og metrics-tracking
   

   # Start et eksperiment med nye hyperparametredvc exp run --set-param train.lr=0.001# Sammenlign resultatetdvc exp diff

   DVC gemmer metrics (fx accuracy, F1) i YAML/JSON, så man kan grafe performance over tid.

3. Fra dvc-objekt til sbom-komponent

For at binde model-artefakterne til resten af supply-chain-historikken skal deres identiteter over i SBOM-filen. Det sker gennem material-referencer – CycloneDXs <component type="file"> eller SPDX3s Artifact-objekt.

Artefakt	Hash (DVC)	SBOM-felt
models/resnet50.safetensors	sha256:4a0d…​c12e	CycloneDX <hash>
data/raw/imagenet.tar.gz	sha256:9f3e…​b77a	SPDX Checksum

<component type="file"> <name>resnet50.safetensors</name> <version>2024-05-30</version> <hashes> <hash alg="SHA-256">4a0d...c12e</hash> </hashes> <externalReferences> <reference type="distribution"> <url>s3://ml-artifacts/models/resnet50/4a0d...c12e</url> </reference> </externalReferences></component>

Når Syft eller dvc bom (eksperimentel feature) genererer SBOM’en, sluger den DVC-metrik-filerne og LFS-pointerne, løfter SHA-hashene op som officielt SBOM-evidence og linker til objekterne i S3. Dermed kan Dependency-Track eller GUAC svare på spørgsmål som:

• Hvilke udsatte deployments bruger et data-snapshot, der er under licens-restriktion?
• Hvilke modelversioner arver en CVE i et bestemt ONNX-runtime wheel?

4. Reproducerbar end-to-end audit

1. Checkout et historisk Git-tag med tilhørende .dvc-filer.
2. dvc pull henter præcis de data- og model-artefakter, hvis hashes optræder i SBOM’en.
3. dvc repro genkører pipeline-stages; uoverensstemmelser i output-hash trigger alarm.
4. cosign verify (fra tidligere sektion) validerer signaturen på modellen og SBOM’en.

Med dét er cirklen lukket: Git giver kildekode-historik, Git-LFS gemmer store filer uden at fragmentere repoet, DVC binder data, modeller og pipelines sammen, og SBOM’en dokumenterer resultatet i et standardformat, som både sikkerhedsteamet og regulatoriske auditører kan forstå.

---

OpenLineage + Marquez: end‑to‑end lineage fra data pipelines til deployment

OpenLineage er kort fortalt et open-source standard-skema og en samling “agents”, der automatisk udsender hændelser om, hvilke input-datasets, kode-jobs og output-artefakter der indgår i en kørsel. Når hændelserne lander i Marquez, gemmes de som en tidsstemplet graf, som udviklere og compliance-teams kan udforske i både UI og via REST/GraphQL-API’er.

Fra rå data til produktionsmodel - Et eksempel

1. Airflow-DAG ingest’er rå klik-logs fra S3 - openlineage-airflow plug-inet sender START/RUN/COMPLETE-events.
2. Spark (med openlineage-spark) renser og aggregerer logs til et feature-parquet-sæt.
3. En Kubernetes Job starter et trænings-script i en container med CUDA + PyTorch. Jobben er instrumenteret med openlineage-kubernetes, så output-artefaktet (f.eks. model.onnx) registreres.
4. Til sidst deployer CI/CD-pipen modellen til et inference-endpoint, stadig under et OpenLineage-“job”, så Marquez kender sammenhængen helt frem til production run.

Visualiseret i marquez

I Marquez’ UI kan du nu klikke dig gennem grafen:

• Data­sættet s3://raw-logs/2024-* → Spark job → features.parquet
• features.parquet → Kubernetes træningsjob → model.onnx
• model.onnx → Deploy job → inference-service:v42

Hver node har versions-hash, timestamp, kørsels-parametre og links til upstream/downstream. Dermed er det muligt at svare på spørgsmål som “Hvis rå-logs-skemaet ændrer sig, hvilke modeller skal så gen-trænes?”.

Sammenkæd lineage, sbom og attestationer

Artefakt	Lineage-kilde (OpenLineage)	SBOM-repræsentation	Attestation
Docker-image til træning	Kubernetes Job & containerID	Syft-genereret CycloneDX	SLSA provenance (in-toto)
features.parquet	Spark output-dataset URN	CycloneDX <component type="data">	DVC data-version
model.onnx	Kubernetes training job output	ML-BOM profil (CycloneDX)	cosign-signature + Rekor log

For at “lime” det hele sammen til fuld sporbarhed følges disse trin:

1. Reference-links - inkluder i din CycloneDX SBOM et <externalReference type="openlineage"> med dataset/job-URN’en fra Marquez. Omvendt tilføjer du Model-hashen som facets i OpenLineage-payloaden.
2. Attestations-nøgler - brug den samme subject.digest i både in-toto-statementen og i SBOM’ens hashes, så beviser kan korreleres automatisk.
3. GUAC-ingest - lad OpenSSF GUAC suge både Marquez-lineage, SBOM’er og attestationer ind. Dermed kan du køre en enkelt GraphQL-forespørgsel og få hele historikken fra datasæt til CVE’er.

Governance-gevinster

• Reproducerbarhed: Et Jira-ticket om performance-drop kan føre direkte til den præcise træningskørsel og underliggende data.
• Compliance: Ved audit kan du vise, hvilke persondata der har været igennem pipeline, og bekræfte, at modellen kun indeholder licenserede komponenter.
• Incident-respons: Når en sårbar libcudnn afsløres, filtrerer du hurtigt Marquez-grafen for alle modeller, der arver biblioteket (via SBOM-hash match).

Med OpenLineage + Marquez som nervebanen for dataflow kombineret med SBOM’er og supply-chain-attestationer får organisationen en ende-til-ende, revisionsklar kilde til, hvordan modeller skabes, versioneres og deployeres - helt ned på container- og datasæt-niveau.