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.
Udgivet af TaigaSå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
| Kontrol | Nyttig dækning | Vigtig begrænsning |
|---|---|---|
| Software composition analysis, eller SCA | Kendte sårbarheder i afhængigheder, inklusive identificerede transitive pakker | Dokumenterer ikke, at applikationens autorisation er korrekt |
| Static application security testing, eller SAST | Understøttede usikre kodemønstre | Kan overse runtimeadfærd og give fund, der kræver triage |
| Secret scanning | Genkendte mønstre for adgangsoplysninger i scannet indhold | En fjernet tekststreng kan efterlade gyldige adgangsoplysninger andre steder |
| Infrastruktur- og konfigurationskontroller | Definerede politikbrud i scannede ressourcer eller konfiguration | Repositorykonfigurationen kan afvige fra det kørende miljø |
| Autoriseret dynamisk test | En kørende applikations adfærd inden for det testede omfang | Kræ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
| Tidspunkt | Hændelse | Faktisk status |
|---|---|---|
| Mandag 09:00 | En ny sikkerhedsmeddelelse identificerer en berørt PDF-afhængighed | Eksisterende releases skal vurderes |
| Mandag 09:15 | Planlagt scanning identificerer produktionsversionen | Fund opdaget, men ikke rettet |
| Mandag 10:00 | Den ansvarlige bekræfter eksponeringen og vælger en understøttet patch | Afhjælpning planlagt |
| Mandag 13:00 | Tests består, og patchens PR merges | Repository rettet; produktion kræver stadig udrulning |
| Mandag 14:00 | Pipelinen udruller det rettede image | Nyt artefakt kører; verifikation mangler |
| Mandag 14:20 | Artefaktscanning og regressionskontroller af eksport består | Rettelse 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
Kilder og videre læsning
- NIST: Secure Software Development Framework ↗
- CISA: Known Exploited Vulnerabilities Catalog ↗
- Taiga docs: Maintaining ↗
Relateret læsning fra Taiga
Fjerner du dette valg, slettes al fremgang gemt i denne browser.
Fremgangen bliver i denne browser. Ingen konto, ingen sporing.