Sårbarhetssporing
Spor hver kjente sårbarhet i programvaren du leverer, fra bygget som hentet den inn, til utgivelsen som rettet den. CRACI registrerer SBOM-en til hvert bygg, sjekker den fortløpende mot nye sårbarhetsdata og sender hvert funn til teamet som eier rettelsen.
Hva er sårbarhetssporing?
Sårbarhetssporing er den løpende registreringen av hver kjente sårbarhet som påvirker programvaren din, fra den oppdages til den er rettet eller avskrevet. For hver av dem svarer den på fire spørsmål: Hvor finnes den, hvilke produkter og utgivelser inneholder den, hvem eier rettelsen, og hva er statusen?
Mange verktøy svarer på det første spørsmålet ved å skanne manifest- og lockfiler i etterkant, og overlater resten til regneark og saker. CRACI begynner tidligere. GitHub Actions-jobbene dine kjører på CRACI-runnere, og mens de kjører, registrerer CRACI hver pakke bygget faktisk hentet inn, inkludert pakker gjenopprettet fra CI-cacher. Det er denne SBOM-en fra bygget CRACI overvåker, så sårbarhetene du sporer, er de som finnes i artefaktet du leverte, ikke i en skanning som kjørte et sted i nærheten.
Spor programvaren du leverer, ikke bare IT-ressursene dine
De fleste verktøy for sårbarhetssporing er laget for IT: De skanner servere, bærbare PC-er og skykontoer, og rettelsen er en patch noen installerer. Programvare du bygger og selger, trenger en annen type registrering. Den sårbare koden ligger inne i utgivelsen din, rettelsen er et nytt bygg, og kunder og myndigheter spør hvilke versjoner som var berørt, og hvor lenge.
Det er den registreringen CRACI fører: SBOM-en til hvert bygg, produktene og versjonene den ble rullet ut på, leverandørkomponentene du har kjøpt inn, og statusen til hver sårbarhet på tvers av alt sammen.
Fortløpende ny vurdering av det du har levert
CRACI registrerer SBOM-en mens hvert bygg kjører, og vurderer deretter overvåkede SBOM-er fortløpende på nytt mot sårbarhetsdata. En sårbarhet som publiseres lenge etter en utgivelse, dukker likevel opp på utgivelsen den rammer, uten at noen kjører en ny skanning.
Én visning på tvers av bygg og repositorier
Funn samles på tvers av bygg og repositorier, med organisasjonsvisninger for standardgrenen. Inventarvisningen viser nøyaktig hvilke programvareversjoner som er rullet ut på hvilke produkter, og byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar avhengighet, så du vet hvilke produkter som var berørt, og hvor lenge.
Triage og videresending til teamet som eier rettelsen
Sikkerhetsteam triagerer oppdagede sårbarheter og sender dem til teamene som eier rettelsen, så hvert funn når menneskene som kan gjøre noe med det. CRACI støtter også VEX for å registrere hvordan en sårbarhet påvirker produktet ditt, og policy gates kan blokkere ethvert bygg som inneholder en bestemt CVE.
Leverandørenes SBOM-er sporet ved siden av dine egne
Legg til SBOM-er fra leverandørene dine, så overvåkes innkjøpte komponenter side om side med programvaren du bygger. Tredjepartskode i produktet ditt spores på samme sted som dine egne avhengigheter.
Fra funn til CRA-varsling
For Cyber Resilience Act sender CRACI inn sårbarhetsvarslene på dine vegne: det tidlige varselet, varslingen og sluttrapporten. SBOM-er eksporteres som CycloneDX eller SPDX med sårbarhetene som er funnet i komponentene, til revisjoner, kunder og din egen dokumentasjon.
Hver sårbare pakke, og hva som trekker den inn
Hvert bygg viser pakkene sine med versjon, package URL, lisens og sårbarhetsstatus, og viser om SBOM-en er fullstendig. Åpne en pakke for å se advisoryene med alvorlighetsgrad, og pakkene som krever den.
Livssyklusen for sårbarhetssporing i CRACI
- Oppdag. Hvert bygg produserer en SBOM med fullstendighetsstatus, eksportert som CycloneDX eller SPDX med transitive avhengigheter. Overvåkede SBOM-er, både dine egne og leverandørenes, vurderes fortløpende på nytt mot sårbarhetsdata.
- Lokaliser. Organisasjonsvisninger på tvers av bygg og repositorier, inventarvisningen og byggehistorikken viser hvilke produkter og versjoner som er berørt, og siden når.
- Prioriter og triager. Hver advisory viser alvorlighetsgraden. Sikkerhetsteam triagerer hvert funn, med VEX-støtte for å registrere hvordan en sårbarhet påvirker produktet ditt.
- Utbedre. Hvert funn går til teamet som eier rettelsen, og «Required by» viser hvilken pakke som trekker inn en transitiv sårbarhet. Policy gates kan holde en bestemt CVE ute av senere bygg.
- Verifiser. SBOM-en til neste bygg viser om den sårbare versjonen er borte, så registreringen går helt fram til den rettede utgivelsen.
- Rapporter. CRACI sender inn CRA-sårbarhetsvarsler på dine vegne, og SBOM-er eksporteres med sårbarhetene som er funnet i komponentene.
Hva du bør spore for hver sårbarhet
- Sårbarhet
- Advisoryen og ID-ene (CVE, GHSA og andre), med alvorlighetsgrad.
- Komponent
- Pakken og den nøyaktige versjonen, og om det er en direkte eller transitiv avhengighet.
- Sti
- Pakkene som trekker inn den sårbare, som forteller deg hva du skal oppgradere.
- Eksponering
- Hvilke produkter, utgivelser og bygg som inneholder den, og siden når.
- Eier
- Teamet som har ansvaret for rettelsen.
- Status
- Åpen, under undersøkelse, ikke berørt eller rettet, helst registrert som VEX.
- Dokumentasjon
- Bygget eller utgivelsen som ikke lenger inneholder den sårbare versjonen.
Nøkkeltall som viser om sporingen fungerer
Sikkerhetsteam rapporterer vanligvis på fire tall:
- Gjennomsnittlig tid til utbedring (MTTR): hvor lang tid det tar fra en sårbarhet blir funnet, til en utgivelse uten den.
- Overholdelse av utbedringsfrister: andelen sårbarheter som rettes innen fristen policyen din setter for alvorlighetsgraden deres.
- Utvikling i etterslepet: om antallet åpne sårbarheter går opp eller ned.
- Eksponeringsvindu: hvor lenge hvert produkt ble levert med en sårbar versjon. Byggehistorikken i CRACI viser hvilke bygg som inneholdt en sårbar avhengighet, så du vet i hvilken periode du var berørt.
Hva CRACI ikke gjør i dag
CRACI tilbyr ikke reachability-analyse, så den rangerer ikke funn etter om koden din kaller den sårbare funksjonen. Den viser ikke utbedringsnøkkeltall som MTTR, overholdelse av frister eller utviklingen i etterslepet. Den varsler ikke ut fra en terskel for alvorlighetsgrad i dag, og varslene dekker brudd på egress-policyen. Kommentarer på funn, en sammenligning mellom utgivelser, terskelvarsler og webhooks for sårbarheter er på veikartet.
VEX: hvilke sårbarheter som faktisk påvirker produktet ditt
En sårbar komponent i SBOM-en din betyr ikke alltid et sårbart produkt. Den berørte koden er kanskje ikke med i det du leverer, eller kan kanskje ikke nås på den måten et angrep krever. VEX (Vulnerability Exploitability eXchange) er en maskinlesbar måte å si det på: Hver VEX-erklæring knytter sammen et produkt, en sårbarhet og en status. Standardstatusene er ikke berørt, berørt, rettet og under undersøkelse.
Det får betydning når kunder og myndigheter sjekker SBOM-ene dine mot sårbarhetsdatabaser. Uten en VEX-erklæring ser hvert treff ut som en åpen sak, og teamet ditt ender opp med å forklare de samme falske positivene om og om igjen. CRACI støtter VEX for å registrere hvordan en sårbarhet påvirker produktet ditt, sammen med triagen som sender hvert funn til teamet som eier rettelsen.
Lurer du på hvor mye det er å holde tritt med? Se hvor mange CVE-er som publiseres hver dag, og hvor mye volumet av sårbarheter med High og Critical har vokst.
Sårbarhetssporing forklart
Vanlige spørsmål om å spore sårbarheter i programvaren du bygger og kjøper
Hva er sårbarhetssporing?
Sårbarhetssporing er den løpende registreringen av hver kjente sårbarhet som påvirker programvaren din, fra den blir funnet til den er rettet eller avskrevet: hvilken komponent og versjon den finnes i, hvilke produkter og utgivelser som inneholder den, hvem som eier rettelsen, og hva statusen er. For programvare du leverer, starter den med en nøyaktig liste over komponenter, og det er nettopp det en SBOM gir.
Hva er stegene i sårbarhetshåndtering?
Den vanlige syklusen har fem steg: oppdag sårbarhetene i det du kjører eller leverer, prioriter dem, utbedre dem, verifiser at rettelsen fjernet dem, og rapporter. Sporingen er det som binder stegene sammen, så et funn ikke blir borte mellom oppdagelsen og en rettet utgivelse. I CRACI er stegene å registrere SBOM-en fra bygget, triagere hvert funn, sende det til teamet som eier det, bekrefte at et senere bygg ikke lenger inneholder den sårbare versjonen, og rapportere gjennom SBOM-eksporter og CRA-varsler.
Hvordan sporer du utbedring av sårbarheter?
Gi hver sårbarhet en eier og en status, og lukk den først når et bygg eller en utgivelse ikke lenger inneholder den sårbare versjonen. Mål hvor lang tid rettelser tar, om de overholder fristene dine, og om etterslepet av åpne saker krymper. I CRACI viser hvert byggs SBOM om den sårbare versjonen fortsatt er der, og en policy gate kan holde en bestemt CVE ute av senere bygg.
Hva er sårbarhetshåndtering med SBOM?
Sårbarhetshåndtering med SBOM betyr å matche komponentene som står oppført i programvarens stykklister (SBOM-er), mot sårbarhetsdata, og å gjøre det på nytt etter hvert som nye sårbarheter publiseres. Resultatet blir aldri bedre enn SBOM-en. CRACI registrerer SBOM-en mens bygget kjører, så listen gjenspeiler hva bygget faktisk hentet inn, inkludert pakker gjenopprettet fra CI-cacher.
Hvordan skiller sårbarhetssporing seg fra sårbarhetsskanning?
En skanning er et øyeblikksbilde: Den leser filer, rapporterer funn og stopper. Sporing tar vare på funnene, eierne og statusen over tid, og fortsetter å sjekke levert programvare etter hvert som nye sårbarheter dukker opp. CRACI er en registrator, ikke en skanner: Den registrerer hvert bygg og vurderer deretter de overvåkede SBOM-ene fortløpende på nytt.
Sporer CRACI sårbarheter i tredjepartsprogramvare?
Ja. Du kan legge til leverandørenes SBOM-er, og de innkjøpte komponentene overvåkes side om side med programvaren du bygger på CRACI.
Kan CRACI blokkere et bygg som inneholder en kjent sårbarhet?
Ja. Policy gates kan blokkere et bygg på grunn av funn, blant annet ethvert bygg som inneholder en bestemt CVE, så en sårbarhet du har rettet, ikke kommer tilbake i et senere bygg.
Hvordan varsler CRACI meg om sårbarheter?
Funn vises i CRACIs organisasjonsvisninger, der sikkerhetsteam triagerer dem og sender dem til teamene som eier dem. Varsler dekker i dag brudd på egress-policyen. Terskelvarsler og webhooks for sårbarheter er på veikartet, det samme er varsler i Slack og Teams.
Hjelper CRACI med sårbarhetsrapportering etter CRA?
Ja. CRACI sender inn CRA-sårbarhetsvarslene på dine vegne: det tidlige varselet, varslingen og sluttrapporten. Å oppfylle Cyber Resilience Act er fortsatt produsentens prosess; CRACI automatiserer en betydelig del av innsikten i forsyningskjeden og dokumentasjonen som den prosessen trenger.
Støtter CRACI VEX?
Ja. CRACI støtter VEX (Vulnerability Exploitability eXchange) for å registrere hvordan en kjent sårbarhet påvirker produktet ditt, sammen med triage og videresending til teamet som eier rettelsen. En VEX-erklæring forteller kunder og myndigheter om en sårbarhet som er matchet i SBOM-en din, faktisk påvirker produktet, så de ikke jager falske positiver. Book en demo for å se hvordan det passer inn i triageprosessen din.
Gjør CRACI reachability-analyse?
Nei. CRACI tilbyr ikke reachability-analyse. Den viser hvilke av byggene, repositoriene og produktene dine som inneholder en sårbar komponent, og støtter VEX for å registrere hvordan en sårbarhet påvirker produktet ditt.
Se sårbarhetssporing på dine egne bygg
Book en demo, så viser vi hvilke sårbarheter som når programvaren du leverer, og hvem som eier hver rettelse
Book en demo