Sårbarhedsopfølgning
Følg hver kendt sårbarhed i den software, du leverer, fra det build, der trak den ind, til den release, der rettede den. CRACI registrerer SBOM'en for hvert build, bliver ved med at tjekke den mod nye sårbarhedsdata og sender hvert fund til det team, der ejer rettelsen.
Hvad er sårbarhedsopfølgning?
Sårbarhedsopfølgning er den løbende registrering af hver kendt sårbarhed, der påvirker din software, fra opdagelsen, til den er rettet eller udelukket. For hver enkelt besvarer den fire spørgsmål: Hvor sidder den, hvilke produkter og releases indeholder den, hvem ejer rettelsen, og hvad er dens status?
Mange værktøjer besvarer det første spørgsmål ved at scanne manifest- og lockfiler bagefter og overlader resten til regneark og tickets. CRACI starter tidligere. Dine GitHub Actions-jobs kører på CRACI-runnere, og mens de kører, registrerer CRACI hver pakke, buildet faktisk hentede, inklusive pakker gendannet fra CI-caches. Den build-time SBOM er det, CRACI overvåger, så de sårbarheder, du følger, er dem i det artefakt, du leverede, ikke i en scanning, der kørte et sted i nærheden.
Opfølgning på den software, du leverer, ikke kun dine IT-aktiver
De fleste værktøjer til sårbarhedsopfølgning er bygget til IT: De scanner servere, bærbare og cloudkonti, og rettelsen er en patch, som nogen installerer. Software, du bygger og sælger, kræver en anden slags registrering. Den sårbare kode ligger i din release, rettelsen er et nyt build, og kunder og myndigheder spørger, hvilke versioner der var berørt, og hvor længe.
Det er den registrering, CRACI fører: SBOM'en for hvert build, de produkter og versioner, det blev udrullet på, de leverandørkomponenter, du har købt ind, og status for hver sårbarhed på tværs af dem alle.
Løbende genvurdering af det, du har leveret
CRACI registrerer SBOM'en, mens hvert build kører, og genvurderer derefter løbende overvågede SBOM'er mod sårbarhedsdata. En sårbarhed, der offentliggøres længe efter en release, dukker stadig op på den release, den rammer, uden at nogen skal køre en scanning igen.
Ét overblik på tværs af builds og repositories
Fund samles på tværs af builds og repositories med organisationsvisninger på standardbranchen. Inventarvisningen viser præcis, hvilke softwareversioner der er udrullet på hvilke produkter, og build-historikken viser, hvilke tidligere builds der indeholdt en sårbar afhængighed, så du ved, hvilke produkter der var berørt, og hvor længe.
Triage og videresendelse til det ansvarlige team
Sikkerhedsteams triagerer fundne sårbarheder og sender dem til de teams, der ejer rettelsen, så hvert fund når frem til dem, der kan handle på det. CRACI understøtter også VEX til at registrere, hvordan en sårbarhed påvirker dit produkt, og policy gates kan blokere ethvert build, der indeholder en bestemt CVE.
Leverandørers SBOM'er overvåget ved siden af dine egne
Tilføj SBOM'er fra dine leverandører, så overvåges indkøbte komponenter side om side med den software, du bygger. Tredjepartskode i dit produkt følges samme sted som dine egne afhængigheder.
Fra fund til CRA-underretning
Til Cyber Resilience Act indsender CRACI sårbarhedsunderretningerne på dine vegne: den tidlige varsling, underretningen og den endelige rapport. SBOM'er eksporteres som CycloneDX eller SPDX med de sårbarheder, der er fundet i komponenterne, til audits, kunder og dine egne optegnelser.
Hver sårbar pakke, og hvad der trækker den ind
Hvert build viser sine pakker med version, package URL, licens og sårbarhedsstatus og viser, om dets SBOM er komplet. Åbn en pakke for at se dens advisories med alvorlighed og de pakker, der kræver den.
Livscyklussen for sårbarhedsopfølgning i CRACI
- Find. Hvert build producerer en SBOM med en fuldstændighedsstatus, eksporteret som CycloneDX eller SPDX med transitive afhængigheder. Overvågede SBOM'er, dine egne og dine leverandørers, genvurderes løbende mod sårbarhedsdata.
- Lokalisér. Organisationsvisninger på tværs af builds og repositories, inventarvisningen og build-historikken viser, hvilke produkter og versioner der er berørt, og siden hvornår.
- Prioritér og triagér. Hver advisory viser sin alvorlighed. Sikkerhedsteams triagerer hvert fund med VEX-understøttelse til at registrere, hvordan en sårbarhed påvirker dit produkt.
- Afhjælp. Hvert fund går til det team, der ejer rettelsen, og "Required by" viser, hvilken pakke der trækker en transitiv sårbarhed ind. Policy gates kan holde en bestemt CVE ude af senere builds.
- Verificér. SBOM'en for det næste build viser, om den sårbare version er væk, så registreringen løber helt frem til den rettede release.
- Rapportér. CRACI indsender CRA-sårbarhedsunderretninger på dine vegne, og SBOM'er eksporteres med de sårbarheder, der er fundet i komponenterne.
Hvad du skal registrere for hver sårbarhed
- Sårbarhed
- Advisoryen og dens ID'er (CVE, GHSA og andre) med alvorlighed.
- Komponent
- Pakken og den præcise version, og om det er en direkte eller transitiv afhængighed.
- Sti
- De pakker, der trækker den sårbare ind, hvilket fortæller dig, hvad der skal opgraderes.
- Eksponering
- Hvilke produkter, releases og builds der indeholder den, og siden hvornår.
- Ejer
- Det team, der er ansvarligt for rettelsen.
- Status
- Åben, under undersøgelse, ikke berørt eller rettet, helst registreret som VEX.
- Dokumentation
- Det build eller den release, der ikke længere indeholder den sårbare version.
Nøgletal, der viser, om opfølgningen virker
Sikkerhedsteams rapporterer som regel på fire tal:
- Gennemsnitlig tid til afhjælpning (MTTR): hvor lang tid der går, fra en sårbarhed findes, til der er en release uden den.
- Overholdelse af afhjælpningsfrister: andelen af sårbarheder, der rettes inden for den frist, din politik fastsætter for deres alvorlighed.
- Udvikling i efterslæbet: om antallet af åbne sårbarheder stiger eller falder.
- Eksponeringsvindue: hvor længe hvert produkt blev leveret med en sårbar version. CRACI's build-historik viser, hvilke builds der indeholdt en sårbar afhængighed, så du ved, i hvilken periode du var berørt.
Hvad CRACI ikke gør i dag
CRACI tilbyder ikke reachability-analyse og rangerer derfor ikke fund efter, om din kode kalder den sårbare funktion. CRACI viser ikke afhjælpningsnøgletal som MTTR, overholdelse af frister eller udviklingen i efterslæbet. CRACI sender i dag ikke alarmer ud fra en alvorlighedstærskel, og alarmerne dækker brud på egress-politikken. Kommentarer på fund, en diff mellem releases, tærskelalarmer og webhooks for sårbarheder er på roadmappen.
VEX: hvilke sårbarheder der faktisk påvirker dit produkt
En sårbar komponent i din SBOM betyder ikke altid et sårbart produkt. Den berørte kode er måske ikke med i det, du leverer, eller kan måske ikke nås på den måde, et angreb kræver. VEX (Vulnerability Exploitability eXchange) er en maskinlæsbar måde at sige det på: Hver VEX-erklæring forbinder et produkt, en sårbarhed og en status. Standardstatusserne er not affected, affected, fixed og under investigation.
Det får betydning, når kunder og myndigheder tjekker dine SBOM'er mod sårbarhedsdatabaser. Uden en VEX-erklæring ligner hvert match et åbent problem, og dit team ender med at forklare de samme falske positiver igen og igen. CRACI understøtter VEX til at registrere, hvordan en sårbarhed påvirker dit produkt, sammen med den triage, der sender hvert fund til det team, der ejer rettelsen.
Nysgerrig efter, hvor meget der er at holde trit med? Se hvor mange CVE'er der offentliggøres hver dag, og hvordan mængden af High- og Critical-sårbarheder er vokset.
Sårbarhedsopfølgning forklaret
Almindelige spørgsmål om opfølgning på sårbarheder i den software, du bygger og køber
Hvad er sårbarhedsopfølgning?
Sårbarhedsopfølgning er den løbende registrering af hver kendt sårbarhed, der påvirker din software, fra det øjeblik den findes, til den er rettet eller udelukket: hvilken komponent og version den sidder i, hvilke produkter og releases der indeholder den, hvem der ejer rettelsen, og hvad dens status er. For software, du leverer, starter den med en præcis liste over komponenter, og det er det, en SBOM giver.
Hvad er trinene i sårbarhedsstyring?
Den sædvanlige cyklus har fem trin: find sårbarhederne i det, du kører eller leverer, prioritér dem, afhjælp dem, verificér, at rettelsen fjernede dem, og rapportér. Opfølgningen er det, der binder trinene sammen, så et fund ikke går tabt mellem opdagelse og en rettet release. I CRACI består trinene i at registrere build-time SBOM'en, triagere hvert fund, sende det til det ansvarlige team, bekræfte, at et senere build ikke længere indeholder den sårbare version, og rapportere via SBOM-eksporter og CRA-underretninger.
Hvordan følger man op på afhjælpning af sårbarheder?
Giv hver sårbarhed en ejer og en status, og luk den først, når et build eller en release ikke længere indeholder den sårbare version. Mål, hvor lang tid rettelserne tager, om de overholder dine frister, og om efterslæbet af åbne sårbarheder bliver mindre. I CRACI viser hvert builds SBOM, om den sårbare version stadig er der, og en policy gate kan holde en bestemt CVE ude af senere builds.
Hvad er SBOM-baseret sårbarhedsstyring?
SBOM-baseret sårbarhedsstyring betyder, at komponenterne i dine softwarestyklister matches mod sårbarhedsdata, og at det gøres igen, efterhånden som nye sårbarheder offentliggøres. Resultatet er aldrig bedre end SBOM'en. CRACI registrerer SBOM'en, mens buildet kører, så listen afspejler, hvad buildet faktisk hentede, inklusive pakker gendannet fra CI-caches.
Hvordan adskiller sårbarhedsopfølgning sig fra sårbarhedsscanning?
En scanning er et øjebliksbillede: Den læser filer, rapporterer fund og stopper. Opfølgning bevarer fundene, deres ejere og deres status over tid og bliver ved med at tjekke leveret software, efterhånden som nye sårbarheder dukker op. CRACI registrerer, den scanner ikke: Den registrerer hvert build og genvurderer derefter løbende de overvågede SBOM'er.
Følger CRACI op på sårbarheder i tredjepartssoftware?
Ja. Du kan tilføje leverandørers SBOM'er, og de indkøbte komponenter overvåges side om side med den software, du bygger på CRACI.
Kan CRACI blokere et build, der indeholder en kendt sårbarhed?
Ja. Policy gates kan blokere et build på grund af fund, herunder ethvert build, der indeholder en bestemt CVE, så en sårbarhed, du har rettet, ikke vender tilbage i et senere build.
Hvordan giver CRACI mig besked om sårbarheder?
Fund vises i CRACI's organisationsvisninger, hvor sikkerhedsteams triagerer dem og sender dem til de ansvarlige teams. Alarmer dækker i dag brud på egress-politikken. Tærskelalarmer og webhooks for sårbarheder er på roadmappen, ligesom alarmer i Slack og Teams.
Hjælper CRACI med sårbarhedsrapportering under CRA?
Ja. CRACI indsender CRA-sårbarhedsunderretningerne på dine vegne: den tidlige varsling, underretningen og den endelige rapport. At opfylde Cyber Resilience Act er fortsat producentens proces; CRACI automatiserer en væsentlig del af det overblik over og den dokumentation for forsyningskæden, som processen kræver.
Understøtter CRACI VEX?
Ja. CRACI understøtter VEX (Vulnerability Exploitability eXchange) til at registrere, hvordan en kendt sårbarhed påvirker dit produkt, sammen med triage og videresendelse til det team, der ejer rettelsen. En VEX-erklæring fortæller kunder og myndigheder, om en sårbarhed, der matches i din SBOM, faktisk påvirker produktet, så de ikke jagter falske positiver. Book en demo for at se, hvordan det passer ind i din triageproces.
Laver CRACI reachability-analyse?
Nej. CRACI tilbyder ikke reachability-analyse. CRACI viser, hvilke af dine builds, repositories og produkter der indeholder en sårbar komponent, og understøtter VEX til at registrere, hvordan en sårbarhed påvirker dit produkt.
Se sårbarhedsopfølgning på dine egne builds
Book en demo, så viser vi, hvilke sårbarheder der når den software, du leverer, og hvem der ejer hver rettelse
Book en demo