Code security means finding, fixing and preventing security flaws before software reaches production. It covers the code you write, the open-source parts you reuse, and the files that describe your servers and containers. Four places flaws hide, and how to tell which ones matter. Codebeveiliging betekent beveiligingsfouten vinden, herstellen en voorkomen voordat software in productie gaat. Het gaat om de code die u zelf schrijft, de open-sourceonderdelen die u hergebruikt, en de bestanden die uw servers en containers beschrijven. Vier plekken waar fouten zitten, en hoe u ziet welke ertoe doen.
Every application has flaws its developers did not intend. OWASP lists the most common ones in its Top 10:2025, and broken access control is number one: the software forgets to check whether you may see what you ask for. Automated code scanning is good at known patterns, such as text from a web form pasted straight into a database query. It is poor at business logic. It cannot know that invoice 1043 belongs to another customer.
Business impact: a missing access check leaks customer data quietly, through normal-looking requests, and no scanner warns you. We suggest two layers: scanning on every change for the known patterns, and a human review of any code that decides who may see or change what.
Elke applicatie bevat fouten die de ontwikkelaars niet bedoelden. OWASP zet de meest voorkomende op een rij in de Top 10:2025, en gebrekkige toegangscontrole staat op één: de software vergeet te controleren of u mag zien wat u opvraagt. Geautomatiseerde codescans zijn goed in bekende patronen, zoals tekst uit een webformulier die rechtstreeks in een databasevraag belandt. In bedrijfslogica zijn ze zwak. Een scanner weet niet dat factuur 1043 van een andere klant is.
Bedrijfsimpact: een ontbrekende toegangscontrole lekt klantgegevens stil, via normaal ogende verzoeken, en geen scanner waarschuwt u. Wij raden twee lagen aan: scans bij elke wijziging voor de bekende patronen, en een menselijke review van alle code die bepaalt wie wat mag zien of wijzigen.
AI tools help an attacker study a public application, guess where an access check is missing, and try many variations of a request automatically.AI-tools helpen een aanvaller een openbare applicatie te bestuderen, te raden waar een toegangscontrole ontbreekt en automatisch veel varianten van een verzoek te proberen.
AI coding assistants write working code fast, and working is not the same as safe. Generated code can skip an access check as easily as a rushed developer can.AI-codeerassistenten schrijven snel werkende code, en werkend is niet hetzelfde als veilig. Gegenereerde code kan een toegangscontrole net zo makkelijk overslaan als een ontwikkelaar met haast.
AI-assisted review can read each change for logic flaws, not just patterns, and explain the finding to the developer. A person still approves code that guards money or personal data.AI-ondersteunde review kan elke wijziging lezen op logicafouten, niet alleen op patronen, en de bevinding aan de ontwikkelaar uitleggen. Code die geld of persoonsgegevens bewaakt, keurt nog steeds een mens goed.
Modern software is assembled. Your developers write the part that makes it yours and reuse open-source components for the rest: logging, web frameworks, file readers. When a flaw in one of those components is published, every application that ships the old version has it too, including yours. Dependency scanning compares the list of components in each release, its SBOM, with public vulnerability databases.
Business impact: once a flaw is public, attackers can search for every system running that version. You cannot fix what you do not know you ship. This step is about honest components with known holes; packages that are malicious on purpose are covered in the supply chain briefing.
Moderne software wordt samengesteld. Uw ontwikkelaars schrijven het deel dat het van u maakt en hergebruiken open-sourceonderdelen voor de rest: logging, webframeworks, bestandslezers. Wordt een fout in zo'n onderdeel gepubliceerd, dan heeft elke applicatie met de oude versie die fout ook, de uwe inbegrepen. Afhankelijkheidsscans vergelijken de lijst met onderdelen van elke release, de SBOM, met openbare kwetsbaarheidsdatabases.
Bedrijfsimpact: zodra een fout openbaar is, kunnen aanvallers zoeken naar elk systeem met die versie. U kunt niet herstellen waarvan u niet weet dat u het levert. Deze stap gaat over eerlijke onderdelen met bekende gaten; pakketten die bewust kwaadaardig zijn, staan in de briefing over de toeleveringsketen.
When a fixed version of a component is published, AI tools can help an attacker compare old and new code and work out the flaw faster than before.Zodra een herstelde versie van een onderdeel verschijnt, kunnen AI-tools een aanvaller helpen oude en nieuwe code te vergelijken en de fout sneller dan vroeger te achterhalen.
AI assistants suggest components and versions from what they learned, which can be an old version with a known flaw. The suggestion sounds just as confident either way.AI-assistenten stellen onderdelen en versies voor op basis van wat ze leerden, en dat kan een oude versie met een bekende fout zijn. Het voorstel klinkt in beide gevallen even zeker.
AI tools can propose the upgrade and adjust the code that calls the component, so staying current costs less effort. Tests and a review still decide whether it ships.AI-tools kunnen de upgrade voorstellen en de code aanpassen die het onderdeel aanroept, zodat bijblijven minder moeite kost. Tests en een review beslissen nog steeds of het live gaat.
Servers, networks and storage are now often described in text files, infrastructure as code, and software is packed into container images. That makes them code too. One line that opens a storage bucket to the internet is copied to every environment built from that template. An image built two years ago still carries the operating-system libraries of two years ago. OWASP ranks security misconfiguration second in its Top 10:2025.
Business impact: one wrong setting becomes the default everywhere, and an old image brings old holes into new deployments. We suggest scanning templates and images before they are deployed, and rebuilding images on a schedule, not only when the application changes.
Servers, netwerken en opslag worden tegenwoordig vaak in tekstbestanden beschreven, infrastructure as code, en software wordt verpakt in containerimages. Daarmee is dat ook code. Eén regel die een opslagbucket voor internet openzet, wordt gekopieerd naar elke omgeving die met dat sjabloon wordt gebouwd. Een image van twee jaar geleden bevat nog de besturingssysteembibliotheken van twee jaar geleden. OWASP zet verkeerde beveiligingsconfiguratie op twee in de Top 10:2025.
Bedrijfsimpact: één verkeerde instelling wordt overal de standaard, en een oud image brengt oude gaten mee in nieuwe uitrol. Wij raden aan sjablonen en images te scannen vóór de uitrol, en images volgens schema opnieuw te bouwen, niet alleen als de applicatie verandert.
Bots already sweep the internet for open storage and exposed services. AI helps them recognise what they found and what it is worth.Bots doorzoeken het internet al naar open opslag en blootgestelde diensten. AI helpt ze herkennen wat ze vonden en wat het waard is.
AI assistants write templates in seconds, often with permissive example settings that make it work first time. Copied into production, the shortcut becomes the standard.AI-assistenten schrijven sjablonen in seconden, vaak met ruime voorbeeldinstellingen zodat het meteen werkt. Eenmaal naar productie gekopieerd wordt die snelkoppeling de standaard.
Policy checks, increasingly AI-assisted, read every template and image before deployment and explain why a setting is risky. The block itself stays a simple, agreed rule.Beleidscontroles, steeds vaker AI-ondersteund, lezen elk sjabloon en image vóór de uitrol en leggen uit waarom een instelling riskant is. De blokkade zelf blijft een eenvoudige, afgesproken regel.
Scanners report every known flaw in every component, whether or not your software ever uses the flawed part. Teams get a list longer than they can fix, and sorting by severity score alone keeps it long. Three questions shrink it. Is the flawed code reachable in what we run? Is it being exploited now, according to the KEV catalogue? How likely is exploitation soon, according to EPSS? Suppliers can answer the first question for their product with a VEX statement.
Business impact: the flaw that is exploited today waits in the same queue as many that never will be. We suggest triage on reachability and active exploitation first. Ask for one number instead of the total: known-exploited flaws that are reachable in production, and how long each has been open.
Scanners melden elke bekende fout in elk onderdeel, of uw software het foute deel nu gebruikt of niet. Teams krijgen een lijst die langer is dan ze kunnen herstellen, en sorteren op alleen een ernstscore houdt die lang. Drie vragen maken hem korter. Is de foute code bereikbaar in wat wij draaien? Wordt hij nu misbruikt, volgens de KEV-catalogus? Hoe waarschijnlijk is misbruik binnenkort, volgens EPSS? Leveranciers kunnen de eerste vraag voor hun product beantwoorden met een VEX-verklaring.
Bedrijfsimpact: de fout die vandaag wordt misbruikt, staat in dezelfde rij als vele die dat nooit worden. Wij raden aan eerst te sorteren op bereikbaarheid en actief misbruik. Vraag om één getal in plaats van het totaal: bekende misbruikte fouten die in productie bereikbaar zijn, en hoe lang elk al openstaat.
AI can shorten the time from a published flaw to a working attack, so the window to act on what is actively exploited gets smaller.AI kan de tijd tussen een gepubliceerde fout en een werkende aanval verkorten, waardoor de tijd om te handelen op wat actief wordt misbruikt kleiner wordt.
AI triage tools can label a finding "not reachable" with confidence and be wrong. A dismissed finding that nobody re-checks is a blind spot with a sign-off.AI-triagetools kunnen een bevinding vol overtuiging "niet bereikbaar" noemen en zich vergissen. Een weggezette bevinding die niemand opnieuw bekijkt, is een blinde vlek met een handtekening.
AI can check reachability across a large codebase, combine it with KEV and EPSS, and group findings by the one upgrade that fixes them. People keep the decision on what waits.AI kan bereikbaarheid in een grote codebase nagaan, dat combineren met KEV en EPSS, en bevindingen bundelen per upgrade die ze oplost. Mensen houden de beslissing over wat mag wachten.
| Control | Helps with | In one line |
|---|---|---|
| Code scanning | Own code (01) | Known risky patterns are flagged on every change. Findings above an agreed severity block the release. |
| Access-logic review | Own code (01) | A second person reads any change that decides who may see or change what. Scanners don't. |
| Dependency scanning + SBOM | Open source (02) | Each release has an SBOM, and new vulnerability reports are matched against it every day, not only at build time. |
| Template and image checks | Configuration (03) | Infrastructure templates and container images are scanned before deployment, with a short list of settings that always block. |
| Scheduled rebuilds | Configuration (03) | Images are rebuilt from an updated base on a fixed rhythm, even when the application did not change. |
| Exploited-first triage | Findings (04) | Reachable flaws on the KEV list go first, then high EPSS scores, then the rest by severity. |
| VEX from suppliers | Findings (04) | Ask suppliers for VEX statements, so you don't chase flaws in parts their product doesn't use. |
| Pentest | All four | An independent test finds what the tools missed, especially in business logic. |
| Maatregel | Helpt bij | In één zin |
|---|---|---|
| Codescans | Eigen code (01) | Bekende riskante patronen worden bij elke wijziging gemarkeerd. Bevindingen boven een afgesproken ernst blokkeren de release. |
| Review van toegangslogica | Eigen code (01) | Een tweede persoon leest elke wijziging die bepaalt wie wat mag zien of wijzigen. Scanners doen dat niet. |
| Afhankelijkheidsscans + SBOM | Open source (02) | Elke release heeft een SBOM, en nieuwe kwetsbaarheidsmeldingen worden er elke dag tegen gelegd, niet alleen bij het bouwen. |
| Sjabloon- en imagecontroles | Configuratie (03) | Infrastructuursjablonen en containerimages worden vóór de uitrol gescand, met een korte lijst instellingen die altijd blokkeren. |
| Herbouwen volgens schema | Configuratie (03) | Images worden in een vast ritme opnieuw gebouwd op een bijgewerkte basis, ook als de applicatie niet veranderde. |
| Triage: misbruikt eerst | Bevindingen (04) | Bereikbare fouten op de KEV-lijst gaan voor, dan hoge EPSS-scores, dan de rest op ernst. |
| VEX van leveranciers | Bevindingen (04) | Vraag leveranciers om VEX-verklaringen, zodat u geen fouten najaagt in delen die hun product niet gebruikt. |
| Pentest | Alle vier | Een onafhankelijke test vindt wat de tools misten, vooral in bedrijfslogica. |
Business software routinely reuses open-source components, and new flaws in them are published all the time. Every codebase has some.Bedrijfssoftware hergebruikt routinematig open-sourceonderdelen, en er worden voortdurend nieuwe fouten in gepubliceerd. Elke codebase heeft er een paar.
Customer data exposed through a missing check or a known flaw, or one public misconfiguration repeated in every environment.Klantgegevens blootgesteld door een ontbrekende controle of een bekende fout, of één openbare misconfiguratie die in elke omgeving terugkomt.
Flaws will still ship. Scanning on every change and exploited-first triage mean the dangerous ones are found and fixed first.Er gaan nog steeds fouten mee. Scans bij elke wijziging en triage op misbruik zorgen dat de gevaarlijke het eerst worden gevonden en hersteld.
Executes through engineering leads. The CISO sets the triage rules and reports the two numbers.Uitvoering via de engineeringleads. De CISO stelt de triageregels vast en rapporteert de twee getallen.
Known-exploited flaws reachable in production · days the oldest of those has been open · % of releases with an SBOM · % of repositories scanned on every change.Bekende misbruikte fouten die in productie bereikbaar zijn · dagen dat de oudste daarvan openstaat · % releases met een SBOM · % repositories dat bij elke wijziging wordt gescand.
“Security flaws in our own code, open-source components, infrastructure templates or container images reach production undetected or unprioritised, leading to exposure of customer data or disruption of service.”“Beveiligingsfouten in eigen code, open-sourceonderdelen, infrastructuursjablonen of containerimages bereiken onopgemerkt of zonder prioriteit de productie, met blootstelling van klantgegevens of verstoring van de dienstverlening tot gevolg.”
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | Security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure, is a named measure (Art. 21). NIS2 requires management to approve the measures and oversee them, and it can be held liable. | Ask suppliers how they find and prioritise flaws in what they deliver, and how fast they fix exploited ones. Put that in the contract. | An exploited flaw in your software can count as a significant incident if it meets the thresholds: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month. Confirm with legal. |
| DORA | For financial entities, the ICT risk standard requires source-code reviews with static and dynamic testing before systems go live, including open-source code where feasible (RTS (EU) 2024/1774, Art. 16). | Code a supplier builds or delivers falls under the same rule. Ask how they test it, and whether you can see the results. | An exploited flaw in a critical function can count as a major ICT-related incident: initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware), intermediate report within 72 hours of the initial notification, final report within one month. Confirm with legal. |
| SOC 2 | Vulnerability management and change management are core: flaws found, assessed and fixed, and changes tested before deployment, all tested over the period. | Read the vulnerability-management controls and their exceptions. Check whether open-source components and container images are in scope. | A known flaw left open becomes an exception in the next report if the control failed. Customers ask for a bridge letter and a root-cause analysis. |
| ISAE 3402 | Relevant where the software touches financial reporting: auditors expect program changes to be tested and approved before production. | Check whether program-change controls cover the application you rely on. | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. |
| CRA | For manufacturers of software or connected products, the CRA requires, based on the manufacturer's risk assessment, products without known exploitable vulnerabilities, and an SBOM covering at least the top-level dependencies (Annex I), from 11 December 2027. Reporting applies from 11 September 2026. | Ask whether the product falls under the CRA, and whether the vendor shares its SBOM and VEX statements. | An actively exploited vulnerability in your product: early warning within 24 hours, notification within 72 hours, via the ENISA Single Reporting Platform. Confirm with legal. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | Beveiliging bij het verwerven, ontwikkelen en onderhouden van systemen, inclusief het afhandelen en melden van kwetsbaarheden, is een benoemde maatregel (art. 21). NIS2 eist dat het bestuur de maatregelen goedkeurt en erop toeziet; het kan aansprakelijk worden gesteld. | Vraag leveranciers hoe zij fouten vinden en prioriteren in wat zij leveren, en hoe snel ze misbruikte fouten herstellen. Leg dat vast in het contract. | Een misbruikte fout in uw software kan een significant incident zijn als het de drempels haalt: vroegtijdige waarschuwing binnen 24 uur na ontdekking, incidentmelding binnen 72 uur, eindrapport binnen een maand. Stem af met legal. |
| DORA | Voor financiële instellingen eist de ICT-risicostandaard broncodereviews met statische en dynamische tests voordat systemen live gaan, waar haalbaar ook van open-sourcecode (RTS (EU) 2024/1774, art. 16). | Code die een leverancier bouwt of levert, valt onder dezelfde regel. Vraag hoe zij die testen, en of u de resultaten kunt inzien. | Een misbruikte fout in een kritieke functie kan een ernstig ICT-gerelateerd incident zijn: eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur na ontdekking), tussenrapport binnen 72 uur na de eerste melding, eindrapport binnen een maand. Stem af met legal. |
| SOC 2 | Kwetsbaarheidsbeheer en wijzigingsbeheer zijn kern: fouten gevonden, beoordeeld en hersteld, en wijzigingen getest vóór de uitrol, allemaal over de periode getest. | Lees de maatregelen voor kwetsbaarheidsbeheer en hun afwijkingen. Controleer of open-sourceonderdelen en containerimages binnen de reikwijdte vallen. | Een bekende fout die openbleef, wordt een afwijking in het volgende rapport als de maatregel faalde. Klanten vragen om een bridge letter en een oorzaakanalyse. |
| ISAE 3402 | Relevant waar de software de financiële verslaggeving raakt: auditors verwachten dat programmawijzigingen getest en goedgekeurd zijn vóór productie. | Controleer of de maatregelen voor programmawijzigingen de applicatie dekken waarop u vertrouwt. | ISAE 3402 verplicht niet tot melden aan de auditors van klanten. Verwacht een afwijking in het volgende rapport, en vraag in het contract om tussentijdse melding. |
| CRA | Voor fabrikanten van software of verbonden producten eist de CRA, op basis van de risicobeoordeling van de fabrikant, producten zonder bekende misbruikbare kwetsbaarheden, en een SBOM die minstens de directe afhankelijkheden dekt (bijlage I), vanaf 11 december 2027. De meldplicht geldt vanaf 11 september 2026. | Vraag of het product onder de CRA valt, en of de leverancier zijn SBOM en VEX-verklaringen deelt. | Een actief misbruikte kwetsbaarheid in uw product: vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur, via het Single Reporting Platform van ENISA. Stem af met legal. |
Checked against: CRA (EU) 2024/2847 Annex I and Art. 71, and the Commission CRA reporting page (2026), NIS2 Art. 20, 21 and 23, DORA RTS (EU) 2024/1774 Art. 16 and (EU) 2025/301, OWASP Top 10:2025, CISA KEV catalog, FIRST EPSS, CISA VEX minimum requirements (Apr 2023) · October 2026.
Gecontroleerd tegen: CRA (EU) 2024/2847 bijlage I en art. 71, en de CRA-meldpagina van de Commissie (2026), NIS2 art. 20, 21 en 23, DORA-RTS (EU) 2024/1774 art. 16 en (EU) 2025/301, OWASP Top 10:2025, CISA KEV-catalogus, FIRST EPSS, CISA-minimumeisen voor VEX (apr 2023) · oktober 2026.