Fortsätt att hitta och åtgärda sårbarheter
Bygg en kontinuerlig process från upptäckt av sårbarheter till verifierad åtgärd i produktion. Förstå underhållsluckan som en lyckad prototyp kan dölja.
Publicerad av TaigaSå skriver vi
Det här lär du dig
- Förklara varför oförändrad programvara behöver fortlöpande säkerhetsgranskning.
- Koppla olika slags skanning till deras täckning och begränsningar.
- Följ ett fynd genom prioritering, korrigering, driftsättning och verifiering.
En fungerande prototyp kan bli en tjänst utan underhåll
Vibe coding kan snabbt ge en användbar prototyp. Risken i produktion växer när människor fortsätter använda den utan löpande säkerhetsunderhåll. Det är en allvarlig lucka: programvaran förblir exponerad medan den som skapade den betraktar arbetet som klart.
Luckan är både organisatorisk och teknisk. En skanner kan finnas utan ansvarig. Ett fynd kan ha en ansvarig utan en väg till release. En mergad korrigering kan lämna den gamla produktionsartefakten i drift.
Utvärdera den faktiska utvecklingsplattformen och dess konfiguration. Vissa verktyg erbjuder säkerhetsfunktioner. En produktetikett fastställer inte om din driftsatta applikation får kontinuerlig skanning och verifierade korrigeringar.
Skanna när underlaget kan förändras
Kör relevanta kontroller på föreslagna ändringar och byggda artefakter. Bedöm versioner som stöds på nytt enligt ett schema, eftersom säkerhetsinformationen ändras utan en commit. Starta ytterligare granskning när ett relevant säkerhetsmeddelande, en ändrad exponering eller en incident uppstår.
Håll omfattningen uttrycklig. Identifiera repositoryn, brancher, lockfiler, avbildningar, driftsatta digests, körmiljöer och miljöer. Ta med applikationer som inte längre får nya funktioner men fortfarande har användare.
En misslyckad skanning innebär saknat underlag. Övervaka skanningarnas aktualitet, fel i informationsflöden, autentiseringsfel, komponenter utan stöd och luckor i täckningen. En tom fyndlista efter ett misslyckat jobb är inte ett rent resultat.
Använd olika kontroller för olika frågor
| Kontroll | Användbar täckning | Viktig begränsning |
|---|---|---|
| Software composition analysis, SCA | Kända sårbarheter i beroenden, inklusive identifierade transitiva paket | Fastställer inte att applikationens auktorisering är korrekt |
| Static application security testing, SAST | Osäkra kodmönster som verktyget stöder | Kan missa beteende vid körning och ge fynd som behöver bedömas |
| Skanning efter hemligheter | Kända mönster för autentiseringsuppgifter i skannat innehåll | En borttagen sträng kan lämna en giltig autentiseringsuppgift på annat håll |
| Kontroller av infrastruktur och konfiguration | Definierade policybrott i skannade resurser eller konfigurationer | Konfigurationen i repositoryt kan skilja sig från miljön som körs |
| Behörig dynamisk testning | Beteendet hos en applikation som körs inom testets omfång | Kräver tillstånd, lämpliga data och försiktighet med sidoeffekter |
Kombinera kontrollerna med granskning och relevanta säkerhetstester. Påstå inte att någon skanning bevisar att sårbarheter saknas.
Följ ett fiktivt fynd till produktion
| Tid | Händelse | Faktisk status |
|---|---|---|
| Måndag 09:00 | Ett nytt säkerhetsmeddelande identifierar ett berört PDF-beroende | Befintliga releaser behöver bedömas |
| Måndag 09:15 | En schemalagd skanning identifierar produktionsversionen | Fyndet är upptäckt, inte åtgärdat |
| Måndag 10:00 | Ansvarig bekräftar exponeringen och väljer en patch som stöds | Åtgärden är planerad |
| Måndag 13:00 | Tester godkänns och PR:n med patchen mergas | Repositoryt är korrigerat; produktionen behöver fortfarande driftsättningen |
| Måndag 14:00 | Pipelinen driftsätter den korrigerade avbildningen | Den nya artefakten körs; verifiering återstår |
| Måndag 14:20 | Artefaktskanning och regressionstester av exporten godkänns | Korrigeringen är verifierad inom det kontrollerade omfånget |
Prioritera utifrån allvarlighetsgrad, belägg för utnyttjande, exponering, berörda data och tillgängliga begränsande åtgärder. CISA:s katalog hjälper till att identifiera känt utnyttjande. Den är ett underlag, inte en fullständig riskbedömning. CISA:s katalog.
Ett tillfälligt undantag behöver underlag, ansvarig, kompenserande kontroller och en sluttid eller händelse som utlöser ny granskning. Om det inte finns någon patch, överväg en godkänd tillfällig lösning, begränsning av funktionen eller borttagning av den berörda komponenten.
Stäng underhållsluckan
Mät tiden till bedömning och verifierad åtgärd per prioritet. Följ upp förfallna undantag, inaktuella skanningar, berörda produktionsversioner och återkommande fynd. Ett minskat antal fynd kan också bero på minskad täckning. Granska nämnaren.
Taiga Maintaining skannar länkade repositoryn efter ändringar och med jämna mellanrum. Det registrerar fynd och kopplar åtgärder till initiativ och granskade ändringar. Kontrollera skanningens status och det aktuella dokumenterade beteendet. Maintaining.
Din pipeline behöver fortfarande lämpliga releasekontroller. Tjänsteansvarig behöver fortfarande bekräfta driftsättningen och korrekt drift. Den kontinuerliga kedjan ingår i att driva en AI-programvarufabrik, även för produkter vars första version var en prototyp.
Gör övningen
Använd lektionens fiktiva tidslinje. Identifiera var teamet felaktigt skulle kunna förklara arbetet klart. Definiera skanningens utlösande händelser, fellarm, åtgärdsansvarig, releaseverifiering och sluttid för ett tillfälligt undantag.
Ladda ned övningsblad (Markdown)Kontrollera din förståelse
Källor och vidare läsning
- NIST: Secure Software Development Framework ↗
- CISA: Known Exploited Vulnerabilities Catalog ↗
- Taiga docs: Maintaining ↗
Relaterad läsning från Taiga
Om du avmarkerar valet raderas alla framsteg som sparats i den här webbläsaren.
Framstegen stannar i webbläsaren. Inget konto, ingen spårning.