Software supply chain-security in 2026: SBOM's, SLSA en wat de Cyber Resilience Act nu eist

Het grootste deel van het afgelopen decennium betekende "applicatiebeveiliging" het scannen van de code die je team zelf schreef. Dat kader is nu de kleinere helft van het probleem. De code die je uitlevert is overweldigend code die je niet zelf hebt geschreven - transitieve open-source-afhankelijkheden, base images, build-plugins, CI-runners - en precies daar zijn aanvallers naartoe verschoven. Als je delivery leidt voor een gereguleerd Benelux-team, is software supply chain-security geen leuke bijkomstigheid van volwassenheid meer, maar een compliance-deadline met een datum erop. Dit is wat de termen echt betekenen, wat de EU op het punt staat te eisen, en waar het engineeringwerk landt.

CI/CD-pijplijndiagram met build-, test- en beveiligingsfasen waar SBOM-generatie en build-provenance ontstaan tussen commit en deployment

Waarom de software supply chain het aanvalsoppervlak werd

De dreiging is niet theoretisch en neemt niet af. Sonatype's tiende jaarlijkse State of the Software Supply Chain-rapport, gepubliceerd in januari 2026, vond meer dan 454.000 nieuwe kwaadaardige open-source-pakketten in 2025, waarmee het cumulatieve totaal aan bekende en geblokkeerde malware boven de 1,233 miljoen pakketten uitkwam - een stijging van 75% jaar op jaar in open-source-malware. In dezelfde periode haalden ontwikkelaars 9,8 biljoen open-source-downloads op via de vier grootste registries, een stijging van 67% (Sonatype, 2026). De twee cijfers samen vormen het hele verhaal: de consumptie explodeert, en aanvallers hebben het vergiftigen van de bron geïndustrialiseerd in plaats van een slot te forceren.

De faalmodus verschilt van een klassieke kwetsbaarheid. Een CVE in een library is een ongeluk dat je kunt patchen; een kwaadaardig pakket is een bewuste payload die in je build draaide op het moment dat een ontwikkelaar install typte. Typosquatting, dependency confusion en gecompromitteerde maintainer-accounts bereiken productie allemaal via dezelfde vertrouwde pijp die je elke dag gebruikt. Daarom is de branche gestopt met praten over "kwetsbare afhankelijkheden" en begonnen over supply chain-integriteit: de vraag is niet langer alleen "heeft deze component een bekend gebrek", maar "weet ik daadwerkelijk wat er in mijn software zit, en kan ik bewijzen hoe die is gebouwd."

Wat een SBOM is - en wat het je niet vertelt

Een Software Bill of Materials (SBOM) beantwoordt de eerste helft van die vraag. Het is een formele, machineleesbare inventaris van elke component in een softwareproduct - libraries, pakketten, versies, licenties en metadata - meestal uitgedrukt in een van de twee dominante formaten, SPDX of CycloneDX. Wanneer er een nieuwe kritieke kwetsbaarheid opduikt in een veelgebruikte library, zijn de organisaties die binnen uren "zijn we getroffen, en waar" kunnen beantwoorden degenen met actuele SBOM's. Degenen die handmatig door repositories grep-pen beantwoorden die vraag nog dagen later, wat tijdens een incident hetzelfde is als hem niet beantwoorden.

De valkuil is een SBOM behandelen als een compliance-artefact in plaats van een operationeel artefact. Een "papieren SBOM" die eenmalig bij release wordt gegenereerd en opgeborgen, is vrijwel waardeloos, omdat je afhankelijkheidsgraaf en de kwetsbaarheden daarin dagelijks veranderen. Een SBOM is alleen nuttig als hij bij elke build opnieuw wordt gegenereerd en continu wordt afgezet tegen kwetsbaarheids- en exploiteerbaarheidsdata. En hij heeft een harde grens: een SBOM vertelt je wat er in de doos zit, niet hoe de doos in elkaar is gezet. Hij kan je niet vertellen of de build zelf is gemanipuleerd - of het artefact in je registry werkelijk het artefact is dat je broncode heeft geproduceerd. Dat gat is wat de volgende maatregel dicht.

SBOM versus SLSA: bewijzen hoe de software is gebouwd

SLSA - Supply-chain Levels for Software Artifacts, uitgesproken als "salsa" - is een leveranciersonafhankelijk raamwerk, nu beheerd via de OpenSSF, dat build-integriteit aanpakt in plaats van componentinventaris. Waar een SBOM een lijst is, is SLSA een keten van bewaring. Het kernmechanisme is provenance: verifieerbare, manipulatiebestendige metadata die vastlegt hoe een artefact is gebouwd, vanuit welke bron, door welke builder, zodat een afnemer kan bevestigen dat de binary in productie werkelijk afkomstig is van de beoordeelde broncode en een ongemanipuleerde pijplijn (SLSA, OpenSSF).

