Livscykeln för sårbarhetshantering hos programvaruleverantörer

Vad är livscykeln för sårbarhetshantering?

Livscykeln för sårbarhetshantering är den repeterbara process som en produktleverantör följer för att hantera en sårbarhet i programvara den levererar: ta emot eller hitta den, verifiera den, ta reda på vad som berörs, åtgärda den, släppa åtgärden och informera kunderna. Hos en leverantör drivs den oftast av ett incidentteam för produktsäkerhet (PSIRT), medan utvecklingsteamen tar fram åtgärderna.

Den här sidan handlar om leverantörssidan. Sårbarhetshantering inom IT, att skanna och patcha de servrar och laptops som en organisation driver, delar begreppen men inte de svåra delarna. En leverantör måste svara för varje release som stöds och finns hos kunderna, och måste publicera vad den har hittat.

Stegen i livscykeln

1. Ta emot eller upptäck. Sårbarheter kommer från externa forskare via ditt program för sårbarhetsrapportering, från kunder, från samordnare som nationella CSIRT och från din egen bevakning: en ny CVE i ett open source-beroende, ett fynd från en skanner eller ett internt test. Logga var och en med ett spårnings-id och bekräfta mottagandet till externa rapportörer.
2. Verifiera och triagera. Återskapa problemet eller bekräfta beroendematchningen, avgör om det är en sårbarhet i din produkt och bedöm hur allvarlig och hur brådskande den är. Stäng det som inte gäller, med ett skäl du kan visa senare. Prioriteringssignaler som EPSS och CISA:s KEV-katalog hjälper dig att rangordna det som återstår.
3. Bedöm berörda produkter och versioner. Hitta varje produkt, release och gren som stöds och som innehåller den sårbara koden eller komponenten, och varje kundinstallation som kör någon av dem. Det här steget avgör omfattningen av åtgärden och säkerhetsmeddelandet.
4. Åtgärda. Det ansvariga teamet tar fram och testar en åtgärd: ett uppgraderat beroende, en kodändring eller en begränsande åtgärd, till exempel en konfigurationsändring, när en rättning ännu inte är möjlig.
5. Släpp åtgärden. Leverera uppdaterade versioner för varje berörd gren som stöds, via en kanal som kunderna kan lita på.
6. Informera och offentliggör. Publicera ett säkerhetsmeddelande som anger vad som berörs, hur allvarligt det är och vad som ska göras, tilldela eller hänvisa till ett CVE-id och ge rapportören erkännande. Maskinläsbara format som CSAF och VEX gör att kunderna kan behandla säkerhetsmeddelanden automatiskt.
7. Bevaka och lär. Håll utkik efter utnyttjande och ny information, uppdatera säkerhetsmeddelandet och för tillbaka grundorsaken till utvecklingen, så att samma typ av brist inte levereras igen.

ISO/IEC 30111 och ISO/IEC 29147

Två internationella standarder beskriver den här livscykeln för leverantörer. De delar upp den vid organisationens gräns:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Titel	Vulnerability handling processes	Vulnerability disclosure
Omfattar	Det som händer internt: verifiering, utredning, prioritering och åtgärd	Gränssnitten: att ta emot rapporter och publicera säkerhetsmeddelanden
Centralt innehåll	Policy och organisation, PSIRT:s ansvar, hanteringsfaser, hänsyn till leveranskedjan	Intressenters roller, hantering av rapporter, innehåll i säkerhetsmeddelanden, samordning, policy för offentliggörande
Målgrupp	Leverantörer som hanterar rapporterade sårbarheter	Leverantörer som tar emot rapporter och offentliggör sårbarheter

Standarderna är utformade för att användas tillsammans. ISO/IEC 30111 anger sex hanteringsfaser: förberedelse, mottagande, verifiering, utveckling av åtgärd, release och efter release. Den kräver också uppföljning av processen, sekretess kring information om sårbarheter och uppmärksamhet på leveranskedjan, eftersom många sårbarheter finns i komponenter du inte har skrivit. Båda standarderna är aktuella utgåvor, bekräftade vid ISO:s senaste granskningar, och är markerade för revidering.

