Læringssti 05Lektion 3 / 8

Bliv ved med at finde og rette sårbarheder

Byg en løbende proces fra opdagelse af sårbarheder til verificeret afhjælpning i produktion. Forstå det vedligeholdelsesgab, en vellykket prototype kan skjule.

Praktisk12 minReviewet

Udgivet af Sådan skriver vi

Det lærer du

  • Forklar, hvorfor uændret software kræver løbende sikkerhedsreview.
  • Forbind forskellige scanningstyper med deres dækning og begrænsninger.
  • Følg et fund gennem prioritering, rettelse, udrulning og verifikation.

En fungerende prototype kan blive en tjeneste uden vedligeholdelse

Vibe coding kan hurtigt skabe en nyttig prototype. Produktionsrisikoen vokser, når folk fortsætter med at bruge den uden løbende sikkerhedsvedligeholdelse. Det er en alvorlig mangel: Softwaren forbliver eksponeret, mens den person, der skabte den, betragter arbejdet som færdigt.

Manglerne er både organisatoriske og tekniske. En scanner kan eksistere uden en ansvarlig. Et fund kan have en ansvarlig uden en vej til release. En merget rettelse kan efterlade det gamle produktionsartefakt i drift.

Vurdér den faktiske udviklingsplatform og dens konfiguration. Nogle værktøjer har sikkerhedsfunktioner. En produktbetegnelse dokumenterer ikke, om din udrullede applikation får løbende scanning og verificerede rettelser.

Scan, når dokumentationsgrundlaget kan ændre sig

Kør relevante kontroller på foreslåede ændringer og byggede artefakter. Vurdér understøttede versioner igen efter en tidsplan, fordi sikkerhedsoplysninger ændrer sig uden et commit. Udløs yderligere review ved en relevant sikkerhedsmeddelelse, ændret eksponering eller hændelse.

Gør omfanget tydeligt. Identificér repositories, branches, lockfiler, images, udrullede digests, runtimes og miljøer. Medtag applikationer, der ikke længere får nye funktioner, men stadig betjener brugere.

En fejlet scanning betyder manglende dokumentation. Overvåg scanningernes aktualitet, fejl i datakilder, autentificeringsfejl, komponenter uden support og huller i dækningen. En tom liste over fund efter et fejlet job er ikke et rent resultat.

Brug forskellige kontroller til forskellige spørgsmål

KontrolNyttig dækningVigtig begrænsning
Software composition analysis, eller SCAKendte sårbarheder i afhængigheder, inklusive identificerede transitive pakkerDokumenterer ikke, at applikationens autorisation er korrekt
Static application security testing, eller SASTUnderstøttede usikre kodemønstreKan overse runtimeadfærd og give fund, der kræver triage
Secret scanningGenkendte mønstre for adgangsoplysninger i scannet indholdEn fjernet tekststreng kan efterlade gyldige adgangsoplysninger andre steder
Infrastruktur- og konfigurationskontrollerDefinerede politikbrud i scannede ressourcer eller konfigurationRepositorykonfigurationen kan afvige fra det kørende miljø
Autoriseret dynamisk testEn kørende applikations adfærd inden for det testede omfangKræver tilladelse, egnede data og hensyn til sideeffekter

Kombinér kontrollerne med review og relevante sikkerhedstests. Påstå ikke, at en scanning beviser fravær af sårbarheder.

Følg et fiktivt fund ind i produktion

TidspunktHændelseFaktisk status
Mandag 09:00En ny sikkerhedsmeddelelse identificerer en berørt PDF-afhængighedEksisterende releases skal vurderes
Mandag 09:15Planlagt scanning identificerer produktionsversionenFund opdaget, men ikke rettet
Mandag 10:00Den ansvarlige bekræfter eksponeringen og vælger en understøttet patchAfhjælpning planlagt
Mandag 13:00Tests består, og patchens PR mergesRepository rettet; produktion kræver stadig udrulning
Mandag 14:00Pipelinen udruller det rettede imageNyt artefakt kører; verifikation mangler
Mandag 14:20Artefaktscanning og regressionskontroller af eksport bestårRettelse verificeret inden for det kontrollerede omfang

Prioritér ud fra alvorlighed, dokumenteret udnyttelse, eksponering, berørte data og tilgængelige afhjælpninger. CISA’s katalog hjælper med at identificere kendt udnyttelse. Det er ét input, ikke en fuldstændig risikovurdering. CISA-kataloget.

En midlertidig undtagelse kræver dokumentation, en ansvarlig, kompenserende kontroller og et udløb eller en udløser for review. Hvis ingen patch findes, kan I overveje en autoriseret workaround, begrænse en funktion eller fjerne den berørte komponent.

Luk vedligeholdelsesgabet

Mål tiden til triage og verificeret afhjælpning efter prioritet. Følg overskredne undtagelser, forældede scanninger, berørte produktionsversioner og tilbagevendende fund. Færre fund kan også skyldes mindre dækning; undersøg nævneren.

Taiga Maintaining scanner tilknyttede repositories efter ændringer og med faste mellemrum. Funktionen registrerer fund og forbinder afhjælpning med initiativer og reviewede ændringer. Kontrollér status for scanningerne og den aktuelt dokumenterede adfærd. Maintaining.

Din pipeline kræver stadig passende releasekontroller. Tjenesteejeren skal stadig bekræfte udrulning og korrekt drift. Denne sammenhængende proces er en del af driften af en AI-softwarefabrik, også for produkter, der begyndte som prototyper.

Lav øvelsen

Brug den fiktive tidslinje i lektionen. Find de steder, hvor teamet fejlagtigt kunne erklære arbejdet færdigt. Definér udløsere for scanning, fejlalarm, ansvarlig for afhjælpning, releaseverifikation og udløb af midlertidige undtagelser.

Download arbejdsark (Markdown)

Kontrollér din forståelse

En applikation har ikke ændret sig i tre måneder. Den seneste scanning af afhængigheder bestod ved release. Hvilket udsagn er der belæg for?

Kilder og videre læsning

Relateret læsning fra Taiga