Eksportskema

Oversat fra den engelske original. Hvis de to versioner er forskellige, gælder den engelske. Oversættelsen er endnu ikke korrekturlæst af en dansk modersmålsbruger.

Denne side er skemaet for den fulde dataeksport: hvad bundtet indeholder, og hvilken form hver post har. Hvordan du starter en eksport, verificerer den, og hvilke grænser der gælder, står på siden om dataeksport. Databehandleraftalen §9 henviser hertil.

Bundtets struktur

export-<your-org-slug>-<YYYY-MM-DDTHH-MM-SS-mmmZ>.tar.gz
├── VERIFY.md                          — step-by-step verification recipe
├── manifest.json                      — every file below, SHA-256 and size
├── manifest.json.intoto.jsonl         — DSSE-signed in-toto Statement over manifest.json
├── audit.ndjson                       — your org's audit events, last 90 days
├── access-log.ndjson                  — your registry access log (every package and container download, upload and delete)
├── bundles/
│   ├── <repo>.bundle                  — git bundle: full history, every ref
│   └── <repo>.empty                   — instead of a bundle, for a repository with no commits (zero bytes)
├── findings/                          — scan findings, see "Scan findings, policy, attestations and SBOMs" below
├── policy/                            — package policy, verdicts, exceptions and scanner settings
├── attestations/                      — build provenance and release attestations, with their signatures
├── sboms/                             — repository and container-image SBOMs, with an index
└── metadata/
    ├── packages.ndjson                — package inventory, see "Packages" below
    ├── packages-files.ndjson          — every file of every package version
    ├── packages-container-tags.ndjson — container image tag → manifest digest
    ├── components.ndjson              — third-party component inventory, see "Component inventory" below
    └── <repo>/
        ├── repo.ndjson                — repository settings, description, topics
        ├── issues.ndjson              — every issue, open and closed
        ├── pulls.ndjson               — every pull request, open and closed
        ├── comments.ndjson            — issue and pull-request comments
        ├── labels.ndjson
        ├── milestones.ndjson          — open and closed
        ├── releases.ndjson            — release metadata; see "Release assets" below
        └── lfs-manifest.ndjson        — LFS object inventory, see "LFS content" below

Repository-navne med tegn uden for a-z 0-9 . _ - vises med de tegn erstattet af _.

Anvendte standarder:

• Repositories: Gits eget git bundle-format. git clone <bundle> genskaber repository’et fuldt ud, inklusive historik, branches og tags. Et repository uden commits har intet at bundte og optræder i stedet som en tom fil, <repo>.empty.
• Issues, pull requests og de øvrige filer i metadata/: NDJSON, ét JSON-objekt pr. linje, i samme form som Forgejo API’et returnerer for hvert objekt.
• Revisionslog: NDJSON, én hændelse pr. linje (id, action, actor, fields_json, created_at). Samme form som fremforges interne revisionsstrøm.
• Adgangslog for registry’et: NDJSON, ældste først, én hændelse pr. linje i den form, GET /orgs/{slug}/access-log returnerer, med klient-IP’er og logins, som de blev registreret. Den dækker alt, der stadig opbevares inden for din opbevaringsperiode for revisionsloggen. Se Registry access log.
• Integritet: manifest.json lister hver fil med dens SHA-256-hash og størrelse. Manifestet er DSSE-signeret med fremforges Ed25519-builder-nøgle; signaturen ligger i manifest.json.intoto.jsonl og verificeres mod den offentlige trust root på https://www.frem.sh/.well-known/slsa-trust-root.json med openssl, jq, python3 og curl — intet fremforge-værktøj kræves. Den fulde opskrift står i VERIFY.md i bundtet og i §“Verificér det signerede manifest” på siden om dataeksport. Det er den samme trust root, som er offentliggjort for SLSA build-attestationer: én nøgle, to predicate-typer, ingen afhængighed af Sigstore.

Ingen proprietære formater. Hvert artifact i bundtet kan læses med almindelige open source-værktøjer. Intet fremforge-CLI kræves.

Pakker

metadata/packages.ndjson er oversigten over din organisations pakke-registry: én linje pr. pakkeversion med dens type (container, npm, maven, pypi, generic, …), name og version, som Forgejos pakke-API lister dem.

metadata/packages-files.ndjson lister hver fil i hver af de versioner, én linje pr. fil:

For container-images er en pakkeversion et tag (eller, for et manifest uden tag, som én platform af et multi-arch-image, selve digesten). metadata/packages-container-tags.ndjson knytter hvert tag til dets manifest-digest (owner, name, tag, manifest_digest), som er det, docker pull <image>@sha256:… og andre OCI-værktøjer bruger. Imagets lag og config står i packages-files.ndjson som filer navngivet efter deres digest, med download_path, der peger på registry’ets endpoints /v2/…/blobs/… og /v2/…/manifests/….

Tjek en downloadet fil mod oversigten:

row=$(jq -c 'select(.name=="@acme/lib" and .version=="1.2.0")' metadata/packages-files.ndjson)
curl -sSL -H "Authorization: token $TOKEN" -o pkg.bin "https://frem.sh$(jq -r .download_path <<<"$row")"
echo "$(jq -r .sha256 <<<"$row")  pkg.bin" | sha256sum -c -

Oversigten er altid med i bundtet. Selve pakkefilerne kommer kun på anmodning, som et separat arkiv: se §“Pakkeindhold”.