Andra ramverk följer samma mönster. FIRST PSIRT Services Framework delar in arbetet i upptäckt av sårbarheter, triagering och analys, åtgärd och offentliggörande, och IEC 62443-4-1 tar med säkerhetsuppdateringar och hantering av defekter i sin livscykel för säker utveckling av industriella produkter.

Roller

• PSIRT eller produktsäkerhetsteam: äger processen, tar emot rapporter, triagerar, samordnar åtgärder och publicerar säkerhetsmeddelanden. Se CRACI för PSIRT-team och hur ett PSIRT skiljer sig från ett CSIRT.
• Produkt- och utvecklingsteam: äger koden, tar fram och testar åtgärderna och levererar releaserna.
• Releasehantering: avgör vilka grenar som stöds som får en åtgärd, och när.
• Kundsupport och kommunikation: hanterar kundfrågor och säkerhetsmeddelandets målgrupp.
• Juridik: ger råd om offentliggörande, avtal och anmälningar till myndigheter.
• Externa parter: rapportörer, samordnare som CERT/CC eller ett nationellt CSIRT, underhållare uppströms av berörda komponenter och kunder som måste driftsätta åtgärden.

Tidslinjer och SLA:er

Det finns ingen enskild obligatorisk tidslinje. De flesta leverantörer sätter interna mål efter allvarlighetsgrad och publicerar de externa i sin policy för offentliggörande. En typisk struktur:

• Bekräfta en extern rapport inom några arbetsdagar.
• Triagera inom några dagar, så att rapportören och det ansvariga teamet vet var ärendet står.
• Åtgärda enligt en tidsfrist som styrs av allvarlighetsgrad och utnyttjande, kortast för kritiska fynd och allt som är känt för att utnyttjas.
• Offentliggör när åtgärden är tillgänglig, eller vid en överenskommen tidsfrist om åtgärden försenas.

Yttre press sätter den yttersta gränsen. Forskare sätter ofta en tidsfrist för offentliggörande (Google Project Zero ger leverantörer 90 dagar), och regelverk lägger till egna: EU:s Cyber Resilience Act kräver att tillverkare åtgärdar sårbarheter utan dröjsmål och sätter tidsfrister för rapportering av aktivt utnyttjade sårbarheter (se vad CRA kräver). När en sårbarhet redan utnyttjas, som vid en zero-day, körs varje steg med den kortaste tidsfristen.

Där livscykeln brister

De flesta förseningar uppstår inte när åtgärden skrivs. De kommer av att du inte vet vad du har levererat.

• Att inte veta vilka releaser som innehåller en komponent. En ny CVE dyker upp i ett bibliotek. Vilka av förra årets releaser innehåller det, och vilka kunder kör dem? Utan en registrering per release bygger team om gamla taggar eller söker igenom repon för hand, och listan över berörda versioner i säkerhetsmeddelandet blir en gissning.
• Transitiva beroenden. Många sårbara paket är inte sådana som du har valt. De kommer in som transitiva beroenden flera nivåer ner, så en sökning i dina manifest missar dem.
• Brus från utvecklingsberoenden. Skannrar som läser lockfiler rapporterar testramverk och byggverktyg som aldrig levereras. Varje sådant kostar triageringstid och begraver de fynd som spelar roll.
• Komponenter utanför pakethanteraren. Binärer som laddas ner av byggskript, basavbilder och leverantörskomponenter finns inte i en lockfile alls.
• Oklart ägarskap. Ett fynd som inget team äger blir liggande. Triageringen är klar först när åtgärden har en ägare.
• Åtgärder som inte håller. En sårbar version kommer tillbaka via ett annat beroende eller en gammal gren, eftersom inget hindrar den från att komma in i nästa bygge.

Mätetal

