Livssyklusen for sårbarhetshåndtering hos programvareleverandører

Hva er livssyklusen for sårbarhetshåndtering?

Livssyklusen for sårbarhetshåndtering er den gjentakbare prosessen en produktleverandør følger for å håndtere en sårbarhet i programvare den leverer: motta eller finne den, verifisere den, finne ut hva som er berørt, rette den, gi ut rettingen og informere kundene. Hos en leverandør drives den vanligvis av et product security incident response team (PSIRT), mens utviklingsteamene gjør rettingene.

Denne siden handler om leverandørsiden. IT-sårbarhetshåndtering, å skanne og patche serverne og laptopene en organisasjon drifter, deler vokabularet, men ikke de vanskelige delene. En leverandør må stå til ansvar for hver støttet utgivelse kundene har, og må publisere det den fant.

Stadiene i livssyklusen

1. Motta eller oppdage. Sårbarheter kommer fra eksterne forskere gjennom programmet ditt for offentliggjøring, fra kunder, fra koordinatorer som nasjonale CSIRT-er og fra din egen overvåking: en ny CVE i en avhengighet med åpen kildekode, et skannerfunn eller en intern test. Loggfør hver av dem med en sporings-ID, og bekreft mottak overfor eksterne rapportører.
2. Verifisere og triagere. Reproduser problemet eller bekreft avhengighetstreffet, avgjør om det er en sårbarhet i produktet ditt, og vurder hvor alvorlig og hvor hastende det er. Lukk det som ikke gjelder, med en begrunnelse du kan vise senere. Prioriteringssignaler som EPSS og CISA KEV-katalogen hjelper deg å rangere det som gjenstår.
3. Vurdere berørte produkter og versjoner. Finn hvert produkt, hver utgivelse og hver støttet gren som inneholder den sårbare koden eller komponenten, og hver kundeinstallasjon som kjører en av dem. Dette steget avgjør omfanget av rettingen og advisoryen.
4. Utbedre. Teamet som eier koden, utvikler og tester en retting: en oppgradert avhengighet, en kodeendring eller et avbøtende tiltak, for eksempel en konfigurasjonsendring når en retting ennå ikke er mulig.
5. Gi ut rettingen. Lever oppdaterte versjoner for hver berørt støttet gren, gjennom en kanal kundene kan stole på.
6. Varsle og offentliggjøre. Publiser en advisory som sier hva som er berørt, hvor alvorlig det er, og hva man skal gjøre, tildel eller henvis til en CVE-ID, og krediter rapportøren. Maskinlesbare formater som CSAF og VEX lar kunder behandle advisories automatisk.
7. Overvåke og lære. Følg med på utnyttelse og ny informasjon, oppdater advisoryen, og før rotårsaken tilbake til utviklingen, så samme type feil ikke leveres igjen.

ISO/IEC 30111 og ISO/IEC 29147

To internasjonale standarder beskriver denne livssyklusen for leverandører. De deler den ved organisasjonens grense:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Tittel	Vulnerability handling processes	Vulnerability disclosure
Dekker	Det som skjer internt: verifisering, undersøkelse, prioritering og utbedring	Grensesnittene: mottak av rapporter og publisering av advisories
Hovedinnhold	Policy og organisering, PSIRT-ansvar, håndteringsfaser, hensyn til leverandørkjeden	Interessentroller, rapporthåndtering, innhold i advisories, koordinering, policy for offentliggjøring
Målgruppe	Leverandører som håndterer rapporterte sårbarheter	Leverandører som mottar rapporter og offentliggjør sårbarheter

Standardene er laget for å brukes sammen. ISO/IEC 30111 nevner seks håndteringsfaser: forberedelse, mottak, verifisering, utvikling av utbedring, utgivelse og etter utgivelse. Den ber også om prosessovervåking, konfidensialitet for sårbarhetsinformasjon og oppmerksomhet på leverandørkjeden, siden mange sårbarheter ligger i komponenter du ikke har skrevet. Begge standardene er gjeldende utgaver, bekreftet ved de siste ISO-gjennomgangene, og er merket for revisjon.