SLSA is opgebouwd als progressieve build-niveaus in plaats van één lat om te halen:

Build L1 - provenance bestaat: het buildproces genereert een verslag van hoe het artefact is geproduceerd. Basaal, maar het maakt manipulatie in principe detecteerbaar.
Build L2 - provenance is ondertekend en gegenereerd door een gehoste build-service, zodat het niet triviaal op een laptop van een ontwikkelaar te vervalsen is.
Build L3 - het build-platform is gehard zodat provenance onvervalsbaar is en de build draait in een geïsoleerde, niet-manipuleerbare omgeving. Dit is het niveau dat betekenisvol verdedigt tegen een gecompromitteerd buildsysteem.

De praktische lezing voor een delivery-lead: SBOM en SLSA zijn complementair, niet concurrerend. De SBOM vertelt jou en je auditors wat er is uitgeleverd; SLSA-provenance laat een afnemer verifiëren dat wat is uitgeleverd, is gebouwd zoals je beweert. Volwassen programma's genereren beide vanuit dezelfde pijplijn, bij elke release, en behandelen een ontbrekende of niet-ondertekende provenance zoals ze een falende test behandelen - als een release-blokker, niet als een waarschuwing.

Wat de EU Cyber Resilience Act eist - en wanneer

Voor Benelux-teams is de reden dat dit nu een roadmap-item is in plaats van een onderzoeksonderwerp de EU Cyber Resilience Act (CRA). Die geldt voor vrijwel elk "product met digitale elementen" dat op de EU-markt wordt gebracht - hardware en software - en maakt van meerdere praktijken hierboven van goede hygiëne een wettelijke verplichting. De CRA trad op 10 december 2024 in werking, en de tijdlijn is gefaseerd (Europese Commissie):

11 september 2026 - de rapportageverplichtingen beginnen. Fabrikanten moeten actief misbruikte kwetsbaarheden en ernstige incidenten melden aan ENISA en nationale CSIRT's, met een vroegtijdige waarschuwing binnen 24 uur en een vervolg binnen 72 uur.
11 december 2027 - de hoofdverplichtingen gelden volledig: secure-by-design-eisen, kwetsbaarheidsbeheer gedurende de ondersteuningsperiode, conformiteitsbeoordeling, CE-markering en de plicht om beveiligingsupdates te leveren.

De SBOM is in dat regime vastgelegd. Onder de CRA moeten fabrikanten een software bill of materials opstellen en onderhouden die minimaal de top-level-afhankelijkheden van het product dekt, in een gangbaar machineleesbaar formaat zoals SPDX, CycloneDX of SWID. Hij hoeft niet gepubliceerd te worden, maar moet in de technische documentatie van het product zitten en op verzoek aan markttoezichtautoriteiten worden overhandigd (Anchore, EU CRA SBOM-overzicht). Als je product de EU-markt raakt, is "we zouden een SBOM kunnen produceren als daarom wordt gevraagd" geen verdedigbare positie meer; de machinerie moet al bestaan en continu draaien, want kwetsbaarheidsrapportage op een klok van 24 uur is onmogelijk zonder.

Hoe je dit in de pijplijn bouwt in plaats van het erop te schroeven

De teams die de CRA zonder drama zullen opvangen, zijn degenen die supply chain-security behandelen als pijplijn-loodgieterswerk, niet als een pre-audit-paniek. Vier bewegingen doen het meeste werk. Ten eerste, genereer de SBOM in CI bij elke build en bewaar hem als een eersteklas artefact naast de binary, zodat inventaris een bijproduct van uitleveren wordt in plaats van een apart project. Ten tweede, dwing curatie af bij de voordeur: geautomatiseerd beleid dat afhankelijkheden blokkeert die verdacht nieuw, niet-onderhouden of met incompatibele licenties zijn, stopt een groot deel van de kwaadaardige-pakketaanvallen voordat ze ooit in een build belanden. Ten derde, produceer ondertekende build-provenance en verifieer die bij deployment, opklimmend naar SLSA Build L3 op de pijplijnen die er het meest toe doen. Ten vierde, koppel SBOM-data aan exploiteerbaarheidscontext - VEX en reachability - zodat je team zijn uren besteedt aan de kwetsbaarheden die daadwerkelijk bereikbaar zijn in je product, niet aan een muur van ongedifferentieerde "high"-scores.

Niets hiervan is nog exotische tooling; de raamwerken zijn volwassen en de formaten zijn gestandaardiseerd. Wat het vergt is dezelfde discipline die elite-delivery onderscheidt van de rest - de maatregel één keer coderen, in het platform, zodat elk team hem erft in plaats van hem opnieuw uit te vinden. De CRA heeft simpelweg een datum gezet op wanneer die discipline niet langer optioneel is. September 2026 is de eerste van die data, en die is dichterbij dan een typische platformmigratie nodig heeft om te landen.