Lärstig 05Lektion 3 / 8

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.

Praktisk nivå12 minGranskad

Publicerad av Så 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

KontrollAnvändbar täckningViktig begränsning
Software composition analysis, SCAKända sårbarheter i beroenden, inklusive identifierade transitiva paketFastställer inte att applikationens auktorisering är korrekt
Static application security testing, SASTOsäkra kodmönster som verktyget stöderKan missa beteende vid körning och ge fynd som behöver bedömas
Skanning efter hemligheterKända mönster för autentiseringsuppgifter i skannat innehållEn borttagen sträng kan lämna en giltig autentiseringsuppgift på annat håll
Kontroller av infrastruktur och konfigurationDefinierade policybrott i skannade resurser eller konfigurationerKonfigurationen i repositoryt kan skilja sig från miljön som körs
Behörig dynamisk testningBeteendet hos en applikation som körs inom testets omfångKrä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

TidHändelseFaktisk status
Måndag 09:00Ett nytt säkerhetsmeddelande identifierar ett berört PDF-beroendeBefintliga releaser behöver bedömas
Måndag 09:15En schemalagd skanning identifierar produktionsversionenFyndet är upptäckt, inte åtgärdat
Måndag 10:00Ansvarig bekräftar exponeringen och väljer en patch som stödsÅtgärden är planerad
Måndag 13:00Tester godkänns och PR:n med patchen mergasRepositoryt är korrigerat; produktionen behöver fortfarande driftsättningen
Måndag 14:00Pipelinen driftsätter den korrigerade avbildningenDen nya artefakten körs; verifiering återstår
Måndag 14:20Artefaktskanning och regressionstester av exporten godkännsKorrigeringen ä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

En applikation har inte ändrats på tre månader. Den senaste skanningen av beroenden godkändes vid release. Vilket påstående har stöd?

Källor och vidare läsning

Relaterad läsning från Taiga