Er wordt een kritieke kwetsbaarheid gepubliceerd, het advies verspreidt zich, en binnen een uur vraagt iemand in de bedrijfschat: zijn wij getroffen? Log4Shell maakte die vraag beroemd. CVE-2021-44228 trof Log4j Core van 2.0-beta9 tot 2.15.0, een bibliotheek die enkele lagen diep in de afhankelijkheidsboom van talloze Java-producten zat, en de meeste teams moesten met veel moeite uitzoeken waar die zat.

De vraag klinkt eenvoudig. Eigenlijk zijn het er drie:

  1. Zit het kwetsbare component in iets wat we bouwen of leveren?
  2. Zo ja, kan het in ons product worden misbruikt?
  3. Sinds wanneer, en in welke releases?

De meeste processen beantwoorden de eerste twee. De derde is de vraag die klanten, auditors en toezichthouders daarna stellen, en die is achteraf het moeilijkst te beantwoorden.

Stap 1: Zoek uit of het component aanwezig is

Bedrijven komen meestal op een van vier manieren tot een antwoord, ruwweg op volgorde van volwassenheid.

Rondvragen en zoeken. Iemand plaatst een bericht in Slack, engineers doorzoeken hun repositories en lockfiles op de pakketnaam, en een spreadsheet verzamelt de antwoorden. Dit is nog steeds de meest gebruikte methode. Ze is traag, hangt af van wie antwoordt, en mist alles wat niet in een bestand is gedeclareerd: afhankelijkheden van afhankelijkheden, gevendorde bibliotheken, base images, tools die tijdens de build zijn geïnstalleerd.

De scannerdashboards bekijken. Afhankelijkheidsscanners markeren de CVE binnen enkele uren per repository. Dat is sneller, maar een scanner rapporteert over de code die vandaag voor hem ligt, meestal de standaardbranch. Hij vertelt u niet welke releases uw klanten draaien, of wat een build van drie maanden geleden werkelijk binnenhaalde.

Een SBOM-inventaris bevragen. Teams die voor elke release een software bill of materials bewaren, kunnen één vraag over al die releases stellen: welke producten en versies bevatten de getroffen versies van dit pakket? Dit is de eerste methode die antwoord geeft voor software die u hebt geleverd, niet alleen voor software in de repository.

Continu matchen. Als SBOM's worden gemonitord tegen kwetsbaarheidsgegevens, bestaat de lijst met getroffen producten al voordat iemand ernaar vraagt. De chatdraad begint dan met het antwoord in plaats van met de vraag.

De kwaliteit van elke methode hangt af van wat de inventaris werkelijk bevat. De gebruikelijke blinde vlekken zijn:

  • Transitieve afhankelijkheden. Het kwetsbare pakket is zelden een pakket dat u zelf hebt toegevoegd. Het komt drie of vier niveaus dieper binnen.
  • Alles wat het manifest niet declareert. Pakketten die zijn geïnstalleerd door buildscripts, npx-tools, Dockerfile-stappen, teruggezette caches en gevendorde C- en C++-code.
  • Oude releases. Een branch die niet meer bouwt, kan niet opnieuw worden gescand, maar het product dat eruit is gebouwd, kan nog in het veld staan.

Stap 2: Bepaal of het ertoe doet

Een component kan aanwezig zijn zonder een echt risico te vormen, dus de volgende stap is triage:

  • Versie en configuratie. Valt de versie precies binnen het getroffen bereik? Is de kwetsbare functie meegecompileerd en ingeschakeld?
  • Bereikbaarheid. Roept uw code de kwetsbare functie überhaupt aan?
  • Blootstelling. Is het component bereikbaar vanaf het netwerk of via onbetrouwbare invoer, of wordt het alleen tijdens de build gebruikt?
  • Mitigaties. Is er sandboxing, een netwerkbeperking of een configuratie die de exploit blokkeert?
  • Signalen van misbruik. CVSS geeft de ernst, EPSS schat de kans dat een CVE in de komende 30 dagen wordt misbruikt, en CISA's Known Exploited Vulnerabilities catalog somt de kwetsbaarheden op die al in het wild worden misbruikt. Samen bepalen ze waar eerst naar wordt gekeken.