Komponentoversigt

metadata/components.ndjson er din organisations oversigt over tredjepartskomponenter: én linje pr. komponent og pr. sted, hvor den bruges eller har været brugt — de samme rækker, som GET /orgs/{slug}/components/usages svarer med. Anvendelser, der er ophørt, bevares i 180 dage og er med, så historikken følger med dig.

Scanningsfund, politik, attestationer og SBOM’er

Hver eksport indeholder de sikkerhedsdata, fremforge har om din organisation, som NDJSON (ét JSON-objekt pr. linje), dækket af det signerede manifest som alle andre filer. Hver linje er den fulde post, fremforge gemmer, bortset fra det interne tenant-id og lagerstier; afviste fund er med, sammen med hvem der afviste dem, hvorfor og indtil hvornår. Rækker, der vedrører en registry-pakke, har et package-objekt (type, owner, name, version, file, blob_sha256).

findings/
├── sast.ndjson                        — static analysis (rule, file, line, severity)
├── dependencies.ndjson                — dependency vulnerabilities, with CVSS and EPSS where known
├── dependency-dismissals.ndjson       — repository-wide dependency dismissals
├── licences.ndjson                    — licence findings
├── container-images.ndjson            — container image vulnerabilities
├── container-image-dismissals.ndjson
├── secrets.ndjson                     — rule, file, line and fingerprint; the secret value is never stored
├── malware-uploads.ndjson             — malware found in uploads
├── malware-dependencies.ndjson        — known-malicious dependencies
├── malware-container-layers.ndjson    — per image manifest, each layer's malware verdict
├── packages.ndjson                    — vulnerabilities found in your registry packages
├── package-licences.ndjson            — declared and detected licences of your registry packages
└── sha-pinning.ndjson                 — workflow actions not pinned to a commit
policy/
├── package-policy.ndjson              — your package policy (mode, thresholds, licence lists, minimum age)
├── package-policy-rules.ndjson        — allow and deny rules
├── package-policy-approvers.ndjson
├── package-policy-verdicts.ndjson     — the current verdict for each package file, with reasons
├── package-gate-decisions.ndjson      — downloads blocked, or that would have been blocked in shadow mode
├── exceptions.ndjson                  — policy exceptions, who requested and who approved them
├── malware-overrides.ndjson
├── scan-overrides.ndjson              — per-repository scanner mode overrides
└── settings/                          — each scanner's org settings (sast, dependencies, licences, container-images, secrets)
attestations/
├── build-provenance.ndjson            — one line per build provenance attestation
├── build-provenance/<id>.intoto.jsonl — its DSSE envelope (the Ed25519 signature)
├── build-provenance/<id>.sigstore.json — its keyless Sigstore bundle, where one was made
├── releases.ndjson                    — release attestations: subjects, the frozen release manifest, status, and envelope_path
├── sbom-ingest.ndjson                 — attestations uploaded together with an SBOM
└── sbom-ingest/<sbom id>.intoto.jsonl
sboms/
├── index.ndjson                       — one line per SBOM, see below
├── repos/<id>.cdx.json                — a repository SBOM, CycloneDX (<id>.spdx.json for SPDX)
└── images/<id>.cdx.json               — a container image SBOM

• Signaturerne følger med attestationerne. Hver envelope verificeres mod den samme trust root som bundtet, med scriptet i §“Verificér det signerede manifest” rettet mod envelopen i stedet for manifest.json.intoto.jsonl (spring tjekkene af manifestSha256 og predicateType over; de gælder kun eksportbundter). Sigstore-bundlerne er signeret mod fremforges egen Fulcio og tidsstempelautoritet, ikke den offentlige Sigstore; se SLSA provenance.
• En manglende signatur vises, den skjules ikke. En linje med "envelope_status": "missing" er en attestation, hvis signaturobjekt ikke længere lå i lageret, da eksporten kørte. Enhver anden lagerfejl får eksporten til at fejle.
• Container-lag. Et lags malware-afgørelse hører til dets indhold, så et lag, der deles med et andet image, listes med sin afgørelse under hvert af dine manifester, der bruger det.
• Release-attestationer findes for repositories med immutable releases. En release, hvis status ikke er signed, har ingen envelope (envelope_path er null).
• SBOM’er. sboms/ indeholder hver SBOM, fremforge gemmer for dine repositories (builds af releases og af default-branchen, uanset om de er uploadet eller lavet af den centrale scanning) og for dine container-images (registry’ets oversigt pr. manifest), som selve dokumentet. Et repository-build har som regel både et CycloneDX- og et SPDX-dokument; se SBOMs. Hver linje i sboms/index.ndjson er den gemte SBOM-post (id, subject_kind repo eller image, format, repo_full_name eller artifact_name, release_tag, image_tags, manifest_digest, created_at, sha256_digest og resten af den gemte post, uden lagerstier) plus tre felter om filen i dette bundt: document_path, document_sha256 og document_status, som er ok, når dokumentet matcher den SHA-256, der blev registreret, da det blev gemt, digest_mismatch, når det ikke gør (bytes eksporteres alligevel, og begge digests står på linjen), og missing, når dokumentet ikke længere lå i lageret. Enhver anden lagerfejl får eksporten til at fejle.
• Pakke-SBOM’er ligger ikke i sboms/. SBOM’en for hver pakkefil i registry’et følger med filen i arkivet med pakkeindhold, som du selv vælger til.