Pakkepolicyer

En pakkepolicy avgjør, fil for fil, om en pakke i organisasjonens register kan lastes ned. Den dekker registertypene fremforge hoster: npm, Maven, PyPI, NuGet, Cargo, Go, Conda, CRAN, Debian, RPM, Helm og generiske pakker, samt containerimager (se Containerimager). Hver organisasjon har én policy, med valgfrie innstillinger per pakketype.

Hva en policy sjekker

Når en fil publiseres, pakker fremforge den ut, lister komponentene som er pakket inn i den, og leser pakkens egen oppgitte lisens (se SBOM-er). Hver komponent matches mot sårbarhetsvarslene i OSV, og matches på nytt hver dag. Policyen evalueres mot disse resultatene, og vurderingen lagres for filen: allow, warn eller block. En endring i policyen, en liste eller et unntak evaluerer alle filer på nytt med én gang, uten ny skanning.

Ved nedlasting er det den lagrede vurderingen som avgjør. Dette skjer for nedlastinger gjennom register-API-et (/api/packages/…, som alle pakkebehandlere bruker) og fra webgrensesnittet. Pakkemetadata, som en npm-packument eller en PyPI simple-indeks, filtreres aldri. Når håndheving er på, får en resolver som ber om en blokkert versjon 403 for den filen; den blir ikke styrt mot en annen versjon.

Sårbarheter

Sårbarhetsregelen er bare på når en terskel for alvorlighetsgrad eller CVSS er satt. Er begge satt, teller et sårbarhetsvarsel som når én av dem.

Lisenser

Lisenser er SPDX-identifikatorer og sjekkes mot både den oppgitte lisensen og lisensene som oppdages i innpakkede komponenter.

Lisenslistene settes på siden lisenspolicy, ett sett regler for pull requests og nedlastinger. Siden Package policies lenker dit. Feltene nedenfor er nedlastingssiden av den policyen, og PUT /orgs/{org}/package-policy godtar dem fortsatt.

Uttrykk evalueres per operand. OR godkjennes når en hvilken som helst operand er tillatt, AND krever alle operandene, og X WITH exception evalueres som X.

Tillatelses- og blokkeringslister

