De wake-up call van december 2021
De Log4Shell-kwetsbaarheid (CVE-2021-44228) in december 2021 was een keerpunt. Een kritieke kwetsbaarheid in een alomtegenwoordige Java-loggingbibliotheek legde wereldwijd systemen bloot. Het kostte organisaties dagen tot weken om uberhaupt te inventariseren of ze geraakt waren.
De les was pijnlijk helder: we weten onvoldoende wat er in onze software zit. En dat is een probleem dat we als ontwikkelaars moeten oplossen.
Het probleem van transitieve afhankelijkheden
De gemiddelde .NET-applicatie heeft tientallen directe NuGet-packages en honderden transitieve afhankelijkheden. Elk van die packages is een potentieel aanvalsvector. Het gaat niet alleen om de packages die je bewust toevoegt, maar ook om de packages die die packages binnenhalen.
Bij Log4j was precies dat het probleem: veel organisaties gebruikten Log4j niet direct, maar het zat diep in hun dependency tree verborgen. Ze wisten niet eens dat het er was.
Software Bill of Materials (SBOM)
Een SBOM is een gestructureerde lijst van alle componenten in je software, inclusief versies en licenties. Denk aan een ingredientenlijst voor je applicatie. Het klinkt basaal, maar de realiteit is dat de meeste teams dit niet op orde hebben.
Standaarden als CycloneDX en SPDX maken het mogelijk om SBOM's machineleesbaar te genereren. In het .NET-ecosysteem kun je tools als dotnet CycloneDX gebruiken om automatisch een SBOM te genereren vanuit je projectbestanden.
Het echte voordeel van een SBOM komt bij incidenten: wanneer de volgende Log4j-achtige kwetsbaarheid opduikt, kun je binnen minuten vaststellen welke applicaties geraakt zijn.
Concrete stappen voor je team
1. Inventariseer je afhankelijkheden. Genereer een SBOM voor al je applicaties. Automatiseer dit als onderdeel van je build pipeline. Sla de SBOM op als build-artifact.
2. Scan continu op kwetsbaarheden. Gebruik tools als Dependabot, Snyk of OWASP Dependency-Check om je dependencies te scannen. Niet eenmalig, maar bij elke build en op een vaste frequentie voor gedeployde applicaties.
3. Pin je versies. Gebruik exacte versienummers in plaats van floating ranges. In .NET betekent dat geen wildcard-versies in je .csproj. Dit voorkomt dat een compromised package automatisch je build binnenkomt.
4. Verifieer package-integriteit. NuGet ondersteunt package signing. Schakel signature validation in. Overweeg een private NuGet-feed als extra beveiligingslaag waar je packages expliciet moet goedkeuren.
5. Minimaliseer je dependencies. Elke dependency is een risico. Vraag je bij elke nieuwe package af: heb ik dit echt nodig, of kan ik dit zelf in twintig regels code oplossen? Minder dependencies betekent minder aanvalsvlak.
6. Houd een response-plan klaar. Wanneer de volgende kritieke kwetsbaarheid verschijnt, wil je niet improviseren. Zorg dat je weet hoe je snel kunt vaststellen welke applicaties geraakt zijn, hoe je patches uitrolt, en wie welke verantwoordelijkheid heeft.
Het grotere plaatje
Supply chain security is niet alleen een technisch probleem. Het raakt aan hoe je als organisatie omgaat met risico. Het vereist samenwerking tussen ontwikkelaars, operations en security. De tooling bestaat; het gaat erom dat je het structureel inricht.
NForza en supply chain security
Bij NForza nemen we de veiligheid van de software supply chain serieus. We helpen organisaties om hun dependency management op orde te brengen, SBOM-generatie te automatiseren en kwetsbaarheden proactief te detecteren. De lessen van Log4j moeten leiden tot structurele verbeteringen, niet tot eenmalige brandoefeningen.