Andre rammeverk følger samme mønster. FIRST PSIRT Services Framework deler arbeidet inn i oppdagelse av sårbarheter, triage og analyse, utbedring og offentliggjøring, og IEC 62443-4-1 inkluderer sikkerhetsoppdateringer og feilhåndtering i sin livssyklus for sikker utvikling av industriprodukter.

Roller

• PSIRT eller produktsikkerhetsteam: eier prosessen, mottar rapporter, triagerer, koordinerer rettinger og publiserer advisories. Se CRACI for PSIRT-team og hvordan et PSIRT skiller seg fra et CSIRT.
• Produkt- og utviklingsteam: eier koden, utvikler og tester rettingene og leverer utgivelsene.
• Release management: avgjør hvilke støttede grener som får en retting, og når.
• Kundestøtte og kommunikasjon: håndterer spørsmål fra kunder og målgruppen for advisoryen.
• Juridisk: gir råd om offentliggjøring, kontrakter og varsling til myndigheter.
• Eksterne parter: rapportører, koordinatorer som CERT/CC eller et nasjonalt CSIRT, upstream-vedlikeholdere av berørte komponenter og kunder som må rulle ut rettingen.

Tidsfrister og SLA-er

Det finnes ingen enkelt påkrevd tidsfrist. De fleste leverandører setter interne mål etter alvorlighetsgrad og publiserer de eksterne i policyen for offentliggjøring. En typisk struktur:

• Bekreft mottak av en ekstern rapport innen noen få virkedager.
• Triager innen få dager, så rapportøren og teamet som eier saken, vet hvor den står.
• Utbedr etter en frist satt ut fra alvorlighetsgrad og utnyttelse, kortest for kritiske funn og alt som er kjent utnyttet.
• Offentliggjør når rettingen er tilgjengelig, eller ved en avtalt frist hvis rettingen blir forsinket.

Press utenfra setter yttergrensen. Forskere setter ofte en frist for offentliggjøring (Google Project Zero gir leverandører 90 dager), og regelverk legger til sine egne: EUs Cyber Resilience Act krever at produsenter utbedrer sårbarheter uten opphold, og setter rapporteringsfrister for aktivt utnyttede sårbarheter (se hva CRA krever). Når en sårbarhet allerede blir utnyttet, som ved en zero-day, kjører hvert stadium på den korteste fristen.

Her svikter livssyklusen

De fleste forsinkelser ligger ikke i å skrive rettingen. De kommer av at du ikke vet hva du har levert.

• Du vet ikke hvilke utgivelser som inneholder en komponent. En ny CVE dukker opp i et bibliotek. Hvilke av fjorårets utgivelser inneholder det, og hvilke kunder kjører dem? Uten en registrering per utgivelse bygger team gamle tagger på nytt eller søker i repositorier for hånd, og listen over berørte versjoner i advisoryen blir en gjetning.
• Transitive avhengigheter. Mange sårbare pakker er ikke pakker du har valgt. De kommer som transitive avhengigheter flere nivåer ned, så et søk i manifestene dine går glipp av dem.
• Støy fra utviklingsavhengigheter. Skannere som leser lockfiler, rapporterer testrammeverk og byggeverktøy som aldri leveres. Hvert av dem koster tid i triage og begraver funnene som betyr noe.
• Komponenter utenfor pakkebehandleren. Binærfiler lastet ned av byggeskript, base-images og leverandørkomponenter dukker ikke opp i en lockfile i det hele tatt.
• Uklart eierskap. Et funn ingen team eier, blir liggende. Triage er først ferdig når rettingen har en eier.
• Rettinger som ikke varer. En sårbar versjon kommer tilbake gjennom en annen avhengighet eller en gammel gren, fordi ingenting hindrer den i å komme inn i neste bygg.

Nøkkeltall

