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. The fix 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. De oplossing 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.
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. The pipeline deserves the same protection as production: MFA on every account, least privilege for build jobs, and releases that are signed and verified, not just uploaded.
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. De pipeline verdient dezelfde bescherming als productie: MFA op elk account, minimale rechten voor bouwtaken, en releases die ondertekend en geverifieerd worden, niet alleen geüpload.
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 has to move into 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 moet in de manier van bouwen zitten: 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.
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. Every piece of software that runs in production needs 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. Elk stuk software dat in productie draait heeft een eigenaar met naam nodig, 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.
| 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 and verified before it ships. |
| Definition of done | Testing (03) | Security requirements are part of “finished”, not a separate phase. A feature with an open security finding is not done. |
| Checks in the pipeline | Testing (03) | Automated dependency and code scanning on every change. Findings block the release above an agreed severity. |
| 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 + disclosure | All four | An independent test before every major release, and a public address where 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 en geverifieerd voordat ze uitgaat. |
| Definition of done | Testen (03) | Beveiligingseisen horen bij “klaar”, niet bij een aparte fase. Een functie met een open beveiligingsbevinding is niet klaar. |
| Controles in de pipeline | Testen (03) | Automatische scans van afhankelijkheden en code bij elke wijziging. 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 + disclosure | Alle vier | Een onafhankelijke test vóór elke grote release, en een publiek adres waar 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 slidedeck. |
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. Management approves the approach and is accountable. | 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 is a significant incident: early warning within 24 hours, notification within 72, final report within a month. Customers who received the release must be warned. 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 is a major ICT incident: initial notification within hours of classification, intermediate report within 72 hours, final report within a 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 must 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: program changes must 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 becomes a control deficiency in the period and must be disclosed to the user auditors, who will ask what it did to the numbers. |
| 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. Het bestuur keurt de aanpak goed en is aansprakelijk. | 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 is een significant incident: vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur, eindrapport binnen een maand. Klanten die de release ontvingen moeten worden gewaarschuwd. Bevestig 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 is een ernstig ICT-incident: eerste melding binnen enkele uren na classificatie, tussenrapport binnen 72 uur, eindrapport binnen een maand. Bevestig 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 moet goedkeuren. | 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: programmawijzigingen moeten geautoriseerd, getest en goedgekeurd zijn, en toegang tot productiecode beperkt. | 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 wordt een tekortkoming in de periode en moet aan de auditors van de klanten worden gemeld, die vragen wat het met de cijfers heeft gedaan. |