Paketpolicyer

En paketpolicy avgör, fil för fil, om ett paket i din organisations register får laddas ned. Den täcker de registertyper som fremforge hostar: npm, Maven, PyPI, NuGet, Cargo, Go, Conda, CRAN, Debian, RPM, Helm och generiska paket, samt container-images (se Container-images). Varje organisation har en policy, med valfria inställningar per pakettyp.

Vad en policy kontrollerar

När en fil publiceras packar fremforge upp den, listar de komponenter som ingår i den och läser paketets egen deklarerade licens (se SBOM:er). Varje komponent matchas mot säkerhetsmeddelandena i OSV, och matchas igen varje dag. Policyn utvärderas mot de resultaten och utlåtandet sparas för filen: allow, warn eller block. En ändring av policyn, en lista eller ett undantag utvärderar om varje fil direkt, utan ny skanning.

Vid nedladdning är det det sparade utlåtandet som avgör. Det gäller nedladdningar via register-API:t (/api/packages/…, som alla pakethanterare använder) och från webbgränssnittet. Paketmetadata, till exempel ett npm-packument eller ett enkelt PyPI-index, filtreras aldrig. När tillämpningen är på får en resolver som ber om en blockerad version 403 för den filen; den styrs inte till en annan version.

Sårbarheter

Sårbarhetsregeln är på bara när ett tröskelvärde för allvarlighetsgrad eller CVSS är angivet. När båda är angivna räknas ett säkerhetsmeddelande som når något av dem.

Licenser

Licenser är SPDX-identifierare, och kontrolleras mot både den deklarerade licensen och de licenser som hittats i medföljande komponenter.

Licenslistorna anges på sidan licenspolicy, en uppsättning regler för pull requests och nedladdningar. Sidan Paketpolicyer länkar dit. Fälten nedan är nedladdningssidan av den policyn, och PUT /orgs/{org}/package-policy tar fortfarande emot dem.

Uttryck utvärderas per operand. OR godkänns när någon operand är tillåten, AND kräver varje operand, och X WITH exception utvärderas som X.

Tillåt- och nekalistor

