Verifiera vad som ingår i releasen

Fråga om beroendet behövs

En agent kan föreslå ett paket som verkar lösa ett problem. Förslaget är inte underlag för att paketet finns eller är lämpligt. Verifiera exakt register, utgivare, paketnamn och version före installation.

För en fiktiv CSV-export kan körmiljön redan erbjuda det nödvändiga beteendet. Ett nytt paket kan ändå vara lämpligt, men tillför underhåll och exekveringsvägar. Jämför implementationsinsatsen med beroendets löpande ansvar.

Granska licens och stödd körmiljö. Undersök underhållsaktivitet och relevanta säkerhetsmeddelanden. Ett bekant namn kan avse ett annat paket i ett annat register. En lyckad installation visar bara att installationen slutfördes.

Granska installations- och byggbeteende

Beroenden kan köra kod under installation eller byggning. Begränsa autentiseringsuppgifter och nätverksåtkomst i miljöerna. Exponera inte produktionshemligheter för ett jobb som behandlar en obetrodd pull request.

Använd en incheckad låsfil där ekosystemet stöder det. Kräv att bygget följer filen. Granska låsfilsändringar tillsammans med källkodsändringen, inklusive oväntade transitiva paket. Versionslåsning förbättrar reproducerbarheten men gör inte en sårbar version säker.

NIST:s SSDF omfattar skydd av programvara och utvecklingsmetoder genom livscykeln. Använd det bredare perspektivet när byggmiljön utformas. Läs ramverket.

Skilj inventering från proveniens

En komponentförteckning, eller SBOM, registrerar komponenter i programvara. Den hjälper dig identifiera berörda releaser när en komponent blir ett problem. Den fastställer inte oberoende att komponenterna är säkra.

Proveniens beskriver hur en artefakt framställdes. SLSA definierar ett proveniensformat för information om bygget och dess indata. Verifieringen måste koppla informationen till en betrodd producent och den artefakt du tänker använda. En fil som heter ”provenance” räcker inte. SLSA-proveniens.

Dokumentera en granskningsbar kedja för exporttjänsten:

1. Den granskade commiten identifierar accepterad källkod.
2. Bygget identifierar indata och exekveringsmiljö.
3. Artefakten har en stabil kontrollsumma.
4. Kontrollerna identifierar artefakten eller källkoden som undersöktes.
5. Driftsättningen registrerar artefakten som placerades i målmiljön.

Undvik att bygga om på ett annat sätt efter godkännande utan en definierad verifieringsprocess. En föränderlig tagg som latest kan senare avse en annan avbildning.

Avgör vad ett fynd betyder

Ett sårbarhetsfynd behöver kontext: berörd version, nåbart beteende, exponering, tillgänglig rättning och konsekvens. Dokumentera underlaget för varje tillfälligt undantag. Ange ansvarig, giltighetstid och villkor för omprövning.

Stäng inte av en hel skanner för att ett fynd saknar relevans. Påstå inte att resultatet är rent när skanningen inte slutfördes. En tidsgräns, ett paket utan stöd eller ett otillgängligt sårbarhetsflöde innebär saknat underlag.

Planera till sist uppdateringar efter release. Nya säkerhetsmeddelanden kan påverka gårdagens accepterade artefakt. Tjänsteansvarig behöver inventering, åtgärdsprocess och kapacitet att skapa en rättad release.

Fortsätt med kontinuerlig sårbarhetshantering för att koppla upprepade skanningar till verifierade produktionsrättningar.