Wat is ketenbeveiliging van software?

Wat is de softwareketen?

De softwareketen bestaat uit iedereen en alles wat betrokken is bij de weg van software van de editor van een ontwikkelaar naar productie. Zie die weg als vier fasen, elk met eigen risico's.

Fase	Wat erin zit	Wat er misgaat
Broncode	Uw code, repositories en accounts van ontwikkelaars	Gestolen inloggegevens, kwaadaardige commits, gelekte secrets
Afhankelijkheden	Open-sourcepakketten, base images, code van derden	Kwetsbare versies, kwaadaardige releases, typosquatting
Build	CI-runners, GitHub Actions, buildtools, caches	Gecompromitteerde actions, vergiftigde caches, gestolen pipeline-secrets
Release	Artefacten, registries, deployments, updates	Verwisselde artefacten, gemanipuleerde updates, geen record van wat is geleverd

Waarom het nu belangrijk is

Het meeste wat u levert, hebt u niet zelf geschreven. Een moderne applicatie is grotendeels open source, en elke directe afhankelijkheid brengt andere mee die niemand in uw team heeft gekozen. Die pakketten draaien met dezelfde toegang als uw eigen code, en hun installatiescripts kunnen in uw CI-pipeline draaien, naast uw secrets.

De afgelopen jaren laten zien hoe dat wordt uitgebuit:

• SolarWinds: de build was gecompromitteerd, waardoor schone broncode een vergiftigde release opleverde.
• Log4Shell: een fout in één logbibliotheek bereikte producten die niet wisten dat ze die gebruikten.
• xz utils: een vertrouwde bijdrager smokkelde een backdoor in een project dat in Linux-distributies voorkomt.
• tj-actions: een gekaapte GitHub Action voerde code van de aanvaller uit in de pipelines die hem gebruikten, met secrets binnen bereik.
• Shai-Hulud: een worm verspreidde zich via npm-pakketten en stal tokens van de machines en CI-jobs die ze installeerden.

Zie wat is een aanval op de softwareketen voor hoe deze aanvallen stap voor stap werken.

Hoe ketenbeveiliging van software werkt

Een programma heeft vier dingen nodig. De rest is detail.

1. Weet wat u levert. Bewaar voor elke release een nauwkeurige SBOM uit de build die de release heeft opgeleverd, inclusief transitieve afhankelijkheden.
2. Bepaal wat er binnenkomt. Pin versies vast, gebruik een lockfile, beperk waar builds iets mogen ophalen en beoordeel nieuwe pakketten.
3. Bescherm de build. Isoleer jobs, beperk secrets, pin actions vast op commit en beperk uitgaand verkeer, zodat een gecompromitteerd pakket uw tokens nergens naartoe kan sturen. Zie runnerbeveiliging en waarom ketenbeveiliging in CI thuishoort.
4. Blijf letten op wat is geleverd. Nieuwe kwetsbaarheden raken software die al in productie is. Monitor die, traceer welke releases zijn getroffen en volg elke oplossing tot aan een nieuwe release.

Zie voor de gedetailleerde checklist best practices voor ketenbeveiliging van software.

Kaders en regelgeving

Naam	Wat het is	Het meest geschikt voor
SLSA	Niveaus voor buildintegriteit en herkomst	Het harden van de manier waarop software wordt gebouwd
NIST SSDF	Werkwijzen voor veilige softwareontwikkeling, SP 800-218	Een volledig programma voor veilige ontwikkeling
NIST SP 800-161	Beheer van cyberrisico's in de toeleveringsketen	Organisatiebreed risicobeheer
OpenSSF Scorecard	Geautomatiseerde controles van de gezondheid van open-sourceprojecten	Afhankelijkheden beoordelen
Cyber Resilience Act	EU-wet voor producten met digitale elementen	Verkopen in de EU. Zie wat is de CRA

Welke tools komen erbij kijken?

Geen enkel product dekt dit allemaal. De categorie valt uiteen in SCA-tools, SBOM-tools, CI/CD- en runnerbeveiliging, package firewalls, application security posture management en binaire analyse. Wat elk daarvan doet en wie het verkoopt, leest u in tools voor ketenbeveiliging van software vergeleken en wat ze kosten.

Waar u begint

1. Genereer een SBOM voor uw belangrijkste product uit de CI-build, en lees hem.
2. Zet meldingen voor kwetsbaarheden in afhankelijkheden aan, en bepaal wie daarvoor verantwoordelijk is.
3. Pin uw GitHub Actions vast op commit en controleer welke secrets uw workflows kunnen bereiken.
4. Beperk uitgaand verkeer vanuit uw builds tot de hosts die ze echt nodig hebben.
5. Richt monitoring in voor wat u hebt geleverd, niet alleen voor wat u bouwt.

Hoe CRACI het aanpakt

CRACI begint bij de build, omdat de build de enige plek is die alles ziet. Het vervangt uw door GitHub gehoste runners door snellere, goedkopere runners die elk pakket vastleggen dat een job ophaalt, op elk niveau van de boom en inclusief pakketten die uit CI-caches zijn teruggezet. Het egressbeleid blokkeert verbindingen die uw build niet nodig heeft, en beschermt u zo zelfs tegen een aanval die nog niemand heeft gezien. Daarna blijft CRACI wat is geleverd toetsen aan nieuwe kwetsbaarheden en volgt het elke kwetsbaarheid van triage tot een gepatchte release. Zie ketenbeveiliging van software met CRACI.

Ketenbeveiliging van software: veelgestelde vragen

Wat is ketenbeveiliging van software?

Het is het beschermen van alles wat in uw software terechtkomt voordat die bij gebruikers aankomt: open-source afhankelijkheden, buildsystemen, pipelinetools en releases.

Wat is een voorbeeld van een aanval op de softwareketen?

Bij de SolarWinds-aanval was de build gecompromitteerd, waardoor klanten een vergiftigde update van een vertrouwde leverancier ontvingen. Bij de Shai-Hulud-aanvallen verspreidde een worm zich via npm-pakketten en stal hij tokens van de machines die ze installeerden.

Wat is het verschil tussen ketenbeveiliging en applicatiebeveiliging?

Applicatiebeveiliging kijkt naar fouten in de code die u schrijft. Ketenbeveiliging kijkt naar wat u niet hebt geschreven en naar hoe uw software wordt gebouwd en uitgebracht. Een programma heeft beide nodig.

Is een SBOM genoeg voor ketenbeveiliging?

Nee. Een SBOM vertelt u wat u levert, en dat is de basis. Daarnaast moet u bepalen wat er binnenkomt, de build beschermen en blijven monitoren wat u hebt uitgebracht.

Wat zijn de belangrijkste kaders?

SLSA voor buildintegriteit, het NIST SSDF voor veilige ontwikkelwerkwijzen en NIST SP 800-161 voor risicobeheer in de keten. In de EU stelt de Cyber Resilience Act wettelijke eisen aan producten met digitale elementen.

Wie is verantwoordelijk voor ketenbeveiliging van software?

Die verantwoordelijkheid ligt meestal bij applicatie- of productbeveiliging, in samenwerking met de platform- en DevOps-teams die de pipelines beheren. Oplossingen gaan vervolgens naar de engineeringteams die verantwoordelijk zijn voor elke service.