Most of the software we run was built by us or for us. Four ways it fails long before anyone attacks it — and the one control that closes each gap. De meeste software die we draaien is door of voor ons gebouwd. Vier manieren waarop ze faalt lang voordat iemand aanvalt — en de ene maatregel die elk gat sluit.
Developers need passwords and keys to make software talk to databases and cloud services. The fastest way to make it work is to type them straight into the code. That code is copied to every developer's laptop, to the build server, to backups, and often to an external agency. If the repository is ever made public by accident, or one laptop is stolen, automated bots find the keys within minutes and try them. Keys committed years ago usually still work.
Business impact: a single leaked key can be direct access to the production database or the cloud account, with no password guessing and no alarm. What tends to work is not discipline but plumbing: a vault that hands out secrets at run time, and a scanner that blocks a commit containing one.
Ontwikkelaars hebben wachtwoorden en sleutels nodig om software met databases en clouddiensten te laten praten. De snelste manier om het werkend te krijgen is ze rechtstreeks in de code te typen. Die code wordt gekopieerd naar elke ontwikkelaarslaptop, naar de bouwserver, naar back-ups en vaak naar een extern bureau. Wordt de repository per ongeluk openbaar, of wordt één laptop gestolen, dan vinden geautomatiseerde bots de sleutels binnen minuten en proberen ze uit. Sleutels van jaren geleden werken meestal nog.
Bedrijfsimpact: één gelekte sleutel kan directe toegang tot de productiedatabase of het cloudaccount betekenen, zonder wachtwoorden raden en zonder alarm. Wat meestal werkt is geen discipline maar loodgieterswerk: een kluis die geheimen pas tijdens het draaien uitgeeft, en een scanner die een commit met een geheim erin blokkeert.
Scanner bots already find leaked keys within minutes; AI now also reads old commit history and decompiled code at scale, turning a forgotten three-year-old key into a same-day, automatically confirmed way in.Scannerbots vinden gelekte sleutels al binnen minuten; AI doorzoekt nu ook oude commits en gedecompileerde code op schaal, waardoor een vergeten sleutel van drie jaar oud dezelfde dag automatisch wordt bevestigd en misbruikt.
Developers paste error messages, config files and whole functions into free AI chat tools to get help fast, and a hardcoded password or key travels with the paste, outside any company system entirely.Ontwikkelaars plakken foutmeldingen, configuratiebestanden en hele functies in gratis AI-chattools om snel hulp te krijgen, en een hardgecodeerd wachtwoord of sleutel gaat gewoon mee, buiten elk bedrijfssysteem om.
AI-assisted scanners check every commit and every chat paste in real time, not once a quarter, and block the commit outright. The fix stays the same: a vault that hands out secrets at run time.AI-ondersteunde scanners controleren elke commit en elke chatplak in realtime, niet één keer per kwartaal, en blokkeren de commit meteen. De oplossing blijft hetzelfde: een kluis die geheimen pas tijdens het draaien uitgeeft.
Between the code and the customer sits a chain of machines that compile, test, package and publish every release. It runs unattended, with broad rights, and rarely gets the attention the production systems get. An attacker who controls it does not need to break our software: they add a few lines during the build. The result is signed with our certificate, installed by every customer, and trusted by every security product on their side.
Business impact: we become the supply chain attack on our own customers. Liability, recall of a release, and a loss of trust that outlasts the technical fix. We suggest giving the pipeline the same protection as production: MFA on every account, least privilege for build jobs, and releases signed with SLSA build provenance.
Tussen de code en de klant staat een keten van machines die elke release compileert, test, verpakt en publiceert. Die draait onbeheerd, met ruime rechten, en krijgt zelden de aandacht die productiesystemen krijgen. Een aanvaller die haar beheerst hoeft onze software niet te kraken: hij voegt tijdens het bouwen een paar regels toe. Het resultaat is ondertekend met ons certificaat, geïnstalleerd door elke klant en vertrouwd door elk beveiligingsproduct aan hun kant.
Bedrijfsimpact: wij worden de supply-chainaanval op onze eigen klanten. Aansprakelijkheid, het terugroepen van een release, en een vertrouwensbreuk die de technische fix overleeft. Wij raden aan de pipeline dezelfde bescherming te geven als productie: MFA op elk account, minimale rechten voor bouwtaken, en releases ondertekend met SLSA-herkomstgegevens.
Once inside, AI helps an attacker write convincing build-step changes and hide them in normal-looking commits, but reaching the pipeline still requires a stolen account or a real misconfiguration to exploit first.Eenmaal binnen helpt AI een aanvaller overtuigende wijzigingen in bouwstappen te schrijven en te verbergen in gewoon ogende commits, maar de pipeline bereiken vereist nog steeds een gestolen account of een echte misconfiguratie.
AI coding agents wired into the pipeline can be tricked by a crafted pull request or issue comment into running commands with build-server rights, turning a helpful automation into an attacker's own foothold.AI-codeeragents die in de pipeline zijn gekoppeld, kunnen door een geprepareerde pull request of issuecomment worden verleid tot het uitvoeren van commando's met bouwserverrechten, waardoor een handige automatisering een bruggenhoofd voor de aanvaller wordt.
AI-based monitoring flags a build job doing something it has never done before, such as reaching a new server or account. The real fix stays MFA, signed releases and a least-privilege token per coding agent, not smarter alarms alone.AI-gebaseerde monitoring signaleert een bouwtaak die iets doet wat nooit eerder gebeurde, zoals een nieuwe server of account benaderen. De echte oplossing blijft MFA, ondertekende releases en een token met minimale rechten per codeeragent, niet alleen slimmere alarmen.
Many organisations test security the way they pass a driving test: once, formally, after the fact. A penetration test months after release finds the flaws that were cheap to fix during design and are now expensive: the code is live, customers depend on it, and the team has moved on. Meanwhile the flaws have been reachable from the internet the whole time.
Business impact: the same defect costs a fraction to fix when it is found at design time, and multiples once it is in production with data behind it. Security works best inside the way software is built: requirements in the definition of done, automated checks on every change, and a short threat-modelling session for any feature that handles money or personal data. The yearly pentest then confirms instead of discovers.
Veel organisaties testen beveiliging zoals je een rijexamen doet: één keer, formeel, achteraf. Een penetratietest maanden na de release vindt de fouten die tijdens het ontwerp goedkoop te herstellen waren en nu duur zijn: de code is live, klanten zijn ervan afhankelijk en het team is doorgegaan. Ondertussen waren de fouten de hele tijd vanaf internet bereikbaar.
Bedrijfsimpact: hetzelfde gebrek kost een fractie om te herstellen als het bij het ontwerp wordt gevonden, en een veelvoud zodra het in productie staat met data erachter. Beveiliging werkt het best binnen de manier van bouwen: eisen in de definition of done, geautomatiseerde controles op elke wijziging, en een korte threat-modellingsessie voor elke functie die geld of persoonsgegevens verwerkt. De jaarlijkse pentest bevestigt dan in plaats van ontdekt.
Between the yearly pentest, AI-assisted scanning tools let an outside attacker probe a live application for known flaw patterns far faster than a human ever could, closing the gap a once-a-year test leaves open.Tussen de jaarlijkse pentest door kan een buitenstaander met AI-ondersteunde scantools een live applicatie veel sneller op bekende foutpatronen doorzoeken dan een mens ooit kon, waardoor het gat van jaarlijks testen sneller wordt gevonden.
AI coding assistants let developers ship features far faster than security review capacity grows, so more code reaches production untested between the yearly pentests, and the flaws pile up exactly where nobody is looking.AI-codeerassistenten laten ontwikkelaars functies veel sneller opleveren dan de reviewcapaciteit meegroeit, waardoor meer code ongetest in productie komt tussen de jaarlijkse pentests door, precies waar niemand kijkt.
AI-assisted code and dependency scanning can run on every change instead of once a year, flagging likely flaws before release. AI-written code gets the same review and scans as human code, and a flagged feature is not done yet.AI-ondersteunde code- en afhankelijkheidsscans kunnen op elke wijziging draaien in plaats van eenmaal per jaar, en waarschijnlijke fouten vóór release signaleren. Door AI geschreven code krijgt dezelfde review en scans als mensenwerk, en een gesignaleerde functie is nog niet klaar.
Software is bought like a project and behaves like a pet. The agency delivers, the contract ends, the internal sponsor changes jobs, and the application keeps running for years with nobody assigned to it. Its components age, security advisories pile up unread, and when a fix is finally needed nobody can safely change the code. The portal still holds every customer record it ever collected.
Business impact: an orphaned application is an unpatchable system with a public face. We suggest that every piece of software in production has a named owner, a maintenance budget that survives the project, and an exit plan: either it is maintained or it is switched off. “Nobody owns it” is the finding an auditor writes down first.
Software wordt gekocht als een project en gedraagt zich als een huisdier. Het bureau levert op, het contract loopt af, de interne opdrachtgever wisselt van baan, en de applicatie draait jaren door zonder dat iemand ervoor verantwoordelijk is. De onderdelen verouderen, beveiligingswaarschuwingen stapelen zich ongelezen op, en als er eindelijk iets gerepareerd moet worden kan niemand de code veilig aanpassen. Het portaal bevat nog steeds elk klantrecord dat het ooit verzamelde.
Bedrijfsimpact: een verweesde applicatie is een onpatchbaar systeem met een publiek gezicht. Wij raden aan dat elk stuk software in productie een eigenaar met naam heeft, een onderhoudsbudget dat het project overleeft, en een exitplan: óf het wordt onderhouden, óf het gaat uit. “Niemand is eigenaar” is de bevinding die een auditor als eerste opschrijft.
For an application with years of unpatched advisories, AI tools now turn a published vulnerability description into a working exploit within hours, and nobody is watching an orphaned system closely enough to notice.Voor een applicatie met jaren aan ongepatchte waarschuwingen zetten AI-tools een gepubliceerde kwetsbaarheidsbeschrijving binnen uren om in een werkende exploit, en niemand houdt een verweesde applicatie goed genoeg in de gaten om het op te merken.
AI tools can now read and explain undocumented legacy code that only the original agency once understood, which helps an attacker map its weaknesses just as easily as it would help a new maintainer fix them.AI-tools kunnen nu ongedocumenteerde legacycode uitleggen die alleen het oorspronkelijke bureau ooit begreep, wat een aanvaller net zo goed helpt de zwakke plekken in kaart te brengen als het een nieuwe beheerder zou helpen ze te herstellen.
AI code-analysis tools can summarise what an abandoned application actually does and where its risk sits, in days instead of months. That only helps once a named owner picks up the maintenance budget behind it.AI-codeanalysetools kunnen in dagen in plaats van maanden samenvatten wat een verweesde applicatie precies doet en waar het risico zit. Dat helpt pas echt zodra een eigenaar met naam het onderhoudsbudget erachter oppakt.
A reference, not a checklist. Signing at the build and checking that signature at deploy tie the two ends together: production then runs only what your pipeline built. The red boxes are often the most effective place to start.
Een referentie, geen afvinklijst. Ondertekenen bij de build en die handtekening controleren bij de uitrol verbinden de twee uiteinden: productie draait dan alleen wat uw pipeline heeft gebouwd. De rode blokken zijn vaak de meest effectieve plek om te beginnen.
| Control | Closes | In one line |
|---|---|---|
| Secret scanning + vault | Secrets (01) | A scanner blocks any commit that contains a key, and a vault hands secrets to software at run time. No secret lives in code. |
| Protected pipeline | Pipeline (02) | MFA on every account that can touch the build, least privilege for build jobs, and every release signed with SLSA provenance and verified before it ships. |
| Definition of done | Testing (03) | Security requirements, for example from OWASP ASVS 5.0, are part of “finished”. A feature with an open security finding is not done. |
| Checks in the pipeline | Testing (03) | Automated code and dependency scans on every change, covering at least the OWASP Top 10:2025. Findings above an agreed severity block the release. |
| Threat modelling | Testing (03) | One hour with the team before building a feature that handles money or personal data: what could go wrong, and what do we do about it. |
| Named owner + budget | Ownership (04) | Every application in production has a person and a maintenance budget line. No owner means a switch-off date. |
| Pentest | All four | An independent test before every major release. |
| security.txt + disclosure policy | All four | A published policy and a security.txt file, so researchers can report a flaw to us first. |
| Developer training | All four | Short, in the tools they use, about the mistakes that actually occurred here. Not a yearly slide deck. |
| Maatregel | Sluit | In één zin |
|---|---|---|
| Secret scanning + kluis | Geheimen (01) | Een scanner blokkeert elke commit met een sleutel erin, en een kluis geeft geheimen pas tijdens het draaien aan de software. Geen geheim staat in code. |
| Beschermde pipeline | Pipeline (02) | MFA op elk account dat bij de build kan, minimale rechten voor bouwtaken, en elke release ondertekend met SLSA-herkomstgegevens en geverifieerd voordat ze uitgaat. |
| Definition of done | Testen (03) | Beveiligingseisen, bijvoorbeeld uit OWASP ASVS 5.0, horen bij “klaar”. Een functie met een open beveiligingsbevinding is niet klaar. |
| Controles in de pipeline | Testen (03) | Automatische scans van code en afhankelijkheden bij elke wijziging, minstens op de OWASP Top 10:2025. Bevindingen boven een afgesproken ernst blokkeren de release. |
| Threat modelling | Testen (03) | Eén uur met het team vóór het bouwen van een functie die geld of persoonsgegevens verwerkt: wat kan er misgaan, en wat doen we eraan. |
| Eigenaar + budget | Eigenaarschap (04) | Elke applicatie in productie heeft een persoon en een onderhoudsbudgetpost. Geen eigenaar betekent een uitzetdatum. |
| Pentest | Alle vier | Een onafhankelijke test vóór elke grote release. |
| security.txt + meldbeleid | Alle vier | Een gepubliceerd beleid en een security.txt-bestand, zodat onderzoekers een fout eerst aan ons kunnen melden. |
| Training ontwikkelaars | Alle vier | Kort, in de tools die ze gebruiken, over de fouten die hier echt zijn gemaakt. Geen jaarlijkse presentatie. |
Secrets in code and orphaned applications exist in almost every organisation that has ever commissioned software. Bots scan for leaked keys continuously.Geheimen in code en verweesde applicaties bestaan in bijna elke organisatie die ooit software heeft laten bouwen. Bots scannen doorlopend op gelekte sleutels.
Direct access to production data, or a poisoned release delivered to every customer under our signature. Liability follows the software we ship.Directe toegang tot productiedata, of een vergiftigde release die onder onze handtekening bij elke klant belandt. Aansprakelijkheid volgt de software die wij leveren.
Flaws will still ship. Scanning, signed builds and ownership mean they are found early, fixed fast and cannot reach every customer unnoticed.Er zullen nog steeds fouten uitgaan. Scanning, ondertekende builds en eigenaarschap zorgen dat ze vroeg worden gevonden, snel gerepareerd en niet ongemerkt elke klant bereiken.
Executes through engineering leads. Each business owner who commissioned an application owns its budget line after launch.Uitvoering via de engineeringleads. Elke opdrachtgever die een applicatie liet bouwen is eigenaar van de budgetpost na oplevering.
% of repositories with secret scanning enforced · number of production applications without a named owner · days from a critical finding to the fix in production · % of releases that are signed and verified.% repositories met afgedwongen secret scanning · aantal productieapplicaties zonder eigenaar met naam · dagen van kritieke bevinding tot fix in productie · % releases dat ondertekend en geverifieerd is.
“Insecure software delivery — secrets in code, an unprotected build pipeline, late testing and applications without an owner — leads to exposure of customer data or a compromised release delivered to customers.”“Onveilige softwarelevering — geheimen in code, een onbeschermde bouwpipeline, te laat testen en applicaties zonder eigenaar — leidt tot blootstelling van klantgegevens of een gecompromitteerde release bij klanten.”
| 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 is a named measure, including how vulnerabilities are handled and disclosed. NIS2 requires management to approve the approach, and it can be held liable. | Ask the agency or vendor how they handle vulnerabilities in what they built for you, and put maintenance, patching and a disclosure route in the contract. A finished project is not a finished obligation. | A leaked key or a poisoned release that affects customers 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. NIS2 may also require you to warn affected customers. Confirm with legal. |
| DORA | For financial entities: a policy for acquisition, development and maintenance of ICT systems, testing before deployment, and source-code security for critical functions. | Outsourced development is an ICT third-party arrangement: it belongs in the register with the prescribed clauses, including access to the code and an exit plan if the developer disappears. | A compromised release or exposed data 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 | Change management and the development lifecycle are core: code review, separation between development and production, controlled deployment, and vulnerability management, all tested over the period. | Read the change-management controls and their exceptions. Emergency changes and access to the pipeline are where deviations hide. The complementary user entity controls tell you what you are expected to approve yourself. | An unauthorised change or a leaked credential becomes an exception in the next report. Auditors trace how it entered the pipeline, and 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 authorised, tested and approved, and access to production code restricted. | Check whether program-change controls cover the application you rely on. The report often expects you to approve changes yourself; if nobody does, that is your gap, not theirs. | An unauthorised or untested change is likely to show as a deviation in the next report; ISAE 3402 itself creates no duty to notify user auditors. Ask for interim disclosure in the contract. |
| CRA | For manufacturers of software or connected products: reporting from 11 September 2026; security by design, vulnerability handling, an SBOM and a defined support period from 11 December 2027. NIST SSDF helps show security by design. | Ask whether the product falls under the CRA, how the vendor will show conformity, and how long it will receive security updates. | 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 is een benoemde maatregel, inclusief hoe kwetsbaarheden worden afgehandeld en gemeld. NIS2 eist dat het bestuur de aanpak goedkeurt; het kan aansprakelijk worden gesteld. | Vraag het bureau of de leverancier hoe zij omgaan met kwetsbaarheden in wat zij voor u bouwden, en leg onderhoud, patching en een meldroute vast in het contract. Een afgerond project is geen afgeronde verplichting. | Een gelekte sleutel of een vergiftigde release die klanten raakt, 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. NIS2 kan ook eisen dat u getroffen klanten waarschuwt. Stem af met legal. |
| DORA | Voor financiële instellingen: beleid voor het verwerven, ontwikkelen en onderhouden van ICT-systemen, testen vóór ingebruikname, en beveiliging van broncode voor kritieke functies. | Uitbestede ontwikkeling is een ICT-derdenovereenkomst: die hoort in het register met de voorgeschreven bepalingen, inclusief toegang tot de code en een exitplan als de ontwikkelaar verdwijnt. | Een gecompromitteerde release of blootgestelde data 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 | Wijzigingsbeheer en de ontwikkelcyclus zijn kern: codereview, scheiding tussen ontwikkeling en productie, beheerste uitrol en kwetsbaarheidsbeheer, allemaal over de periode getest. | Lees de maatregelen voor wijzigingsbeheer en hun afwijkingen. Noodwijzigingen en toegang tot de pipeline zijn waar afwijkingen zich verbergen. De complementary user entity controls zeggen wat u zelf hoort goed te keuren. | Een ongeautoriseerde wijziging of een gelekt wachtwoord wordt een afwijking in het volgende rapport. Auditors volgen hoe het de pipeline binnenkwam, en klanten vragen om een bridge letter en een oorzaakanalyse. |
| ISAE 3402 | Relevant waar de software de financiële verslaggeving raakt: auditors verwachten dat programmawijzigingen geautoriseerd, getest en goedgekeurd zijn, en dat toegang tot productiecode beperkt is. | Controleer of de maatregelen voor programmawijzigingen de applicatie dekken waarop u vertrouwt. Het rapport verwacht vaak dat u wijzigingen zelf goedkeurt; doet niemand dat, dan is dat uw gat, niet het hunne. | Een ongeautoriseerde of ongeteste wijziging komt waarschijnlijk als afwijking in het volgende rapport; ISAE 3402 zelf verplicht niet tot melden aan de auditors van klanten. Vraag in het contract om tussentijdse melding. |
| CRA | Voor fabrikanten van software of verbonden producten: meldplicht vanaf 11 september 2026; security by design, kwetsbaarheidsbeheer, een SBOM en een vaste ondersteuningsperiode vanaf 11 december 2027. NIST SSDF helpt security by design aan te tonen. | Vraag of het product onder de CRA valt, hoe de leverancier conformiteit aantoont en hoe lang het beveiligingsupdates krijgt. | 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 and the Commission CRA reporting page (2026), NIS2 Art. 20, 21 and 23, DORA RTS (EU) 2025/301 (Feb 2025), OWASP Top 10:2025, OWASP ASVS 5.0 (May 2025), NIST SP 800-218 (Feb 2022; v1.2 draft Dec 2025), SLSA v1.2, RFC 9116 (2022) · September 2026.
Gecontroleerd tegen: CRA (EU) 2024/2847 en de CRA-meldpagina van de Commissie (2026), NIS2 art. 20, 21 en 23, DORA-RTS (EU) 2025/301 (feb 2025), OWASP Top 10:2025, OWASP ASVS 5.0 (mei 2025), NIST SP 800-218 (feb 2022; v1.2-concept dec 2025), SLSA v1.2, RFC 9116 (2022) · september 2026.