En listeregel navngir en pakketype (eller alle typer), et navnemønster (jokertegnene * og ?, for eksempel @acme/* eller org.apache.logging.log4j:log4j-core) og et valgfritt versjonsintervall i vers:-syntaks, for eksempel vers:maven/<2.17.1. Intervallene følger hvert økosystems egne versjonsregler for npm, Cargo og Go (semver), PyPI (PEP 440), Maven og NuGet.

• match_target: package matcher pakken du publiserte.
• match_target: component matcher en komponent som er pakket inn i den.

En deny-regel blokkerer. En allow-regel på en pakke slipper den forbi reglene for sårbarheter, lisenser og alder, og en allow-regel på en komponent fritar den komponenten fra reglene for sårbarheter og lisenser. Allow-regler overstyrer aldri kjent skadevare eller en deny-regel. En regel kan ha en utløpsdato.

Minstealder

min_age_hours holder tilbake filer som er yngre enn så mange timer etter at de ble publisert, eventuelt bare for typene i age_types. Alderen avgjøres i nedlastingsøyeblikket, så en fil kan lastes ned så snart den er gammel nok. Lagrer du organisasjonens utgivelsesalder, settes den til så mange dager (0 slår den av); en type med sin egen minstealder i type_overrides beholder den.

En versjon som retter en kjent utnyttet sårbarhet (en CVE oppført i ENISAs EU Vulnerability Database eller CISAs KEV-katalog), holdes ikke tilbake: en rettelse for en sårbarhet som utnyttes i praksis, bør ikke vente. Aldersregelen vises fortsatt i avgjørelsen, merket som frafalt med CVE-en den ble frafalt for, så fritaket er synlig i vurderingen, revisjonsloggen og SIEM. En rettelse for en CVE som ikke er kjent utnyttet, venter som vanlig.

Alltid på

To sjekker kjøres uansett hva policyen sier, også med modusen satt til Off:

• Kjent skadevare. En fil som inneholder en pakke oppført i et OSV-varsel av typen MAL-*, avvises med 403 i alle moduser, også Shadow og Off. For å slippe én fil gjennom trengs et godkjent unntak for regelen malware. Se ondsinnede pakker.
• Navnekollisjon. Et sårbarhetsvarsel som navngir pakkens eget navn og versjon, som regel fordi en offentlig pakke har samme navn, gir en advarsel. Det blokkerer aldri.

Containerimager

Et containerimage evalueres per manifest-digest, mot de samme reglene, med imagets egne inndata:

• Sårbarheter er CVE-funnene fra skanning av containerimager for den digesten (eller taggen), med alvorlighetsgrad og CVSS-score. Imagefunn har ingen EPSS-score, så en policy med vuln_min_epss satt teller dem ikke. Et avvist funn teller ikke.
• Skadevare er et åpent funn av typen ondsinnet pakke på den digesten.
• Lisenser er de imageskanningen rapporterer for pakkene i imaget. En pakke uten lisens regnes som ukjent.
• Tillatelses- og blokkeringslister matcher imaget som typen container (navn og tag) og pakkene i det som komponenter.
• Minstealder regnes fra da taggen ble pushet, hvis container står i age_types (eller age_types er tom).

Imaget sjekkes når det pulles (docker pull, eller en hvilken som helst klient som leser /v2/…/manifests/…), for hvert manifest pullen leverer, inkludert hver plattform i et image for flere plattformer. Imager er bare i shadow-modus: en pull som bryter policyen, registreres under Would have blocked og avvises aldri, uansett hvilken modus du velger. Imagefunn evalueres på nytt minst hver 12. time, og med én gang når du endrer policyen, en liste eller et unntak.

Dette er atskilt fra de eksisterende blokkeringene av image-pulls, som er uendret: innstillingen block_pull i skanning av containerimager og blokkeringen av ondsinnede pakker avviser pulls i dag.

Signaturer

signature_requirement sjekker signaturene til npm-pakker som organisasjonen din henter fra npmjs.org gjennom fremforges avhengighetsproxy, når avhengighetsproxyen er tilgjengelig for organisasjonen din, før tarballen leveres:

• registersignaturen npmjs.org lager over hver versjon (name@version:integrity), verifisert mot npms publiserte registernøkler;
• byggeproveniensen, når versjonen har en: en Sigstore-signert SLSA-attestering, verifisert offline mot den offentlige Sigstores tillitsrot og bundet til tarballens SHA-512.

signature_identities lister byggeidentitetene du stoler på, hver en OIDC-issuer og en subject_regex som hele sertifikatsubjektet må matche. Er noen oppført, teller bare proveniens fra én av dem; en registersignatur alene teller ikke, fordi den beviser hva npmjs.org leverte, ikke hvem som bygde det. For pakker bygd av GitHub Actions i én organisasjon:

"signature_requirement": "require",
"signature_identities": [
  { "issuer": "https://token.actions.githubusercontent.com",
    "subject_regex": "https://github\\.com/sigstore/.+" }
]

Som alle regler følger den policyens modus. En versjon som feiler, registreres med regelen signature og en årsak som no provenance from a trusted identity eller the registry signature does not verify. Et godkjent unntak med regelen signature fritar den.

Hva som ikke sjekkes: pakker publisert til frem.sh (registeret lagrer ingen npm-signatur eller proveniens for dem, så regelen gjelder ikke for dem i det hele tatt), og alle andre pakketyper. Maven-signaturer (.asc) og NuGet-signaturer verifiseres ikke.

Svekket proveniens

provenance_downgrade fanger en versjon der byggeproveniensen er svakere enn for versjonen før. Det er det typiske sporet etter en utgivelse publisert fra en bærbar maskin, eller med et stjålet token, etter at de tidligere utgivelsene kom fra CI. Den bruker de samme verifiserte fakta som signaturer, så den gjelder npm-pakker hentet fra npmjs.org gjennom avhengighetsproxyen.

Versjonen før er den høyeste lavere versjonen som ble publisert tidligere. En tilbakeportering på en eldre linje, for eksempel en sikkerhetsrettelse i 4.5.x utgitt etter 5.4.x, sammenlignes derfor med den forrige utgivelsen på den linjen, ikke med den nyeste. Eldre linjer bygges ofte fortsatt uten proveniens.

En versjon er en svekkelse når versjonen før hadde byggeproveniens, og denne versjonen:

• har ingen proveniens i det hele tatt;
• har proveniens som ikke verifiseres; eller
• ble bygd av en annen signerer: en annen OIDC-utsteder, kilde-repository eller bygge-workflow, eller en selvhostet runner der den forrige versjonen kjørte på en hostet. Disse leses fra det verifiserte Sigstore-sertifikatet. En ny tag av den samme workflowen er den samme signereren.

Den første versjonen av en pakke, og en versjon der forgjengeren ikke hadde proveniens, godkjennes alltid. Denne regelen sammenligner versjoner. For å kreve proveniens på hver versjon bruker du signature_requirement.

"provenance_downgrade": "block"

I konsollen ligger den under Policyer › Pakkepolicyer › Signaturer. Med Terraform er det argumentet provenance_downgrade i fremforge_package_signature_policy. Den kan også settes for én pakketype i type_overrides.

En versjon som feiler, registreres med regelen provenance_downgrade og en årsak som navngir den forrige versjonen, for eksempel 2.4.1 has no build provenance, but the previous version 2.4.0 had eller ... built by a different signer than the previous version 2.4.0: source repository https://github.com/acme/lib -> https://github.com/fork/lib. Et godkjent unntak med regelen signature og selektoren provenance_downgrade fritar bare denne regelen. Et unntak med regelen signature og ingen selektor fritar begge signaturreglene.

Hvor den ikke gjelder ennå:

Proxyens sjekk av låsefiler og filtreringen av pakkemetadata bruker den heller ikke; den vurderes når en tarball lastes ned.

Innstillinger per type

type_overrides setter hvilke som helst av reglene over annerledes for én pakketype, for eksempel en strengere lisensliste for npm. "enabled": false slår policyen av for den typen, bortsett fra sjekken for skadevare.

Moduser

pending_action avgjør hva som skjer med en fil der evalueringen ikke er ferdig ennå, for eksempel en fil publisert for noen sekunder siden. allow (standard) slipper den gjennom. refuse svarer 503 med Retry-After, bare i enforce-modus.

Unntak

Et unntak slipper en pakke forbi én regel i en begrenset tid. Det krever en annen person: den som ber om unntaket, kan ikke godkjenne sin egen forespørsel, og godkjenneren må være eier av organisasjonen eller stå på organisasjonens liste over godkjennere.

Et unntak har:

• et omfang: én fil, et versjonsintervall for en pakke, alle versjoner av en pakke eller én innpakket komponent (etter purl);
• en regel: vuln, licence, age, deny_list, name_clash eller malware, eventuelt avgrenset til én ID for et sårbarhetsvarsel eller én SPDX-lisens;
• en begrunnelse;
• en utløpsdato høyst 366 dager frem i tid. Den er påkrevd.

Et unntak blir bedt om og deretter godkjent eller avvist. Et godkjent unntak kan tilbakekalles når som helst, og det tilbakekalles automatisk når det utløper. Hvert trinn skrives til revisjonsloggen (package_policy.exception.*).

Unntak for pakkepolicyer deler kø, API og innstillinger med unntak for funn: se Unntak, som også dekker godkjennerteamet, taket for utløpstid og automatisk tilbakekalling.

Visningen «Would have blocked»

Åpne organisasjonsadministrasjonen under Sikkerhet › Policyer › Pakkepolicyer. Siden har fire visninger:

• Policy setter modusen og reglene, og viser gjeldende vurderinger av de publiserte filene dine. For å se hva nye innstillinger ville blokkert før du lagrer dem, bruker du prøvekjøringen i API-et (nedenfor).
• Tillatelses- og blokkeringslister inneholder listereglene.
• Unntak viser forespørsler, godkjenningskøen og historikken. Dine egne forespørsler viser ingen Approve-knapp.
• Ville ha blokkert lister nedlastingene policyen avviste, eller ville ha avvist i shadow-modus, de siste 14 dagene: én rad per fil, regel, bruker og dag, med antall nedlastinger. Dette er bevisene du bør gå gjennom før du bytter en organisasjon til enforce.

Nedlastinger som avvises eller registreres på denne måten, står også i tilgangsloggen for registeret med avgjørelsen would_block eller blocked.

Hva som endret seg da håndhevingen startet

2026-10-11:

• Enforce-modus avviser. Før registrerte Enforce de samme resultatene som Shadow. Hvis policyen din allerede var satt til Enforce, avvises nå nedlastinger som bryter den. Sjekk Would have blocked først, eller bytt til Shadow til du har gjort det.
• Kjent skadevare avvises for alle. Før ble den bare registrert.
• Resultatene dine vises. Vurderinger av filer, Would have blocked, pakkefunn og API-ene for evaluering, prøvekjøring, avgjørelser og funn svarer nå for organisasjonen din. Fra da av gir pakkefunn og policyavgjørelser også hendelser i revisjonsloggen (og dermed SIEM- og webhook-hendelser), e-poster med sikkerhetsvarsler, linjer i den ukentlige oppsummeringen og rader i fanen Malware, for endringer fra den dagen. Would have blocked lister også nedlastingene som ble registrert de 14 dagene før.
• Containerimager er uendret: fortsatt bare shadow, se Containerimager.

API

Bruk et token med policy:read eller policy:write (findings:read for pakkefunn). Basis-URL: https://frem.sh/_app/api/v1. Se API-referansen for de fullstendige formene på forespørsler og svar.

En policy i shadow-modus som blokkerer høye og kritiske sårbarhetsvarsler og AGPL, og holder tilbake nye npm-utgivelser i 24 timer:

TOKEN=ffp_...
ORG=acme
V=$(curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://frem.sh/_app/api/v1/orgs/$ORG/package-policy" | jq .version)

curl -sS -X PUT -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  "https://frem.sh/_app/api/v1/orgs/$ORG/package-policy" \
  -d "{\"version\": $V, \"mode\": \"shadow\", \"vuln_min_severity\": \"high\",
       \"licence_deny\": [\"AGPL-3.0-only\", \"AGPL-3.0-or-later\"],
       \"min_age_hours\": 24, \"age_types\": [\"npm\"]}"

Blokker log4j-core under 2.17.1 uansett hvor den er pakket inn:

curl -sS -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  "https://frem.sh/_app/api/v1/orgs/$ORG/package-policy/rules" \
  -d '{"list": "deny", "pkg_type": "maven", "name_glob": "org.apache.logging.log4j:log4j-core",
       "version_range": "vers:maven/<2.17.1", "match_target": "component",
       "reason": "Log4Shell"}'

Revisjon

Hver endring står i revisjonsloggen: package_policy.updated (med hva som ble endret), package_policy.rule.created og .deleted, package_policy.approvers.updated, unntakshendelsene og package_policy.verdict_changed når en fil går fra allow mot warn eller block. En avvist nedlasting, eller en som ville blitt avvist, registreres som package_policy.download_blocked eller package_policy.download_would_block, én gang per fil, regel, bruker og dag.

Relatert

• Ondsinnede pakker
• Skanning av containerimager, som har sin egen pull-blokkering for containerimager
• SBOM-er
• Tilgangslogg for registeret