De meeste teksten over DevOps-security herhalen steeds dezelfde checklist: shift left, scan dingen, beheer secrets, monitor alles. De principes kloppen en zijn op zichzelf vrijwel nutteloos, want ze vertellen je niets over waar het risico zich werkelijk ophoopt, wat aanvallers dit jaar misbruiken, of welke van deze controls de cijfers verschuiven waar je board om geeft. Dit stuk houdt vast aan dezelfde DevSecOps-fundamenten die het oorspronkelijke artikel behandelde, maar onderbouwt elk daarvan met wat de industriedata van 2024 laat zien - zodat een engineering director die een grootschalig of gereguleerd landschap beheert, kan bepalen waar het volgende kwartaal aan besteed wordt, en niet alleen instemmend knikt.
Het dreigingsmodel is verschoven, en wel richting je pipeline
DevSecOps - security integreren in de DevOps-levenscyclus in plaats van het er na de ontwikkeling op te plakken - is geen nieuw advies. Wat veranderde, is de urgentie erachter. Verizon's 2024 Data Breach Investigations Report constateerde dat het misbruik van kwetsbaarheden als initiele toegangsvector jaar-op-jaar met 180% groeide, sterk gedreven door massaal misbruikte zero-days zoals MOVEit. De implicatie is direct: het venster tussen het publiek worden van een kwetsbaarheid en het op grote schaal misbruiken ervan is nu zo kort geworden dat periodieke, losse security-reviews het niet kunnen bijbenen. Het scannen en remedieren van kwetsbaarheden moet binnen de CI/CD-pipeline plaatsvinden, bij elke wijziging, want dat is het enige tempo dat aansluit op de dreiging.
Hetzelfde rapport is onomwonden over de tweede verschuiving. Betrokkenheid van de software-supplychain en van derden kwam voor in ongeveer 15% van de breaches, een sprong van 68% ten opzichte van het jaar ervoor. Je aanvalsoppervlak bestaat niet langer grotendeels uit je eigen code. Het is alles wat je build binnenhaalt.
Je dependency-graph is waar het risico werkelijk zit
Dit is het punt waar generiek advies het hardst faalt. "Scan je dependencies" klinkt als hygiene; de data zegt dat het de hoofdzaak is. Datadog's State of DevSecOps 2024, gebaseerd op tienduizenden applicaties en container images, vond dat 90% van de Java-services minstens een kritieke of high-severity kwetsbaarheid in een third-party-library draagt, tegenover een gemiddelde van 47% in andere talen. Belangrijker nog voor hoe je scant: 63% van die high- en kritieke Java-kwetsbaarheden komt uit indirecte, transitieve dependencies - de libraries die je libraries binnenhalen, die nooit in je eigen manifest verschijnen en die een naive first-party-scan volledig mist.
De operationele consequentie is specifiek. Software composition analysis moet de volledige transitieve boom resolven, en je moet de gebouwde container image scannen, niet alleen de bronrepository, want daar wordt de werkelijke runtime-dependencyset samengesteld. Als je security-testing stopt bij je eigen code en directe dependencies, kijk je naar een minderheid van je blootstelling.
Automatiseringsgaten, niet ontbrekende tools, zijn de zwakke schakel
De principes rond immutable infrastructure, security as code, secrets management en least-privilege-toegang worden doorgaans als beslecht beschouwd. De data zegt dat ze in de praktijk breed onbeslecht zijn. Datadog vond dat 38% van de organisaties die AWS gebruiken nog steeds gevoelige productieacties handmatig via de console uitvoerde - ClickOps - in plaats van via Infrastructure as Code. Handmatige productiewijzigingen zijn precies wat immutable infrastructure en reproduceerbare, reviewbare controls ondermijnt: ze creeren drift die geen enkele scanner kan zien en laten geen audit trail achter.
Met credentials is het hetzelfde verhaal. Slechts 37% van de GitHub Actions-gebruikers vertrouwde uitsluitend op kortlevende credentials; de overige 63% gebruikte nog steeds langlevende IAM-keys, het meest betrouwbare wat een aanvaller kan vinden in een gelekt secret of een gecompromitteerde build. Als je dit jaar een infrastructuurcontrol wilt prioriteren, haal CI/CD dan weg van langlevende credentials en zet het over op kortlevende, gefedereerde identiteit. Die ene wijziging neutraliseert een grote klasse aan supplychain- en secrets-blootstellingsincidenten.
Continue monitoring is een prioriteringsprobleem, geen volumeprobleem
De reflex zodra je scanning aanzet, is om elke kritieke CVE als brand te behandelen. Die reflex bedelft je team en remt je delivery. Datadog's data over aanvalsruis is opvallend: van tientallen miljoenen kwaadaardige requests van geautomatiseerde scanners triggerde slechts 0,0065% daadwerkelijk een kwetsbaarheid. De overgrote meerderheid van wat je raakt is onschadelijke achtergrondruis.
Dezelfde logica geldt voor je eigen backlog. Wanneer runtime-context wordt toegepast - is de kwetsbare code daadwerkelijk geladen, bereikbaar en blootgesteld - bleek dat 63% van de organisaties die kritieke CVE's leken te hebben, er geen meer overhield. Een scanner die duizend criticals rapporteert, geeft je geen securityhouding; hij geeft je een triageprobleem. Continue monitoring verdient zijn bestaan wanneer hij rangschikt op exploiteerbaarheid en bereikbaarheid, zodat engineers hun beperkte remediatietijd besteden aan de handvol issues die een aanvaller daadwerkelijk zou kunnen gebruiken.
Remediatiesnelheid is de metric die bewijst dat de pipeline werkt
Shift-left en incident response zijn makkelijk te claimen en moeilijk te verifieren. Er is een heldere metric voor de vraag of je pipeline de blootstelling werkelijk verkort: hoe snel je bekende, actief misbruikte kwetsbaarheden dicht. Verizon vond dat organisaties gemiddeld 55 dagen nodig hadden om de helft van de kritieke kwetsbaarheden op CISA's Known Exploited Vulnerabilities-catalogus te remedieren, en dat 8% een jaar na bekendmaking nog steeds ongepatcht was. De KEV-lijst is de subset die actief in het wild wordt misbruikt. Vijfenvijftig dagen om de helft daarvan te fixen is precies het gat dat een DevSecOps-pipeline bestaat om te dichten. Als je een cijfer wilt om je security-investering aan te sturen, volg dan de time-to-remediate voor KEV-vermelde issues en breng die omlaag; al het andere in dit artikel staat ten dienste daarvan.
Het nieuwe front: AI-ondersteunde delivery beveiligen
Een invalshoek waar het oorspronkelijke artikel volledig aan voorafgaat. Het 2024 DORA-rapport, gebaseerd op meer dan 39.000 respondenten, vond dat 75,9% van de teams nu AI in hun werk gebruikt, terwijl ongeveer 40% weinig tot geen vertrouwen heeft in AI-gegenereerde code - en AI heeft de neiging change-batches te vergroten, wat de change-failure-risk verhoogt. Grotere, snellere, minder vertrouwde changesets zijn precies de omstandigheden waaronder security-review wordt overgeslagen. AI-ondersteunde ontwikkeling neemt de noodzaak van de bovenstaande controls niet weg; het verhoogt juist de premie op het hebben ervan, geautomatiseerd en in de pipeline, want menselijke review schaalt niet mee met het nieuwe wijzigingsvolume.
Hoe het er goed uitziet
De teams die dit goed aanpakken delen een herkenbare vorm, en die sluit netjes aan op de fundamenten:
- Security gates draaien bij elke wijziging, in CI/CD. Dependency-, container- en secrets-scanning zijn pipeline-stadia, geen periodieke projecten - want een sprong van 180% in het misbruik van kwetsbaarheden wacht niet op je volgende reviewcyclus.
- Scanning resolvt de volledige transitieve boom en de gebouwde image. Met 63% van de kritieke Java-kwetsbaarheden verstopt in indirecte dependencies, mist alles daaronder het merendeel van de blootstelling.
- Productiewijzigingen lopen via Infrastructure as Code, op kortlevende credentials. Geen ClickOps, geen langlevende IAM-keys - de twee automatiseringsgaten die de data als meest voorkomend aanmerkt.
- Findings worden gerangschikt op runtime-bereikbaarheid, niet op ruwe aantallen. Engineers fixen wat exploiteerbaar is, en dat is een fractie van wat een scanner rapporteert.
- De remediatiesnelheid voor actief misbruikte kwetsbaarheden wordt gemeten en verbetert. Dat ene cijfer is de eerlijke toets of de pipeline werkt.
DevOps-security is geen aparte fase en is dat ook nooit geweest - maar het behandelen ervan als integraal onderdeel van de pipeline is nu een meetbare bedrijfsprioriteit, onderbouwd met harde cijfers, niet een slogan. DORA's diepteonderzoek naar security uit 2024 bestaat juist omdat supplychain-breaches de inzet verhoogden, en het wijst dezelfde kant op als de rest van de data: platform engineering en interne developer platforms kunnen security, compliance en governance afdwingen zonder developers af te remmen. Dat is het werk. Bij Expeditious Software bouwen we DevSecOps en platform engineering in het delivery platform zelf, zodat security iets is dat je pipeline als bijproduct van uitleveren voortbrengt, en niet iets dat je onder tijdsdruk reconstrueert. Wil je je huidige houding aftoetsen tegen deze cijfers, neem dan contact op met ons team.
