Verifiser hva som inngår i utgivelsen

Spør om avhengigheten er nødvendig

En agent kan foreslå en pakke som ser ut til å løse et problem. Det er et forslag, ikke dokumentasjon på at pakken finnes eller er egnet. Verifiser nøyaktig registry, utgiver, pakkenavn og versjon før installasjon.

For en fiktiv CSV-eksport kan kjøremiljøet allerede gi påkrevd atferd. En ny pakke kan fortsatt være riktig, men legger til vedlikehold og utførelsesveier. Sammenlign implementeringsinnsatsen med avhengighetens løpende ansvar.

Gjennomgå lisens og støttet kjøremiljø. Undersøk vedlikeholdsaktivitet og relevante sikkerhetsmeldinger. Et kjent navn kan vise til en annen pakke i et annet registry. En vellykket installasjon viser bare at installasjonen ble fullført.

Undersøk installasjons- og byggeatferd

Avhengigheter kan kjøre kode under installasjon eller build. Begrens påloggingsopplysninger og nettverkstilgang i disse miljøene. Ikke eksponer produksjonshemmeligheter for en jobb som behandler en ikke-betrodd pull request.

Bruk en committet låsefil der økosystemet støtter det. Krev at buildet følger filen. Gjennomgå låsefilendringer sammen med kildekodeendringen, inkludert uventede transitive pakker. Låsing av versjoner forbedrer reproduserbarhet, men gjør ikke en sårbar versjon trygg.

NISTs SSDF omfatter beskyttelse av programvare og utviklingspraksis gjennom livssyklusen. Bruk det bredere perspektivet når byggemiljøet utformes. Les rammeverket.

Skill komponentoversikt fra opprinnelsesdokumentasjon

En software bill of materials, eller SBOM, registrerer programvarekomponenter. Den hjelper deg med å identifisere berørte utgivelser når en komponent gir grunn til bekymring. Den dokumenterer ikke uavhengig at komponentene er trygge.

Provenance beskriver hvordan et artefakt ble produsert. SLSA definerer et provenanceformat for informasjon om buildet og dets inndata. Verifisering må knytte informasjonen til en betrodd produsent og artefaktet du vil bruke. En fil kalt «provenance» er ikke nok. SLSA provenance.

Registrer en kjede som kan undersøkes, for eksporttjenesten:

1. Det gjennomgåtte committet identifiserer akseptert kildekode.
2. Buildet identifiserer inndata og utførelsesmiljø.
3. Artefaktet har en stabil digest.
4. Kontrollene identifiserer artefaktet eller kildekoden de undersøkte.
5. Utrullingen registrerer artefaktet som ble plassert i målmiljøet.

Unngå å bygge på en annen måte etter godkjenning uten en definert verifiseringsprosess. En endringsbar tag som latest kan vise til et annet image senere.

Avgjør hva et funn betyr

Et sårbarhetsfunn trenger kontekst: berørt versjon, tilgjengelig atferd, eksponering, tilgjengelig rettelse og konsekvens. Registrer dokumentasjonen bak hvert midlertidige unntak. Gi det en ansvarlig, et utløp og en utløser for gjennomgang.

Ikke undertrykk en hel skanner fordi ett funn ikke er relevant. Ikke rapporter et rent resultat når skanningen ikke ble fullført. Et tidsavbrudd, en pakke som ikke støttes, eller en utilgjengelig kilde til sikkerhetsmeldinger betyr manglende dokumentasjon.

Planlegg til slutt oppdateringer etter utgivelse. Nye sikkerhetsmeldinger kan berøre gårsdagens aksepterte artefakt. Tjenesteeieren trenger en oversikt, en responsprosess og kapasitet til å produsere en rettet utgivelse.

Fortsett med kontinuerlig sårbarhetshåndtering for å knytte gjentatte skanninger til verifiserte rettelser i produksjon.