Pakkepolitikker

En pakkepolitik afgør, fil for fil, om en pakke i din organisations registry må downloades. Den dækker de registry-typer, fremforge hoster: npm, Maven, PyPI, NuGet, Cargo, Go, Conda, CRAN, Debian, RPM, Helm og generiske pakker samt container-images (se Container-images). Hver organisation har én politik med valgfrie indstillinger pr. pakketype.

Hvad en politik tjekker

Når en fil udgives, pakker fremforge den ud, oplister de komponenter, der er pakket i den, og læser pakkens egen erklærede licens (se SBOM’er). Hver komponent sammenholdes med OSV-advisories og sammenholdes igen hver dag. Politikken evalueres mod de resultater, og afgørelsen gemmes for filen: allow, warn eller block. En ændring af politikken, en liste eller en undtagelse evaluerer alle filer igen med det samme, uden ny scanning.

Ved download er det den gemte afgørelse, der bestemmer. Det sker for downloads gennem registry-API’et (/api/packages/…, som alle pakkehåndteringer bruger) og fra webgrænsefladen. Pakkemetadata, såsom et npm-packument eller et PyPI simple index, filtreres aldrig. Når håndhævelsen er slået til, får en resolver, der beder om en blokeret version, 403 for den fil; den ledes ikke over til en anden version.

Sårbarheder

Sårbarhedsreglen er kun slået til, når en tærskel for alvorlighed eller CVSS er sat. Er begge sat, tæller en advisory, der når en af dem.

Licenser

Licenser er SPDX-identifikatorer og tjekkes mod både den erklærede licens og de licenser, der er fundet i de indpakkede komponenter.

Licenslisterne sættes på siden licenspolitik, ét sæt regler for pull requests og downloads. Siden Pakkepolitikker linker dertil. Felterne nedenfor er download-delen af den politik, og PUT /orgs/{org}/package-policy accepterer dem stadig.

Udtryk evalueres pr. operand. OR består, når en hvilken som helst operand er tilladt, AND kræver hver operand, og X WITH exception evalueres som X.

Tillads- og afvisningslister

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

• match_target: package matcher den pakke, du udgav.
• match_target: component matcher en komponent, der er pakket i den.

En deny-regel blokerer. En allow-regel på en pakke lader den passere reglerne for sårbarheder, licenser og alder, og en allow-regel på en komponent fritager komponenten fra reglerne for sårbarheder og licenser. Allow-regler tilsidesætter aldrig kendt malware eller en deny-regel. En regel kan have en udløbsdato.

Minimumsalder

min_age_hours holder filer tilbage, der er yngre end så mange timer efter udgivelsen, eventuelt kun for typerne i age_types. Alderen afgøres i det øjeblik, filen downloades, så en fil kan downloades, så snart den er gammel nok. Når du gemmer organisationens udgivelsesalder, sættes den til det antal dage (0 slår den fra); en type med sin egen minimumsalder i type_overrides beholder den.

En version, der retter en kendt udnyttet sårbarhed (en CVE opført i ENISA’s EU Vulnerability Database eller CISA’s KEV-katalog), holdes ikke tilbage: en rettelse af en sårbarhed, der udnyttes i praksis, bør ikke vente. Aldersreglen vises stadig i afgørelsen, markeret som frafaldet med den CVE, den blev frafaldet for, så frafaldet er synligt i afgørelsen, revisionsloggen og SIEM. En rettelse af en CVE, der ikke vides at blive udnyttet, venter som normalt.

Altid slået til

To tjek kører, uanset hvad politikken siger, også når tilstanden er sat til Fra:

• Kendt malware. En fil, der indeholder en pakke opført i en OSV MAL-*-advisory, afvises med 403 i alle tilstande, også Skygge og Fra. For at lade én fil passere kræves en godkendt undtagelse for reglen malware. Se ondsindede pakker.
• Navnesammenfald. En advisory, der nævner din pakkes eget navn og version, som regel fordi en offentlig pakke har det samme navn, giver en advarsel. Den blokerer aldrig.

Container-images

Et container-image evalueres pr. manifest-digest mod de samme regler, med imagets egne input:

• Sårbarheder er CVE-fundene fra scanning af container-images for den digest (eller dens tag) med deres alvorlighed og CVSS-score. Fund i images har ingen EPSS-score, så en politik med vuln_min_epss sat tæller dem ikke. Et afvist fund tæller ikke.
• Malware er et åbent fund af en ondsindet pakke på den digest.
• Licenser er dem, image-scanningen rapporterer for pakkerne i imaget. En pakke uden licens tæller som ukendt.
• Tillads- og afvisningslister matcher imaget som typen container (dets navn og tag) og pakkerne i det som komponenter.
• Minimumsalder regnes fra det tidspunkt, tagget blev pushet, hvis container er i age_types (eller age_types er tom).