En listregel anger en pakettyp (eller vilken typ som helst), ett namnmönster (jokertecknen * och ?, till exempel @acme/* eller org.apache.logging.log4j:log4j-core) och ett valfritt versionsintervall i syntaxen vers:, till exempel vers:maven/<2.17.1. Intervallen följer varje ekosystems egna versionsregler för npm, Cargo och Go (semver), PyPI (PEP 440), Maven och NuGet.

• match_target: package matchar det paket du publicerade.
• match_target: component matchar en komponent som ingår i det.

En regel i nekalistan blockerar. En regel i tillåtlistan för ett paket släpper förbi det trots reglerna för sårbarheter, licenser och ålder, och en tillåtregel för en komponent undantar den komponenten från reglerna för sårbarheter och licenser. Tillåtregler åsidosätter aldrig känd skadlig kod eller en nekaregel. En regel kan ha ett utgångsdatum.

Minimiålder

min_age_hours håller tillbaka filer som är yngre än så här många timmar efter att de publicerades, eventuellt bara för typerna i age_types. Åldern avgörs i samma ögonblick som nedladdningen, så en fil blir nedladdningsbar så snart den är tillräckligt gammal. När du sparar organisationens versionsålder sätts den till så många dagar (0 stänger av den); en typ med en egen minimiålder i type_overrides behåller den.

En version som åtgärdar en känd utnyttjad sårbarhet (en CVE som listas i ENISA:s EU Vulnerability Database eller i CISA:s KEV-katalog) hålls inte tillbaka: en fix för en sårbarhet som utnyttjas i praktiken ska inte behöva vänta. Åldersregeln visas fortfarande i beslutet, markerad som åsidosatt med den CVE den åsidosattes för, så att åsidosättningen syns i utlåtandet, granskningsloggen och SIEM. En fix för en CVE som inte är känd som utnyttjad väntar som vanligt.

Alltid på

Två kontroller körs oavsett vad policyn säger, även när läget är Av:

• Känd skadlig kod. En fil som innehåller ett paket som listas i ett säkerhetsmeddelande MAL-* i OSV avvisas med 403, i alla lägen, även Skugga och Av. För att släppa igenom en fil krävs ett godkänt undantag för regeln malware. Se skadliga paket.
• Namnkonflikt. Ett säkerhetsmeddelande som anger ditt pakets eget namn och version, oftast för att ett publikt paket har samma namn, ger en varning. Det blockerar aldrig.

Container-images

En container-image utvärderas per manifest-digest, mot samma regler, med imagens egna indata:

• Sårbarheter är CVE-fynden från skanning av container-images för den digesten (eller dess tagg), med allvarlighetsgrad och CVSS-poäng. Fynd för images har ingen EPSS-poäng, så en policy med vuln_min_epss angiven räknar dem inte. Ett avfärdat fynd räknas inte.
• Skadlig kod är ett öppet fynd av skadligt paket för den digesten.
• Licenser är de som image-skanningen rapporterar för paketen i imagen. Ett paket utan licens räknas som okänt.
• Tillåt- och nekalistor matchar imagen som typen container (dess namn och tagg) och paketen i den som komponenter.
• Minimiålder räknas från när taggen pushades, om container finns i age_types (eller om age_types är tom).

Imagen kontrolleras när den hämtas (docker pull, eller en klient som läser /v2/…/manifests/…), för varje manifest som pullen levererar, inklusive varje plattform i en image för flera plattformar. Images är bara i skuggläge: en pull som bryter mot policyn registreras under Skulle ha blockerats och avvisas aldrig, oavsett vilket läge du väljer. Fynd för images utvärderas om minst var 12:e timme, och direkt när du ändrar policyn, en lista eller ett undantag.

Det här är skilt från de befintliga blockeringarna av pull för images, som är oförändrade: inställningen block_pull för skanning av container-images och blockeringen av skadliga paket avvisar pullar redan i dag.

Signaturer

signature_requirement kontrollerar signaturerna för npm-paket som din organisation hämtar från npmjs.org via fremforges beroendeproxy, när beroendeproxyn är tillgänglig för din organisation, innan tarballen levereras:

• registersignaturen som npmjs.org gör över varje version (name@version:integrity), verifierad mot npm:s publicerade registernycklar;
• byggproveniensen, när versionen har en: en SLSA-attestering signerad med Sigstore, verifierad offline mot den publika Sigstores förtroenderot och bunden till tarballens SHA-512.

signature_identities listar de byggidentiteter du litar på, var och en en OIDC-issuer och en subject_regex som hela certifikatets subject måste matcha. När någon är angiven räknas bara proveniens från en av dem; en registersignatur ensam räcker inte, eftersom den bevisar vad npmjs.org levererade, inte vem som byggde det. För paket som byggs av GitHub Actions i en organisation:

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

Som alla regler följer den policyns läge. En version som inte klarar kontrollen registreras med regeln signature och en orsak som no provenance from a trusted identity eller the registry signature does not verify. Ett godkänt undantag med regeln signature undantar den.

Vad som inte kontrolleras: paket som publicerats till frem.sh (registret sparar ingen npm-signatur eller proveniens för dem, så regeln gäller inte dem alls) och alla andra pakettyper. .asc-signaturer för Maven och signaturer för NuGet verifieras inte.

Nedgraderad proveniens

provenance_downgrade fångar en version vars byggproveniens är svagare än versionen före den. Det är det typiska spåret av en release som publicerats från en bärbar dator, eller med en stulen token, efter att de tidigare releaserna kom från CI. Den använder samma verifierade fakta som signaturer, så den gäller npm-paket som hämtas från npmjs.org via beroendeproxyn.

Versionen före den är den högsta lägre version som publicerades tidigare. En backport på en äldre linje, till exempel en säkerhetsfix 4.5.x som släpps efter 5.4.x, jämförs alltså med den linjens föregående release, inte med den nyaste. Äldre linjer byggs ofta fortfarande utan proveniens.

En version är en nedgradering när versionen före den hade byggproveniens, och den här versionen:

• saknar proveniens helt;
• har proveniens som inte verifieras; eller
• byggdes av en annan signerare: en annan OIDC-utfärdare, ett annat källrepo eller ett annat byggarbetsflöde, eller en egenhostad runner där den föregående versionen kördes på en hostad. Det läses från det verifierade Sigstore-certifikatet. En ny tagg från samma arbetsflöde är samma signerare.

Den första versionen av ett paket, och en version vars föregångare saknade proveniens, godkänns alltid. Den här regeln jämför versioner. För att kräva proveniens på varje version, använd signature_requirement.

"provenance_downgrade": "block"

I konsolen finns den under Policyer › Paketpolicyer › Signaturer. Med Terraform är det argumentet provenance_downgrade i fremforge_package_signature_policy. Den kan också anges för en enskild pakettyp i type_overrides.

En version som inte klarar kontrollen registreras med regeln provenance_downgrade och en orsak som anger den föregående versionen, till exempel 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. Ett godkänt undantag med regeln signature och selektorn provenance_downgrade undantar bara den här regeln. Ett undantag med regeln signature utan selektor undantar båda signaturreglerna.

Där den inte gäller än:

Proxyns kontroll av låsfiler och dess filtrering av paketmetadata tillämpar den inte heller; den bedöms när en tarball laddas ned.

Inställningar per typ

type_overrides anger någon av reglerna ovan annorlunda för en pakettyp, till exempel en striktare licenslista för npm. "enabled": false stänger av policyn för den typen, förutom kontrollen av skadlig kod.

Lägen

pending_action avgör vad som händer med en fil vars utvärdering inte är klar än, till exempel en fil som publicerades för några sekunder sedan. allow (standard) släpper igenom den. refuse svarar 503 med Retry-After, bara i läget enforce.

Undantag

Ett undantag släpper förbi ett paket trots en regel under en begränsad tid. Det kräver en andra person: den som begär kan inte godkänna sin egen begäran, och godkännaren måste vara ägare av organisationen eller finnas på organisationens lista över godkännare.

Ett undantag har:

• ett omfång: en fil, ett versionsintervall för ett paket, alla versioner av ett paket, eller en medföljande komponent (via purl);
• en regel: vuln, licence, age, deny_list, name_clash eller malware, eventuellt begränsad till ett id för ett säkerhetsmeddelande eller en SPDX-licens;
• en motivering;
• ett utgångsdatum högst 366 dagar bort. Det är obligatoriskt.

Ett undantag begärs och godkänns eller avvisas sedan. Ett godkänt undantag kan återkallas när som helst, och det återkallas automatiskt när det går ut. Varje steg skrivs till granskningsloggen (package_policy.exception.*).

Undantag från paketpolicyn delar kö, API och inställningar med undantag för fynd: se Undantag, som också beskriver teamet för godkännare, taket för utgångsdatum och automatiskt återkallande.

Vyn “Skulle ha blockerats”

Öppna organisationens administrationssidor under Säkerhet › Policyer › Paketpolicyer. Sidan har fyra vyer:

• Policy anger läget och reglerna, och visar de aktuella utlåtandena för dina publicerade filer. För att se vad nya inställningar skulle blockera innan du sparar dem, använd torrkörningen i API:t (nedan).
• Tillåt- och nekalistor innehåller listreglerna.
• Undantag visar begäranden, kön för godkännande och historiken. Dina egna begäranden visar ingen knapp för att godkänna.
• Skulle ha blockerats listar de nedladdningar som policyn avvisade, eller skulle ha avvisat i skuggläge, de senaste 14 dagarna: en rad per fil, regel, användare och dag, med antalet nedladdningar. Det är underlaget att gå igenom innan du byter en organisation till tillämpning.

Nedladdningar som avvisas eller registreras på det här sättet finns också i registrets åtkomstlogg med beslutet would_block eller blocked.

Vad som ändrades när tillämpningen började

Den 2026-10-11:

• Läget Tvinga avvisar. Tidigare registrerade Tvinga samma resultat som Skugga. Om din policy redan var inställd på Tvinga avvisas nu nedladdningar som bryter mot den. Kontrollera Skulle ha blockerats först, eller byt till Skugga tills du har gjort det.
• Känd skadlig kod avvisas för alla. Tidigare registrerades den bara.
• Dina resultat visas. Utlåtanden för filer, Skulle ha blockerats, paketfynd och API:erna för utvärdering, torrkörning, beslut och fynd svarar nu för din organisation. Från och med då ger paketfynd och policybeslut också händelser i granskningsloggen (och därmed händelser i SIEM och webhooks), mejl med säkerhetsaviseringar, rader i veckosammanfattningen och rader på fliken Skadlig kod, för ändringar från den dagen. Skulle ha blockerats listar också de nedladdningar som registrerades de 14 dagarna innan.
• Container-images är oförändrade: fortfarande bara skuggläge, se Container-images.

API

Använd en token med policy:read eller policy:write (findings:read för paketfynd). Bas-URL: https://frem.sh/_app/api/v1. Se API-referensen för de fullständiga strukturerna för förfrågningar och svar.

En policy i skuggläge som blockerar säkerhetsmeddelanden med hög och kritisk allvarlighetsgrad och AGPL, och som håller tillbaka nya npm-releaser i 24 timmar:

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\"]}"

Neka log4j-core under 2.17.1 var den än ingår:

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

Granskning

Varje ändring finns i granskningsloggen: package_policy.updated (med vad som ändrades), package_policy.rule.created och .deleted, package_policy.approvers.updated, händelserna för undantag, och package_policy.verdict_changed när en fil flyttas från allow mot warn eller block. En nedladdning som avvisas eller skulle ha avvisats registreras som package_policy.download_blocked eller package_policy.download_would_block, en gång per fil, regel, användare och dag.

Relaterat

• Skadliga paket
• Skanning av container-images, som har sin egen pull-blockering för container-images
• SBOM:er
• Registrets åtkomstlogg