Mätetal	Vad det visar
Tid till bekräftelse	Om rapportörer får svar när din policy säger att de ska få det
Tid till triagering	Hur länge ett fynd väntar innan någon vet om det spelar roll
Tid till åtgärd, per allvarlighetsgrad	Hur snabbt åtgärder levereras, mätt från mottagande till tillgänglig release
Tid till säkerhetsmeddelande	Hur länge kunderna väntar på information efter åtgärden
Andel inom målet	Om interna SLA:er håller, särskilt för kritiska och utnyttjade fynd
Backlogg efter ålder	Fynd som har fastnat, och var
Andel ej berörda	Hur mycket triageringsarbete som går till fynd som inte gäller

Mät varje steg för sig. En lång tid till åtgärd visar sig ofta vara en lång tid för att hitta de berörda releaserna.

Driv livscykeln utifrån en registrering av vad du har levererat

Varje steg efter triageringen är beroende av att du vet vad som finns i varje release. CRACI kör dina GitHub Actions-byggen på sina egna runners och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, paket som återställs från CI-cachar och beroenden som ingen lockfile listar. Varje SBOM har en fullständighetsstatus och kan exporteras som CycloneDX eller SPDX.

CRACI omvärderar bevakade SBOM:er löpande och sammanställer dem över byggen och repon, och leverantörers SBOM:er kan läggas till så att inköpta komponenter bevakas tillsammans med dina egna. När en ny CVE dyker upp visar bygghistoriken vilka tidigare byggen som innehöll det sårbara beroendet, direkt eller transitivt, så att du vet under vilken period du var berörd, och inventeringsvyn visar vilka programvaruversioner som är driftsatta i vilka produkter. Säkerhetsteamen triagerar fynd i CRACI och skickar dem till teamen som äger åtgärden, CRACI har stöd för VEX, och policyspärrar kan blockera byggen som innehåller en specifik CVE så att en åtgärdad sårbarhet hålls borta. Se sårbarhetsspårning.

Livscykeln för sårbarhetshantering: vanliga frågor

Vilka steg har livscykeln för sårbarhetshantering?

För en produktleverantör: ta emot eller upptäck sårbarheten, verifiera och triagera den, hitta berörda produkter och versioner, ta fram åtgärden, släpp åtgärden, publicera säkerhetsmeddelandet, bevaka och lär. ISO/IEC 30111 anger faserna förberedelse, mottagande, verifiering, utveckling av åtgärd, release och efter release.

Vad är ISO/IEC 30111?

ISO/IEC 30111:2019 är den internationella standarden för processer för hantering av sårbarheter. Den ger leverantörer krav och rekommendationer för att behandla och åtgärda rapporterade sårbarheter i sina produkter och tjänster, från policy och PSIRT:s roll till hanteringsfaser och hänsyn till leveranskedjan.

Vad är skillnaden mellan ISO/IEC 30111 och ISO/IEC 29147?

ISO/IEC 29147 omfattar den utåtriktade delen: att ta emot rapporter och publicera säkerhetsmeddelanden. ISO/IEC 30111 omfattar den interna hanteringen däremellan: verifiering, utredning, prioritering och åtgärd. De två är avsedda att användas tillsammans. Se samordnat offentliggörande av sårbarheter för sidan som rör 29147.

Vad är triagering av sårbarheter?

Triagering är steget där ett säkerhetsteam bekräftar att en rapporterad eller upptäckt sårbarhet är verklig, bedömer hur allvarlig och brådskande den är för din produkt och skickar den till teamet som äger åtgärden. Bra triagering stänger också de fynd som inte gäller, med ett registrerat skäl.

Hur skiljer sig sårbarhetshantering för produkter från den inom IT?

Sårbarhetshantering inom IT patchar de system som en organisation driver. Sårbarhetshantering för produkter hanterar brister i programvara som organisationen bygger och levererar till andra, så den lägger till steg som IT-team inte har: att ta reda på vilka släppta versioner som berörs, leverera en åtgärd till kunderna och informera dem i ett säkerhetsmeddelande.

Vilka mätetal bör en process för sårbarhetshantering följa?

Tid till bekräftelse av en rapport, tid till triagering, tid till åtgärd och tid till säkerhetsmeddelande, var och en per allvarlighetsgrad, plus andelen fynd som når dina interna mål, den öppna backloggen efter ålder och hur många fynd som stängts som ej berörda.