Eksportskjema

Denne siden er skjemaet for den fullstendige dataeksporten: hva pakken inneholder, og hvilken form hver post har. Hvordan du starter en eksport, verifiserer den, og hvilke grenser som gjelder, står på siden om dataeksport. Databehandleravtalen §9 viser hit.

Pakkens oppbygning

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 (package and container downloads, uploads and deletes; CI cache hits are in pulled-versions.ndjson)
├── 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
    ├── deployments.ndjson             — deployments your CI/CD reported, see "Deployments" below
    ├── pulled-versions.ndjson         — package versions pulled per day and consumer, see "Pulled versions" 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

Repositorynavn med tegn utenfor a-z 0-9 . _ - vises med disse tegnene erstattet av _.

Standarder som brukes:

• Repositoryer: Gits eget git bundle-format. git clone <bundle> gjenoppbygger hele repositoryet, med historikk, brancher og tagger. Et repository uten commits har ingenting å pakke, og vises i stedet som en tom <repo>.empty-fil.
• Issues, pull requests og de andre metadata/-filene: NDJSON, ett JSON-objekt per linje, i samme form som Forgejo-API-et returnerer for hvert objekt.
• Revisjonslogg: NDJSON, én hendelse per linje (id, action, actor, fields_json, created_at). Samme form som fremforges interne revisjonsstrøm.
• Tilgangslogg for registeret: NDJSON, eldste først, én hendelse per linje i formen som GET /orgs/{slug}/access-log returnerer, med klient-IP-er og innlogginger slik de ble registrert. Den dekker alt som fortsatt oppbevares innenfor oppbevaringsperioden for revisjonsloggen din. Se Tilgangslogg for registeret.
• Integritet: manifest.json lister hver fil med SHA-256-hash og størrelse. Manifestet er DSSE-signert med fremforges Ed25519-byggenøkkel. Signaturen ligger i manifest.json.intoto.jsonl og verifiseres mot den offentlige tillitsroten på https://www.frem.sh/.well-known/slsa-trust-root.json med openssl, jq, python3 og curl, uten noe fremforge-verktøy. Hele oppskriften står i VERIFY.md inne i pakken og i §«Verifisere det signerte manifestet» på siden om dataeksport. Dette er den samme tillitsroten som publiseres for SLSA-byggeattesteringer: én nøkkel, to predikattyper, null avhengighet av Sigstore.

Ingen proprietære formater. Alt i pakken kan leses med vanlige åpen kildekode-verktøy. Ingen fremforge-CLI kreves.

Pakker

metadata/packages.ndjson er oversikten over organisasjonens pakkeregister: én linje per pakkeversjon, med type (container, npm, maven, pypi, generic, …), name og version, slik Forgejos pakke-API lister dem.

metadata/packages-files.ndjson lister hver fil i hver av disse versjonene, én linje per fil:

For containerimager er en pakkeversjon en tag (eller, for et manifest uten tag, som én plattform i et multi-arch-image, selve digesten). metadata/packages-container-tags.ndjson kobler hver tag til manifestets digest (owner, name, tag, manifest_digest), som er det docker pull <image>@sha256:… og andre OCI-verktøy bruker. Imagets lag og konfigurasjon vises i packages-files.ndjson som filer navngitt etter digesten, med download_path som peker til registerets endepunkter /v2/…/blobs/… og /v2/…/manifests/….

Sjekk en nedlastet fil mot oversikten:

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 -

Oversikten ligger alltid i pakken. Selve pakkefilene kommer bare på forespørsel, som et eget arkiv: se §«Innholdet i pakkene».

Komponentoversikt

metadata/components.ndjson er organisasjonens oversikt over tredjepartskomponenter: én linje per komponent og sted den brukes eller ble brukt, de samme radene som GET /orgs/{slug}/components/usages svarer med. Bruk som er avsluttet, beholdes i 180 dager og er med, slik at historikken følger med deg.

Utrullinger

metadata/deployments.ndjson inneholder hver utrulling CI/CD-en din rapporterte med POST /orgs/{slug}/repos/{repo}/deployments, én linje per utrulling, eldste først etter identifikator.

Pullede versjoner

