Software veilig ontwikkelen wordt een stuk minder vrijblijvend. In 2027 treedt de EU Cyber Resilience Act (CRA) in werking. Best practices op het gebied van security worden dan wettelijke verplichtingen. Voor ontwikkelteams betekent dit dat ze nu in actie moeten komen om zich goed voor te bereiden.
Stel je deze situatie voor. Het is donderdagmiddag en het ontwikkelteam van een grote retailer ontvangt een kritieke security-update. Wat blijkt: een populair third-party component bevat een ernstige kwetsbaarheid. Het team heeft al vrij snel grip op de situatie, omdat de processen op orde zijn. Dankzij container signing en een actuele Software Bill of Materials (SBOM) is binnen enkele minuten duidelijk welke systemen geraakt zijn. Een uur later draaien alle systemen weer op veilige versies.
Dit voorbeeld laat zien hoe moderne softwareontwikkeling zou moeten werken. Vanaf eind 2027 wordt deze manier van werken een wettelijke verplichting.
De CRA verandert de spelregels fundamenteel. Deze wet is van toepassing op alle digitale producten op de EU-markt; van IoT-apparaten tot clouddiensten en applicaties. Fabrikanten moeten kunnen aantonen dat producten ‘secure by design’ zijn, wat inhoudt dat beveiliging centraal staat in het hele ontwikkelproces. Ook worden ze verplicht om minimaal vijf jaar ondersteuning te blijven bieden nadat een product van de markt wordt gehaald.
Deze eisen zijn bindend. Voor alle producten met een ‘digitaal element’ is CE-markering verplicht, anders mogen ze niet worden verkocht op de Europese markt. Softwareleveranciers moeten kunnen aantonen dat software voldoet aan de beveiligingseisen van de CRA en zijn verplicht om een conformiteitsaudit uit te voeren (door een externe partij als het gaat om risicovolle producten). Ernstige beveiligingsincidenten dienen binnen 24 uur te worden gemeld.
En de sancties liegen er niet om: boetes kunnen oplopen tot 15 miljoen euro, of 2,5% van de wereldwijde jaaromzet.
Je zou kunnen zeggen dat de CRA wettelijk vastlegt wat veel beveiligingsexperts al jaren hanteren als best practices. De verplichting om gratis updates te leveren, bijvoorbeeld, dwingt leveranciers om al in de ontwerpfase na te denken over langdurige security.
Voor ontwikkelteams die moeten kunnen aantonen dat hun software veilig is, is het belangrijk om exact te weten welke componenten worden gebruikt. Zoals ik onlangs al schreef, neemt het gebruik van third-party componenten in softwareontwikkeling toe. En dat is niet zonder risico’s. Als deze componenten niet goed worden beheerd, kun je hackers toegang geven tot je systemen of cryptominers ongemerkt op je servers laten draaien.
Na de invoering van de CRA is het niet meer vrijblijvend, maar verplicht om deze risico’s aan te pakken. Container signing biedt hier een oplossing voor, door een digitale handtekening toe te voegen aan container images. Daarmee garandeer je authenticiteit en integriteit. In het kader van de CRA wordt dit essentieel: je moet kunnen bewijzen dat software sinds validatie niet is aangepast. De combinatie van container signing en SBOM vormt daarmee de technische kern van CRA-compliance. Je weet wat je gebruikt én dat het betrouwbaar is.
De CRA wordt gefaseerd ingevoerd. Vanaf 11 september 2026 zijn leveranciers verplicht om meldingen te doen van kwetsbaarheden en ernstige incidenten. De wet wordt volledig ingevoerd op 11 december 2027, wat inhoudt dat leveranciers aan alle verplichtingen binnen de wet moeten voldoen.
Concrete stappen die je kunt nemen met je ontwikkelteam:
De deadline lijkt misschien nog ver weg, maar een transformatie als deze kost tijd. De CRA raakt niet alleen technologie, maar het hele ontwikkelproces. Het is dus belangrijk dat teams snappen waarom dit nodig is. Kies daarom ook in je ontwikkelteam voor een gefaseerde aanpak en start vandaag al met bewustwording.