Nøkkeltall	Hva det viser
Tid til bekreftelse	Om rapportører får svar når policyen din sier at de skal
Tid til triage	Hvor lenge et funn venter før noen vet om det betyr noe
Tid til utbedring, etter alvorlighetsgrad	Hvor raskt rettinger leveres, målt fra mottak til en tilgjengelig utgivelse
Tid til advisory	Hvor lenge kundene venter på informasjon etter rettingen
Andel innenfor målet	Om interne SLA-er holder, særlig for kritiske og utnyttede funn
Backlog etter alder	Funn som står fast, og hvor
Andel ikke berørt	Hvor mye triage-innsats som går til funn som ikke gjelder

Mål hvert stadium for seg. En lang tid til utbedring viser seg ofte å være en lang tid til å finne de berørte utgivelsene.

Kjør livssyklusen på en registrering av det du leverte

Hvert stadium etter triage er avhengig av at du vet hva som er i hver utgivelse. CRACI kjører GitHub Actions-byggene dine på sine egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra CI-cacher og avhengigheter som ingen lockfile lister opp. Hver SBOM har en fullstendighetsstatus og kan eksporteres som CycloneDX eller SPDX.

CRACI vurderer overvåkede SBOM-er på nytt kontinuerlig og samler dem på tvers av bygg og repositorier, og SBOM-er fra leverandører kan legges til, så innkjøpte komponenter overvåkes sammen med dine egne. Når en ny CVE dukker opp, viser byggehistorikken hvilke tidligere bygg som inneholdt den sårbare avhengigheten, direkte eller transitiv, så du vet i hvilken periode du var berørt, og inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter. Sikkerhetsteam triagerer funn i CRACI og sender dem til teamene som eier rettingen, CRACI støtter VEX, og policy gates kan blokkere bygg som inneholder en bestemt CVE, så en rettet sårbarhet holdes ute. Se sårbarhetssporing.

Livssyklusen for sårbarhetshåndtering: ofte stilte spørsmål

Hva er stadiene i livssyklusen for sårbarhetshåndtering?

For en produktleverandør: motta eller oppdage sårbarheten, verifisere og triagere den, finne de berørte produktene og versjonene, utvikle utbedringen, gi ut rettingen, publisere advisoryen og deretter overvåke og lære. ISO/IEC 30111 nevner fasene forberedelse, mottak, verifisering, utvikling av utbedring, utgivelse og etter utgivelse.

Hva er ISO/IEC 30111?

ISO/IEC 30111:2019 er den internasjonale standarden for prosesser for håndtering av sårbarheter. Den gir leverandører krav og anbefalinger for å behandle og utbedre rapporterte sårbarheter i produktene og tjenestene sine, fra policy og PSIRT-rollen til håndteringsfasene og hensyn til leverandørkjeden.

Hva er forskjellen på ISO/IEC 30111 og ISO/IEC 29147?

ISO/IEC 29147 dekker den utadvendte delen: å motta rapporter og publisere advisories. ISO/IEC 30111 dekker den interne håndteringen imellom: verifisering, undersøkelse, prioritering og retting. De to er ment å brukes sammen. Se koordinert offentliggjøring av sårbarheter for 29147-siden.

Hva er triage av sårbarheter?

Triage er steget der et sikkerhetsteam bekrefter at en rapportert eller oppdaget sårbarhet er reell, vurderer hvor alvorlig og hvor hastende den er for produktet ditt, og sender den til teamet som eier rettingen. God triage lukker også funn som ikke gjelder, med en registrert begrunnelse.

Hvordan skiller sårbarhetshåndtering for produkter seg fra IT-sårbarhetshåndtering?

IT-sårbarhetshåndtering patcher systemene en organisasjon drifter. Sårbarhetshåndtering for produkter tar for seg feil i programvare organisasjonen bygger og leverer til andre, så den legger til steg IT-team ikke har: å finne ut hvilke utgitte versjoner som er berørt, levere en retting til kundene og fortelle dem om den i en advisory.

Hvilke nøkkeltall bør en prosess for sårbarhetshåndtering følge?

Tid til bekreftelse av en rapport, tid til triage, tid til utbedring og tid til advisory, hver etter alvorlighetsgrad, pluss andelen funn som oppfyller de interne målene dine, den åpne backloggen etter alder og hvor mange funn som ble lukket som ikke berørt.