metadata/pulled-versions.ndjson er pull-tellingen: én linje per UTC-døgn, pakkeversjon og forbruker, for dagene som fortsatt oppbevares innenfor oppbevaringsperioden for tilgangsloggen din. Siden 2026-10-13 er den eneste oversikt over nedlastingene en CI-jobb gjorde gjennom avhengighetsproxyen og som ble levert fra bufferen; disse står ikke i access-log.ndjson. Dette er radene som GET /orgs/{slug}/components/pulled summerer; sårbarhetsvarslene det endepunktet kobler på, er ikke med i filen.

Skannefunn, policy, attesteringer og SBOM-er

Hver eksport inneholder sikkerhetsdataene fremforge har om organisasjonen din, som NDJSON (ett JSON-objekt per linje), dekket av det signerte manifestet som alle andre filer. Hver linje er hele posten fremforge lagrer, unntatt den interne kunde-ID-en og lagringsstier. Avviste funn er med, sammen med hvem som avviste dem, hvorfor og til når. Rader som gjelder en pakke i registeret, 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, each with its licence policy decision
├── 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
├── package-access-packages.ndjson     — per-package access: each configured package (mode, inheritance)
├── package-access-grants.ndjson       — per-package access grants (teams, Actions repositories)
├── package-protection-rules.ndjson    — protected package names
├── scan-overrides.ndjson              — per-repository scanner mode overrides
└── settings/                          — each scanner's org settings (sast, dependencies, licences, container-images, secrets),
                                         and licence-repo-overrides.ndjson: per-repository licence policy overrides
                                         and package-access.ndjson: the per-package access default
                                         and retention.ndjson: one line per evidence retention class, with what you set,
                                         what applies, the default, the bounds and whether a legal hold is active
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

• Signaturene følger med attesteringene. Hver konvolutt verifiseres mot den samme tillitsroten som pakken, med skriptet i §«Verifisere det signerte manifestet» rettet mot konvolutten i stedet for manifest.json.intoto.jsonl (hopp over sjekkene av manifestSha256 og predicateType, som bare gjelder eksportpakker). Sigstore-bundlene er signert mot fremforges egen Fulcio og tidsstempeltjeneste, ikke offentlig Sigstore; se SLSA-proveniens.
• En manglende signatur vises, den skjules ikke. En linje med "envelope_status": "missing" er en attestering der signaturobjektet ikke lenger fantes i lagringen da eksporten kjørte. Alle andre lagringsfeil får eksporten til å feile.
• Containerlag. Skadevarevurderingen av et lag hører til innholdet, så et lag som deles med et annet image, listes med vurderingen under hvert av manifestene dine som bruker det. Imager som er pullet gjennom avhengighetsproxyen, listes bare så lenge organisasjonen din har ClamAV-skanning av proxyhentinger slått på. Når den er av (standard), skannes de ikke med ClamAV og har ingen lagvurderinger.
• Utgivelsesattesteringer finnes for repositoryer med uforanderlige utgivelser. En utgivelse med en status som ikke er signed, har ingen konvolutt (envelope_path er null).
• SBOM-er. sboms/ inneholder hver SBOM fremforge lagrer for repositoryene dine (utgivelses- og standardbranch-bygg, enten de er lastet opp eller laget av den sentrale skanningen) og for containerimagene dine (registerets oversikt per manifest), som selve dokumentet. Et repository-bygg har som regel både et CycloneDX- og et SPDX-dokument; se SBOM-er. Hver linje i sboms/index.ndjson er den lagrede SBOM-posten (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 av den lagrede posten, uten lagringsstier) pluss tre felter om filen i denne pakken: document_path, document_sha256 og document_status, som er ok når dokumentet stemmer med SHA-256 som ble registrert da det ble lagret, digest_mismatch når det ikke gjør det (bytene eksporteres likevel, og begge digestene står på linjen), og missing når dokumentet ikke lenger fantes i lagringen. Alle andre lagringsfeil får eksporten til å feile.
• Pakke-SBOM-er ligger ikke i sboms/. SBOM-en for hver pakkefil i registeret følger med ved siden av filen i arkivet med innholdet i pakkene, som du må be om.