Læringsløp 05Leksjon 3 / 8

Fortsett å finne og rette sårbarheter

Bygg en kontinuerlig prosess fra oppdagelse av sårbarheter til verifisert utbedring i produksjon. Forstå vedlikeholdsgapet en vellykket prototype kan skjule.

Praktisk12 minGjennomgått

Publisert av Slik skriver vi

Dette lærer du

  • Forklar hvorfor uendret programvare trenger løpende sikkerhetsgjennomgang.
  • Knytt ulike skannetyper til dekningen og begrensningene deres.
  • Følg et funn gjennom prioritering, retting, utrulling og verifikasjon.

En fungerende prototype kan bli en tjeneste uten oppfølging

Vibe coding kan raskt gi en nyttig prototype. Produksjonsrisikoen øker når folk fortsetter å bruke den uten løpende sikkerhetsvedlikehold. Dette er et alvorlig gap: programvaren forblir eksponert mens personen som laget den, regner arbeidet som ferdig.

Gapet er både organisatorisk og teknisk. En skanner kan finnes uten en eier. Et funn kan ha en eier uten en vei til utgivelse. En merget retting kan la det gamle produksjonsartefaktet fortsette å kjøre.

Vurder den faktiske utviklingsplattformen og konfigurasjonen. Noen verktøy har sikkerhetsfunksjoner. En produktbetegnelse fastslår ikke om den utrullede applikasjonen får kontinuerlig skanning og verifiserte rettinger.

Skann når bevisene kan endre seg

Kjør relevante kontroller på foreslåtte endringer og bygde artefakter. Vurder støttede versjoner på nytt etter en plan, fordi informasjon i sikkerhetsvarsler endrer seg uten en commit. Utløs ekstra gjennomgang når et relevant sikkerhetsvarsel, en eksponeringsendring eller en hendelse oppstår.

Gjør omfanget tydelig. Identifiser repositories, brancher, låsefiler, imager, utrullede digests, kjøremiljøer og miljøer. Ta med applikasjoner som ikke lenger får nye funksjoner, men fortsatt betjener brukere.

En mislykket skanning betyr manglende bevis. Overvåk hvor ferske skanningene er, feil i informasjonsstrømmer, autentiseringsfeil, komponenter uten støtte og hull i dekningen. En tom funnliste etter en mislykket jobb er ikke et rent resultat.

Bruk ulike kontroller for ulike spørsmål

KontrollNyttig dekningViktig begrensning
Software composition analysis, eller SCAKjente sårbarheter i avhengigheter, inkludert identifiserte transitive pakkerFastslår ikke at applikasjonens autorisasjon er riktig
Static application security testing, eller SASTUtrygge kodemønstre som verktøyet støtterKan overse oppførsel under kjøring og gi funn som må vurderes
Skanning etter hemmeligheterGjenkjente mønstre for påloggingsopplysninger i skannet innholdEn fjernet streng kan etterlate gyldige påloggingsopplysninger andre steder
Infrastruktur- og konfigurasjonskontrollerDefinerte policybrudd i skannede ressurser eller konfigurasjonKonfigurasjonen i repositoryet kan avvike fra miljøet som kjører
Autorisert dynamisk testingOppførselen til en kjørende applikasjon innenfor testens omfangKrever tillatelse, egnede data og forsiktighet med sideeffekter

Kombiner disse kontrollene med review og relevante sikkerhetstester. Ikke påstå at en skanning beviser fravær av sårbarheter.

Følg et fiktivt funn inn i produksjon

TidHendelseFaktisk status
Mandag 09:00Et nytt sikkerhetsvarsel identifiserer en berørt PDF-avhengighetEksisterende utgivelser må vurderes
Mandag 09:15En planlagt skanning identifiserer produksjonsversjonenFunnet er oppdaget, ikke rettet
Mandag 10:00Eieren bekrefter eksponering og velger en støttet rettingUtbedring er planlagt
Mandag 13:00Testene består, og PR-en med rettingen mergesRepositoryet er rettet; produksjon trenger fortsatt utrulling
Mandag 14:00Pipelinen ruller ut det korrigerte imagetDet nye artefaktet kjører; verifikasjon gjenstår
Mandag 14:20Artefaktskanning og regresjonskontroller av eksport bestårRettingen er verifisert innenfor det kontrollerte omfanget

Prioriter med alvorlighetsgrad, bevis på utnyttelse, eksponering, berørte data og tilgjengelige begrensningstiltak. CISA-katalogen bidrar til å identifisere kjent utnyttelse. Den er ett innspill, ikke en fullstendig risikovurdering. CISA-katalogen.

Et midlertidig unntak trenger bevis, en eier, kompenserende kontroller og en betingelse for utløp eller ny vurdering. Hvis ingen retting finnes, vurder en autorisert omvei, begrensning av funksjonen eller fjerning av den berørte komponenten.

Lukk vedlikeholdsgapet

Mål tiden til vurdering og verifisert utbedring etter prioritet. Følg forfalte unntak, gamle skanninger, berørte produksjonsversjoner og gjentatte funn. Færre funn kan også skyldes redusert dekning. Undersøk nevneren.

Taiga Maintaining skanner tilknyttede repositories etter endringer og med jevne mellomrom. Det registrerer funn og knytter utbedring til initiativer og gjennomgåtte endringer. Kontroller statusen for skannerunden og gjeldende dokumentert oppførsel. Maintaining.

Pipelinen trenger fortsatt passende utgivelseskontroller. Tjenesteeieren må fortsatt bekrefte utrulling og korrekt drift. Denne kontinuerlige kjeden er en del av driften av en AI-programvarefabrikk, også for produkter der første versjon startet som en prototype.

Gjør øvelsen

Bruk den fiktive tidslinjen i denne leksjonen. Finn hvor teamet feilaktig kan erklære suksess. Definer hva som utløser skanning, varsling ved skannefeil, utbedringseier, utgivelsesverifikasjon og utløp av midlertidige unntak.

Last ned arbeidsark (Markdown)

Kontroller forståelsen din

En applikasjon har ikke endret seg på tre måneder. Den siste avhengighetsskanningen besto ved utgivelse. Hvilken påstand støttes?

Kilder og videre lesning

Relatert lesning fra Taiga