Voor PSIRT-teams
CRACI voor PSIRT-teams en leiders in productbeveiliging
De eerste vraag in elke PSIRT-zaak is welke van onze producten en versies het kwetsbare component bevatten. CRACI beantwoordt die vraag vanuit een vastlegging van wat elke build werkelijk heeft opgehaald, en blijft dat doen zodra er nieuwe CVE's worden gepubliceerd.
Bijgewerkt op
Het probleem van een PSIRT-manager
Een hoofd productbeveiliging is verantwoordelijk voor antwoorden die het PSIRT niet alleen kan leveren. Wanneer er een CVE opduikt in een veelgebruikte bibliotheek, stellen klanten, bestuurders en in toenemende mate toezichthouders binnen enkele uren dezelfde vragen: zijn we getroffen, in welke producten en versies, sinds wanneer, en wanneer is het opgelost?
De antwoorden hangen af van de inventaris, en die komt meestal van scanners die achteraf lockfiles of manifests lezen. Ze vermelden ontwikkelafhankelijkheden die nooit worden geleverd en missen pakketten die de build op een andere manier heeft gedownload. Dus vraagt het PSIRT engineeringteams om het handmatig te controleren, en komt het antwoord na dagen, met voorbehouden.
Het FIRST PSIRT Services Framework noemt een inventaris van productcomponenten essentieel om snel de getroffen producten voor overgeërfde kwetsbaarheden te identificeren. Bij die inventaris begint CRACI. Zie voor het volledige beeld van de rol wat is een PSIRT.
Wat CRACI een PSIRT biedt
Een inventaris vastgelegd vanuit de build
CRACI draait uw GitHub Actions-builds op zijn eigen runners en legt de pakketten vast die elke job werkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit CI-caches zijn teruggezet en afhankelijkheden die in geen enkele lockfile staan. Het is een recorder, geen scanner. Elke SBOM heeft een volledigheidsstatus, dus een gedeeltelijke vastlegging wordt als gedeeltelijk gemarkeerd, en SBOM's worden geëxporteerd als CycloneDX of SPDX.
Continue monitoring van wat is geleverd
Gemonitorde SBOM's worden continu opnieuw beoordeeld zodra er nieuwe kwetsbaarheden worden gepubliceerd, en bevindingen worden samengebracht over builds en repositories heen. Een CVE die volgende maand wordt gepubliceerd, wordt gematcht met de releases die u al hebt geleverd, niet alleen met de volgende build. Bekende kwaadaardige releases met een gepubliceerde CVE worden gemarkeerd zoals elke andere kwetsbaarheid.
Getroffen producten, versies en periodes
De buildgeschiedenis toont elke eerdere build met zijn SBOM en welke builds een kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet in welke periode u was getroffen, binnen uw bewaartermijn. De inventarisweergave toont precies welke softwareversies in welke producten zijn uitgerold. Samen maken ze van "zijn we getroffen?" iets wat u kunt opzoeken.
Ingekochte componenten
Producten bestaan zelden alleen uit uw eigen code. U kunt SBOM's van leveranciers toevoegen, zodat componenten van derden naast uw eigen builds worden gemonitord.
Triage, routering en VEX
Securityteams triëren ontdekte kwetsbaarheden en sturen ze naar de teams die verantwoordelijk zijn voor de fix, wat past bij het gedistribueerde PSIRT-model waarin productteams het herstel doen. CRACI ondersteunt VEX. Zie VEX voor hoe verklaringen dat een product niet is getroffen een PSIRT en zijn klanten werk besparen.
Een opgeloste CVE uit latere builds houden
Policy gates kunnen een build blokkeren op bevindingen, ook builds die een specifieke CVE bevatten. Nadat een PSIRT-zaak is gesloten, voorkomt een gate op die CVE dat de kwetsbare versie ongemerkt terugkeert in een latere release.
Bewijs voor audits en klanten
De API levert SBOM's, netwerktraces en herkomstgegevens voor elke build, zodat de vastlegging achter een advisory of een auditantwoord ook buiten de interface beschikbaar is. Waar de EU Cyber Resilience Act van toepassing is, dient CRACI ook de vereiste meldingen namens de fabrikant bij de autoriteiten in; de verplichting blijft bij de fabrikant. Zie wat is de CRA.
Waar CRACI past in het PSIRT-proces
| PSIRT-fase | Wat CRACI bijdraagt |
|---|---|
| Voorbereiding | Een SBOM per build, vastgelegd terwijl hij draait, met een volledigheidsstatus |
| Ontdekking | Continue herbeoordeling van gemonitorde SBOM's, inclusief SBOM's van leveranciers |
| Verificatie | Welke builds, versies en producten het component bevatten, en sinds wanneer |
| Herstel | Triage naar het verantwoordelijke team; policy gates die de CVE uit latere builds houden |
| Release en openbaarmaking | Ondersteuning voor VEX; SBOM-export; API-toegang tot de buildvastlegging |
De fasen volgen de levenscyclus van kwetsbaarheidsbeheer.
Wat CRACI niet doet
- Reachability-analyse. CRACI laat zien dat een kwetsbaar pakket in de build zat, niet of uw code de kwetsbare functie aanroept.
- Scans van broncode. SAST en secrets-scans vallen buiten de scope; er zijn genoeg goede tools die dat naast CRACI doen.
- Andere CI-systemen dan GitHub Actions. Vandaag GitHub Actions; andere CI-systemen staan op de roadmap.
- Naleving namens u. CRACI levert het bewijs; voldoen aan NIS2, de CRA of een ander kader blijft het proces van uw organisatie.
CRACI voor PSIRT-teams: veelgestelde vragen
Is CRACI een PSIRT-tool?
CRACI dekt het deel van PSIRT-werk dat afhangt van weten wat u levert: SBOM's uit de build, continue monitoring daarvan, welke builds en producten een kwetsbaar component bevatten, en triage naar het verantwoordelijke team. Uw kanaal voor openbaarmaking en uw advisoryproces bouwen op die vastlegging voort.
Hoe weet CRACI wat er in een product zit?
Builds draaien op de GitHub Actions-runners van CRACI, en CRACI legt de pakketten vast die elke job werkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit CI-caches zijn teruggezet en afhankelijkheden die in geen enkele lockfile staan. Het is een recorder, geen scanner. Elke SBOM heeft een volledigheidsstatus, zodat u weet wanneer de vastlegging gedeeltelijk is.
Kan CRACI ons vertellen welke eerdere releases door een CVE zijn getroffen?
Ja, binnen uw bewaartermijn. De buildgeschiedenis toont elke eerdere build met zijn SBOM en welke builds een kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet in welke periode u was getroffen. De inventarisweergave toont welke softwareversies in welke producten zijn uitgerold.
Dekt CRACI componenten die we van leveranciers kopen?
U kunt SBOM's van leveranciers toevoegen, zodat ingekochte componenten naast uw eigen builds worden gemonitord.
Ondersteunt CRACI VEX?
Welke CI-systemen ondersteunt CRACI?
Vandaag GitHub Actions. Andere CI-systemen staan op de roadmap.
Zie de blootstelling van uw producten vanuit de build
Boek een demo met uw eigen GitHub Actions-builds: de SBOM's die CRACI vastlegt, de builds die een CVE heeft bereikt, en de triageweergave waarin uw PSIRT zou werken.
Demo boeken