Imaget tjekkes, når det hentes (docker pull eller enhver klient, der læser /v2/…/manifests/…), for hvert manifest, hentningen leverer, herunder hver platform i et image til flere platforme. Images er kun i skyggetilstand: en hentning, der bryder politikken, registreres under Ville have blokeret og afvises aldrig, uanset hvilken tilstand du vælger. Fund i images evalueres igen mindst hver 12. time og med det samme, når du ændrer politikken, en liste eller en undtagelse.

Det er adskilt fra de eksisterende blokeringer af image-hentninger, som er uændrede: indstillingen block_pull under scanning af container-images og blokeringen af ondsindede pakker afviser hentninger i dag.

Signaturer

signature_requirement tjekker signaturerne på npm-pakker, som din organisation henter fra npmjs.org gennem fremforges afhængighedsproxy, når afhængighedsproxyen er tilgængelig for din organisation, før tarballen leveres:

• den registry-signatur, npmjs.org laver over hver version (name@version:integrity), verificeret mod npm’s offentliggjorte registry-nøgler;
• build-provenance, når versionen har en: en Sigstore-signeret SLSA-attestation, verificeret offline mod den offentlige Sigstore-trust root og bundet til tarballens SHA-512.

signature_identities angiver de build-identiteter, du har tillid til, hver med en OIDC-issuer og en subject_regex, som hele certifikatets subject skal matche. Er der angivet nogen, tæller kun provenance fra en af dem; en registry-signatur alene gør ikke, fordi den beviser, hvad npmjs.org leverede, ikke hvem der byggede det. For pakker bygget af GitHub Actions i én organisation:

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

Som alle regler følger den politikkens tilstand. En version, der fejler, registreres med reglen signature og en årsag som no provenance from a trusted identity eller the registry signature does not verify. En godkendt undtagelse med reglen signature fritager den.

Hvad der ikke tjekkes: pakker udgivet til frem.sh (registret gemmer ingen npm-signatur eller provenance for dem, så reglen gælder slet ikke for dem) og alle andre pakketyper. Mavens .asc-signaturer og NuGet-signaturer verificeres ikke.

Nedgradering af provenance

provenance_downgrade fanger en version, hvis build-provenance er svagere end versionen før den. Det er det typiske spor af en udgivelse, der er publiceret fra en bærbar computer eller med et stjålet token, efter at de tidligere udgivelser kom fra CI. Den bruger de samme verificerede fakta som signaturer, så den gælder for npm-pakker hentet fra npmjs.org gennem afhængighedsproxyen.

Versionen før er den højeste lavere version, der blev udgivet tidligere. En backport på en ældre linje, for eksempel en sikkerhedsrettelse i 4.5.x udgivet efter 5.4.x, sammenlignes altså med den linjes forrige udgivelse, ikke med den nyeste. Ældre linjer bygges ofte stadig uden provenance.

En version er en nedgradering, når versionen før den havde build-provenance, og denne version:

• slet ikke har nogen provenance;
• har provenance, der ikke kan verificeres; eller
• er bygget af en anden signerende part: en anden OIDC-issuer, et andet kilderepository eller et andet build-workflow, eller en selvhostet runner, hvor den forrige version kørte på en hostet. Disse læses fra det verificerede Sigstore-certifikat. Et nyt tag fra det samme workflow er den samme signerende part.

Den første version af en pakke og en version, hvis forgænger ikke havde provenance, består altid. Denne regel sammenligner versioner. For at kræve provenance på hver version skal du bruge signature_requirement.

"provenance_downgrade": "block"

I konsollen ligger den under Politikker › Pakkepolitikker › Signaturer. Med Terraform er det argumentet provenance_downgrade i fremforge_package_signature_policy. Den kan også sættes for én pakketype i type_overrides.

En version, der fejler, registreres med reglen provenance_downgrade og en årsag, der nævner den forrige version, 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. En godkendt undtagelse med reglen signature og selektoren provenance_downgrade fritager kun for denne regel. En undtagelse med reglen signature og ingen selektor fritager for begge signaturregler.

Hvor den endnu ikke gælder:

Proxyens lockfil-tjek og dens filtrering af pakkemetadata anvender den heller ikke; den bedømmes, når en tarball downloades.

Indstillinger pr. type