Stap 3: Leg de beslissing vast

De uitkomst wordt per product en versie vastgelegd, steeds vaker als VEX-verklaring (Vulnerability Exploitability eXchange). CISA's minimumvereisten voor VEX definiëren vier statussen: not affected, affected, fixed en under investigation. Een verklaring "not affected" moet aangeven waarom, bijvoorbeeld omdat de kwetsbare code niet aanwezig is of niet door een aanvaller kan worden bereikt.

Dat record voedt alles wat volgt: de oplossing en de releases die die bevatten, het beveiligingsadvies voor klanten en elke melding die een toezichthouder verwacht. Onder de EU Cyber Resilience Act moet een fabrikant bijvoorbeeld binnen 24 uur nadat hij ervan op de hoogte is geraakt een vroegtijdige waarschuwing sturen over een actief misbruikte kwetsbaarheid in zijn product.

Stap 4: Bepaal het blootstellingsvenster

"Zijn wij getroffen?" heeft een tweede helft die vaak wordt overgeslagen: hoe lang waren wij getroffen?

De kwetsbaarheid bestond al lang voordat de CVE werd gepubliceerd. Log4Shell zat sinds 2.0-beta9 in Log4j, jaren voordat iemand het openbaar maakte. Uw blootstelling begon op de dag dat een build voor het eerst een kwetsbare versie binnenhaalde, en eindigde op de dag dat de laatste build met die versie werd vervangen. U hebt dat venster nodig om:

  • klanten te vertellen welke van hun releases zijn getroffen, niet alleen de nieuwste
  • een incidentonderzoek tot de juiste periode te beperken, als de kwetsbaarheid mogelijk is misbruikt
  • een auditor of toezichthouder te tonen wanneer het probleem in het product terechtkwam en wanneer de oplossing werd geleverd

Het scannen van de code van vandaag kan u dat niet geven. De huidige lockfile zegt wat de repository nu wil, niet wat elke eerdere build heeft geïnstalleerd. De enige betrouwbare bron is een record van elke build, vastgelegd terwijl die draaide en daarna bewaard.

Hoe CRACI het beantwoordt

CRACI draait uw GitHub Actions-jobs op eigen runners en legt elk pakket vast dat elke build daadwerkelijk binnenhaalt, direct en transitief, inclusief pakketten die door scripts zijn geïnstalleerd of uit caches zijn teruggezet. De SBOM van elke build wordt bewaard, dus de geschiedenis is er al als er een CVE wordt gepubliceerd.

Als er een nieuwe CVE binnenkomt, ligt het antwoord er al: elke eerdere build en de bijbehorende SBOM, welke daarvan de kwetsbare afhankelijkheid bevatten, direct of transitief, en de periode waarin u was getroffen. Geen spreadsheet, niet opnieuw scannen, niets reconstrueren uit lockfiles. De eerste build die het pakket bevatte en de build die het verwijderde, geven u het blootstellingsvenster, zo ver terug als uw bewaartermijn reikt (standaard 180 dagen, aangepaste bewaartermijn bij Enterprise).

Als u het eenmaal weet, kan een policy gate builds met deze CVE blokkeren, zodat een latere afhankelijkheidsupdate of een teruggezette cache de kwetsbare versie niet ongemerkt terugbrengt in een release.

Vanaf daar heeft de rest van het proces iets om op te steunen:

  • CRACI monitort de SBOM's continu, dus nieuwe CVE's worden aan uw builds getoetst zonder dat iemand erom vraagt.
  • Beveiligingsteams beoordelen bevindingen en sturen ze naar de teams die eigenaar zijn van de oplossing, en CRACI ondersteunt VEX om de uitkomst vast te leggen.
  • De inventaris van CRACI toont welke softwareversies op welke producten zijn uitgerold.
  • Voor de CRA dient CRACI namens u de vroegtijdige waarschuwing, de melding en het eindverslag in.

Boek een demo om de buildgeschiedenis van een van uw eigen repositories te zien.