Kontrollér, hvad der indgår i releasen

Spørg, om afhængigheden er nødvendig

En agent kan foreslå en pakke, som ser ud til at løse et problem. Forslaget er ikke dokumentation for, at pakken findes eller er egnet. Kontrollér det præcise register, udgiveren, pakkenavnet og versionen før installation.

For en fiktiv CSV-eksport tilbyder runtime-miljøet måske allerede den nødvendige adfærd. En ny pakke kan stadig være passende, men tilføjer vedligeholdelse og nye kørselsforløb. Sammenlign implementeringsindsatsen med det løbende ansvar for afhængigheden.

Gennemgå licens og understøttet runtime. Undersøg vedligeholdelsesaktivitet og relevante sikkerhedsadvarsler. Et velkendt navn kan henvise til en anden pakke i et andet register. En vellykket installation viser kun, at installationen blev gennemført.

Undersøg adfærd under installation og build

Afhængigheder kan udføre kode under installation eller build. Begræns adgangsoplysninger og netværksadgang i disse miljøer. Eksponér ikke produktionshemmeligheder for et job, der behandler en upålidelig pull request.

Brug en committet lockfil, hvor økosystemet understøtter det. Kræv, at buildprocessen respekterer filen. Gennemgå ændringer i lockfilen sammen med kildekodeændringen, inklusive uventede transitive pakker. Fastlåste versioner forbedrer reproducerbarhed, men gør ikke en sårbar version sikker.

NIST’s SSDF dækker beskyttelse af software og udviklingspraksis gennem hele livscyklussen. Brug dette bredere perspektiv, når du designer buildmiljøet. Læs rammeværket.

Skeln mellem komponentoversigt og proveniens

En software bill of materials, eller SBOM, registrerer komponenterne i software. Den hjælper med at finde berørte releases, når en komponent giver anledning til bekymring. Den dokumenterer ikke i sig selv, at komponenterne er sikre.

Proveniens handler om, hvordan et artefakt blev produceret. SLSA definerer et format for oplysninger om buildprocessen og dens input. Verifikationen skal forbinde oplysningerne med en betroet producent og det artefakt, du vil bruge. En fil med navnet »provenance« er ikke nok. SLSA-proveniens.

Registrér en kæde for eksporttjenesten, som du kan undersøge:

1. Det gennemgåede commit identificerer den accepterede kildekode.
2. Buildet identificerer sine input og sit kørselsmiljø.
3. Artefaktet har en stabil digest.
4. Kontrollerne identificerer det artefakt eller den kildekode, de undersøgte.
5. Udrulningen registrerer det artefakt, der placeres i målmiljøet.

Undgå et anderledes rebuild efter godkendelse uden en defineret kontrolproces. Et foranderligt tag som latest kan senere henvise til et andet image.

Afgør, hvad et fund betyder

Et sårbarhedsfund kræver kontekst: berørt version, tilgængelig adfærd, eksponering, mulig rettelse og konsekvens. Registrér dokumentationen bag en midlertidig undtagelse. Giv den en ansvarlig, et udløb og en betingelse for nyt review.

Deaktivér ikke en hel scanner, fordi ét fund ikke er relevant. Påstå ikke, at resultatet er rent, hvis scanningen ikke blev gennemført. Timeout, en ikke-understøttet pakke eller et utilgængeligt feed med sikkerhedsadvarsler betyder manglende dokumentation.

Planlæg også opdateringer efter release. Nye sikkerhedsadvarsler kan påvirke gårsdagens accepterede artefakt. Tjenesteejeren har brug for en oversigt, en reaktionsproces og kapacitet til at producere en rettet release.

Fortsæt med løbende håndtering af sårbarheder for at forbinde gentagne scanninger med verificerede rettelser i produktion.