type_overrides sætter en hvilken som helst af reglerne ovenfor anderledes for én pakketype, for eksempel en strengere licensliste for npm. "enabled": false slår politikken fra for den type, bortset fra malware-tjekket.

Tilstande

pending_action afgør, hvad der sker med en fil, hvis evaluering endnu ikke er færdig, for eksempel en fil udgivet for få sekunder siden. allow (standard) lader den passere. refuse svarer 503 med Retry-After, kun i håndhævelsestilstand.

Undtagelser

En undtagelse lader en pakke passere én regel i begrænset tid. Den kræver en anden person: den, der anmoder, kan ikke godkende sin egen anmodning, og den, der godkender, skal være ejer af organisationen eller stå på organisationens liste over godkendere.

En undtagelse har:

• et omfang: én fil, et versionsinterval af en pakke, alle versioner af en pakke eller én indpakket komponent (via purl);
• en regel: vuln, licence, age, deny_list, name_clash eller malware, eventuelt indsnævret til ét advisory-id eller én SPDX-licens;
• en begrundelse;
• en udløbsdato højst 366 dage ude i fremtiden. Den er påkrævet.

En undtagelse anmodes om og bliver derefter godkendt eller afvist. En godkendt undtagelse kan til enhver tid tilbagekaldes, og den tilbagekaldes automatisk, når den udløber. Hvert trin skrives til revisionsloggen (package_policy.exception.*).

Undtagelser i pakkepolitikken deler kø, API og indstillinger med undtagelser for fund: se Undtagelser, som også dækker teamet af godkendere, den maksimale udløbstid og automatisk tilbagekaldelse.

Visningen “Ville have blokeret”

Åbn din organisations administrationssider under Sikkerhed › Politikker › Pakkepolitikker. Siden har fire visninger:

• Politik sætter tilstanden og reglerne og viser de aktuelle afgørelser for dine udgivne filer. For at se, hvad nye indstillinger ville blokere, før du gemmer dem, skal du bruge prøvekørslen i API’et (nedenfor).
• Tillads- og afvisningslister indeholder listereglerne.
• Undtagelser viser anmodninger, godkendelseskøen og historikken. Dine egne anmodninger viser ingen knap til Godkend.
• Ville have blokeret viser de downloads, politikken afviste eller ville have afvist i skyggetilstand, over de seneste 14 dage: én række pr. fil, regel, bruger og dag, med antallet af downloads. Det er det bevismateriale, du skal gennemgå, før du sætter en organisation til håndhævelse.

Downloads, der er afvist eller registreret på denne måde, står også i registrets adgangslog med afgørelsen would_block eller blocked.

Hvad der ændrede sig, da håndhævelsen startede

Den 2026-10-11:

• Håndhæv afviser. Før registrerede Håndhæv de samme resultater som Skygge. Var din politik allerede sat til Håndhæv, afvises downloads, der bryder den, nu. Tjek Ville have blokeret først, eller skift til Skygge, indtil du har gjort det.
• Kendt malware afvises for alle. Før blev den kun registreret.
• Dine resultater vises. Afgørelser for filer, Ville have blokeret, pakkefund og API’erne for evaluering, prøvekørsel, afgørelser og fund svarer nu for din organisation. Fra da af giver pakkefund og politikafgørelser også hændelser i revisionsloggen (og dermed SIEM- og webhook-hændelser), sikkerhedsadvarsler pr. e-mail, linjer i den ugentlige oversigt og rækker under fanen Malware, for ændringer fra den dag. Ville have blokeret viser også de downloads, der blev registreret i de 14 dage før.
• Container-images er uændrede: stadig kun skyggetilstand, se Container-images.

API

Brug et token med policy:read eller policy:write (findings:read for pakkefund). Basis-URL: https://frem.sh/_app/api/v1. Se API-referencen for de fulde former på forespørgsler og svar.

En politik i skyggetilstand, der blokerer høje og kritiske advisories og AGPL og holder nye npm-udgivelser tilbage 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\"]}"

Afvis log4j-core under 2.17.1, uanset hvor den er pakket ind:

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"}'

Revision

Hver ændring står i revisionsloggen: package_policy.updated (med hvad der ændrede sig), package_policy.rule.created og .deleted, package_policy.approvers.updated, undtagelseshændelserne og package_policy.verdict_changed, når en fil bevæger sig fra allow mod warn eller block. En afvist eller en download, der ville være blevet afvist, registreres som package_policy.download_blocked eller package_policy.download_would_block, én gang pr. fil, regel, bruger og dag.

Relateret

• Ondsindede pakker
• Scanning af container-images, som har sin egen blokering af hentninger for container-images
• SBOM’er
• Registrets adgangslog