Er komt een moment waarop een softwarebedrijf niet meer om applicatiebeveiliging heen kan. Meestal is dat het moment waarop een enterprise-klant een vragenlijst van honderdvijftig punten stuurt, of wanneer een aanbesteding een onafhankelijk testrapport van hoogstens twaalf maanden oud vraagt.
De reflex is dan om snel iets aan te zetten. Een scanner in de pijplijn, een tool met een dashboard. Twee weken later staan er driehonderd meldingen open, ontwikkelaars klagen dat de build blokkeert op een kwetsbaarheid in een bibliotheek die nergens wordt aangeroepen, en niemand kijkt er nog naar. Het budget is op, de veiligheid is niet verbeterd.
In het kort
- Begin niet bij scanners maar bij inzicht: welke externe componenten zitten in uw code, en staan er nog inloggegevens in uw repositories.
- Een haalbaar pad voor 5 tot 50 ontwikkelaars loopt over vier fasen in ongeveer een jaar, niet over één grote invoering.
- Tussen 70 en 90 procent van de code in een gemiddelde toepassing komt van buiten. Volgens Veracode komt 70 procent van de kritieke beveiligingsschuld daaruit voort.
- Geautomatiseerde analyse vindt geen autorisatiefouten en geen fouten in uw bedrijfslogica. Dat is geen instelling die u kunt aanzetten, het is een structurele beperking.
- Vanaf 11 september 2026 geldt de meldplicht uit de Cyber Resilience Act, ook voor software die u eerder verkocht.
Waar begint een softwarebedrijf met applicatiebeveiliging?
Een softwarebedrijf begint met inzicht in wat er al draait: inventariseer alle externe bibliotheken met geautomatiseerde componentanalyse, en verwijder inloggegevens en sleutels die in repositories zijn achtergebleven. Pas daarna volgen gestructureerde ontwerpeisen via dreigingsmodellering, veilige programmeerrichtlijnen en periodieke handmatige penetratietesten om logicafouten uit te sluiten.
Die volgorde is niet willekeurig. Wie begint bij de scanner, begint bij het middelste deel van het probleem en genereert werk zonder context. Wie begint bij de inventaris, weet binnen enkele dagen waar hij staat.
Het volwassenheidspad in vier fasen
Het klakkeloos invoeren van zware enterprisekaders leidt bij teams van deze omvang vrijwel altijd tot vertraging en weerstand. De vier fasen hieronder vertalen beproefde modellen zoals OWASP SAMM en het NIST-raamwerk voor veilige softwareontwikkeling naar een realistisch tempo.
Fase 0: nulmeting en code-hygiëne (week 1 tot 4)
Repositories opschonen, afhankelijkheidsscans activeren en achtergebleven sleutels en certificaten roteren. Dit kost een lead developer of DevOps-engineer eenmalig één tot twee dagen. Het levert meteen het meeste op, want een uitgelekte sleutel in een publieke repository is geen theoretisch risico.
Fase 1: preventie aan de ontwerptafel (maand 2 tot 4)
Dreigingsmodellering introduceren bij substantiële epics, softwarestuklijsten genereren en veilige ontwerpprincipes vastleggen. Product owners en architecten besteden één tot twee uur per epic met architecturale impact aan beveiligingseisen en misbruikscenario’s. Daarnaast spreekt het team een acceptatiegrens af voor nieuwe bibliotheken.
Fase 2: geautomatiseerde bewaking en secure coding (maand 5 tot 8)
Nu pas komt de statische analyse in de pijplijn, en bewust licht ingesteld. Daarbij hoort gerichte training en een afspraak over hoe bevindingen behandeld worden. Het team formuleert een haalbare hersteltermijn voor beveiligingstickets, bijvoorbeeld kritieke bevindingen binnen veertien dagen, en reserveert structureel 10 tot 15 procent van de sprintcapaciteit voor technisch onderhoud. Zonder die reservering loopt de backlog gegarandeerd vol.
Fase 3: onafhankelijke verificatie (maand 9 tot 12)
Een onafhankelijke handmatige grey-box applicatietest laten uitvoeren en een beleid voor gecoördineerde kwetsbaarheidsmelding publiceren via een security.txt-bestand. Het management maakt budget vrij, het team levert testaccounts en documentatie aan en verwerkt de bevindingen vóór de grote commerciële uitrol.
Waarom programma’s stranden
Uit discussies op ontwikkelaarsplatforms komt telkens hetzelfde patroon. De weerstand ontstaat niet tegen beveiliging als zodanig, maar tegen meldingen zonder context. Een ontwikkelaar verwoordde het zo: veel scannertickets zijn waardeloos, en de tickets die wel waarde hebben, vragen eerst context voor ze uitvoerbaar zijn.
Blokkeert een poortwachter bovendien elke build bij elke nieuwe melding, dan zoekt het team omwegen. En het administratieve proces rond een beveiligingsticket voelt vaak zwaarder dan de ingreep zelf: vier uur proces voor vijftien minuten code. Applicatiebeveiliging slaagt daarom alleen wanneer beveiligingstaken in de bestaande backlog terechtkomen, met zakelijke context erbij, en niet in losse spreadsheets of scannerrapporten.
De bouwstenen en hun samenhang
| Bouwsteen | Wat het oplost | Wanneer aan de beurt | Inspanning |
|---|---|---|---|
| Dreigingsmodellering | Fundamentele ontwerpfouten en ontbrekende vertrouwensgrenzen, voordat er code is | Fase 1, tijdens het functioneel en technisch ontwerp | 1 tot 3 uur per substantiële feature met architecturale impact |
| Veilige ontwerpprincipes | Dwingt patronen af zoals minimale rechten, veilige standaardinstellingen en scheiding van taken | Fase 1, bij het opstellen van uw architectuur en standaarden | Eenmalige definitie, daarna toetsen bij architectuurreviews |
| Secure coding | Klassieke codefouten zoals injectie en ongevalideerde invoer | Fase 2, continu tijdens de implementatie | Doorlopende discipline; 1 tot 2 dagen training per ontwikkelaar |
| Afhankelijkhedenbeheer en softwarestuklijst | Bekende kwetsbaarheden in externe bibliotheken, plus de wettelijk vereiste transparantie | Fase 0 en 1, vanaf dag één in de pijplijn | 1 dag initiële inrichting; 1 tot 2 uur per week opvolging |
| Geautomatiseerde analyse | Snelle controle op codefouten en kwetsbare bibliotheken bij elke wijziging | Fase 2, na stabilisering van de coderichtlijnen | 2 tot 4 dagen implementatie en fijnafstelling om ruis weg te halen |
| API-beveiliging | Ongeautoriseerde data-extractie via koppelvlakken en volumetrische aanvallen | Fase 1 en 2, bij elk API-ontwerp | Structureel onderdeel van API-ontwikkeling |
| Handmatige applicatiepentest | Bedrijfslogicafouten, autorisatielekken en ketens van kwetsbaarheden | Fase 3, minstens jaarlijks of vóór een belangrijke release | 3 tot 10 mandagen externe inzet per applicatiedomein |
| Gecoördineerde kwetsbaarheidsmelding | Een veilig kanaal voor externe onderzoekers om iets te melden | Fase 3, zodra de applicatie commercieel draait | Eenmalig 4 tot 8 uur voor beleid en security.txt |
Waarom scanners uw applicatielogica niet begrijpen
In DevSecOps-discussies wordt geregeld aangenomen dat statische en dynamische analyse samen handmatige verificatie overbodig maken. Dat is geen kwestie van betere instellingen. Scanners werken met vooraf gedefinieerde patronen en kennen de bedoeling van uw software niet.
Vier kwetsbaarheidsklassen blijven daardoor structureel onzichtbaar.
Autorisatie op objectniveau. Wanneer een gebruiker in het adres /api/facturen/1045 het nummer verandert naar 1046 en de financiële gegevens van een andere organisatie te zien krijgt, antwoordt de server met een geldige statuscode en keurige data. Voor een geautomatiseerd instrument is dat een geslaagde transactie. Alleen een mens ziet dat die gegevens niet aan de aanvrager toebehoren.
Fouten in de bedrijfslogica. Een betaalstap overslaan in een afrekenproces, twee elkaar uitsluitende kortingen combineren, een goedkeuringsstap omzeilen. Daar zit geen afwijkende syntax in en geen verdacht programmeerpatroon. Het zijn conceptuele fouten.
Samenloop in de tijd. Aanvalspaden waarbij asynchrone processen gelijktijdig worden aangesproken om saldi te manipuleren of limieten te overschrijden, vragen timing die buiten het bereik van standaardscripts valt.
Contextafhankelijke rechten. Verschillen tussen rollen met fijnmazige rechtenstructuren, of de scheiding tussen klanten in een platform dat meerdere organisaties bedient, worden nauwelijks begrepen. Daardoor blijven lekken tussen organisaties onopgemerkt.
De cijfers ondersteunen dat. Uit het Veracode State of Software Security Report, gebaseerd op 1,3 miljoen applicaties en 126,4 miljoen bevindingen, blijkt dat 82 procent van de organisaties kampt met beveiligingsschuld die langer dan een jaar openstaat. Organisaties die uitsluitend op scans leunen, verdrinken in ruis terwijl de fundamentele risico’s blijven liggen. Industriële analyses van ontwerpfouten tonen bovendien dat meer dan de helft van alle gebreken terug te voeren is op architectuur- en logicafouten die statische analyse per definitie niet kan herstellen.
Wat uw klanten en de wetgever vragen
| Aanleiding | Wat er gevraagd wordt | Verwacht bewijs |
|---|---|---|
| Klantvragenlijst | Lijsten met 50 tot 200 vragen over encryptie, ontwikkelproces, autorisatiemodellen en de afhandeling van kwetsbaarheden | Aantoonbaar beleid voor veilige ontwikkeling, een recente samenvatting van uw pentest, en bewijs van een patchproces met gedefinieerde hersteltijden |
| Aanbesteding of lastenboek | Bewijs dat maatregelen tegen gangbare softwarebedreigingen zijn ingebed | Onafhankelijk testrapport van hoogstens twaalf maanden oud, een verklaring over uw ontwerpaanpak, en ISO 27001- of CyberFundamentals-conformiteit |
| Cyber Resilience Act | Beveiliging vanaf het ontwerp, actief kwetsbaarhedenbeheer en een machineleesbare softwarestuklijst | Vanaf 11 september 2026 een werkend proces om actief misbruikte kwetsbaarheden binnen 24 uur te melden; eind 2027 technische documentatie, stuklijst en CE-markering |
| NIS2 bij uw klanten | Klanten in essentiële en belangrijke sectoren moeten hun keten borgen en leggen dat contractueel door | Formele borging van uw ontwikkelprocessen, aantoonbaar kwetsbaarhedenbeheer en contractuele aansprakelijkheid voor tijdige updates |
| Cyberverzekering | Strengere acceptatievoorwaarden en uitsluitingsgronden | Aantoonbare back-ups en meervoudige authenticatie, gecombineerd met structureel kwetsbaarhedenbeheer en periodieke externe testen op uw kernapplicaties |
Wat de verordening concreet van u vraagt en welke termijnen gelden, staat in ons artikel voor Vlaamse softwarebouwers.
De toeleveringsketen: het grootste deel van uw code
Tussen 70 en 90 procent van de code in een moderne toepassing komt van buiten. Dat is geen tekortkoming, dat is hoe software gebouwd wordt. Het betekent wel dat uw beveiligingsniveau grotendeels bepaald wordt door componenten die u niet zelf schreef.
De cijfers zijn stevig. Volgens het Open Source Security and Risk Analysis-rapport bevat 84 procent van de onderzochte commerciële codebases minstens één kwetsbaarheid in een opensourcecomponent, en vertoont 74 procent er een met hoog of kritiek risico. In 91 procent van de codebases zitten componenten die meer dan tien versies achterlopen of al jaren niet meer onderhouden worden. Veracode stelt vast dat 70 procent van alle kritieke beveiligingsschuld rechtstreeks uit externe code voortkomt, en dat het herstellen daarvan gemiddeld langer duurt dan bij eigen code: een mediane hersteltijd van twaalf maanden tegenover acht.
Drie praktijken houden dat beheersbaar. Continue componentanalyse in uw pijplijn, zodat u weet wat er binnenkomt. Het automatisch genereren en bewaren van een softwarestuklijst bij elke productiebuild, zodat u bij een nieuw ontdekt lek binnen minuten weet welke versies geraakt zijn. En gefaseerde updates via tooling die kleine wijzigingen stapsgewijs aanbiedt, zodat componenten niet zo ver achterlopen dat een beveiligingsupdate zware regressie veroorzaakt.
Wat het kost aan tijd
De investering zit in engineeringuren en gerichte externe expertise, niet in dure platformen. Commerciële uurtarieven voor consultancy en pentesting worden in de Belgische markt niet publiek vrijgegeven; onderstaande indicaties komen uit gevestigde praktijkkaders.
- Dreigingsmodellering: één dag voorbereiding en methodische instructie voor uw lead developers, daarna één tot drie uur per team per substantiële epic. Er bestaan gratis hulpmiddelen voor; een gestructureerde sessie aan een whiteboard werkt evengoed.
- Afhankelijkhedenbeheer en stuklijst: vier tot acht uur om de scanners en generatoren in uw pijplijn te zetten, daarna één tot twee uur per week om updates na te kijken.
- Secure coding: één tot twee dagen praktijkgerichte training, daarna twee uur per kwartaal om incidentinzichten te bespreken. Onderzoek toont dat getrainde teams kwetsbaarheden gemiddeld binnen vijf maanden oplossen, tegenover 12,6 maanden voor teams zonder training.
- Statische analyse: twee tot drie werkdagen om de tool te configureren en irrelevante regels uit te schakelen, daarna ongeveer een halfuur per sprint om geblokkeerde meldingen te beoordelen.
- Handmatige applicatiepentest: drie tot tien mandagen externe inzet, plus vier uur intern voor intake en scope en één tot drie dagen na oplevering voor triage en planning.
- Gecoördineerde kwetsbaarheidsmelding: vier tot zes uur voor beleid en security.txt, daarna uitsluitend wanneer er werkelijk iets binnenkomt.
Twee bezwaren, eerlijk bekeken
“Beveiliging vertraagt onze releases”
De onderliggende zorg is terecht. Een softwarebedrijf leeft van tempo, en elke extra processtap kost tijd.
Wat vertraagt is echter niet beveiliging, maar reactieve beveiliging. Wanneer kwetsbaarheden pas in productie opduiken, of wanneer een enterprise-klant vlak voor ondertekening een testrapport vraagt en de applicatie blijkt vol ontwerpfouten te zitten, staat de hele pijplijn stil. Sprints worden geschrapt voor noodpatches. Door risico’s aan de ontwerptafel te adresseren, corrigeert u fouten op het moment dat de architectuur nog flexibel is. Empirisch onderzoek toont dat het herstellen van een fout in productie tot dertig keer meer engineeringtijd kost dan preventie bij het ontwerp. Een gestructureerd proces maakt uw releaseplanning voorspelbaarder, niet trager.
“Onze klanten vragen er niet naar”
Vandaag misschien niet. Dat argument vervalt gegarandeerd bij de eerste offerteaanvraag van een enterprise-klant, een financiële instelling of een overheid. Grote inkopers hanteren strenge vragenlijsten en verlangen een recent onafhankelijk testrapport. Wie dat niet kan leveren, valt af.
Daarnaast is de regelgeving veranderd. De Belgische NIS2-wet verplicht duizenden bedrijven in kritieke sectoren om hun toeleveringsketen te beveiligen, en zij leggen die eisen door aan hun software- en SaaS-leveranciers. En de Cyber Resilience Act maakt veilige ontwikkeling, componenteninventaris en een meldplicht binnen 24 uur dwingend voor commerciële digitale producten op de Europese markt. Niet-naleving kan oplopen tot 15 miljoen euro of 2,5 procent van de wereldwijde omzet, en tot een verbod op markttoegang.
Waar u het beste begint
Niet bij een tool. Bij twee vragen die u binnen een week kunt beantwoorden: welke externe componenten zitten er in uw productiecode, en staan er nog sleutels of inloggegevens in uw repositories. Dat levert vrijwel altijd werk op dat vandaag al opgelost kan worden.
Weet u dat, dan wordt de vervolgvraag concreet: welke fase past bij waar u staat, en welke bouwsteen levert nu het meeste op. Cyberplan doet die nulmeting en voert de onafhankelijke verificatie uit die u zelf niet geloofwaardig over uzelf kunt doen. Wat dat inhoudt, staat op onze pagina over application security.
Veelgestelde vragen
Wat houdt een veilige ontwikkelcyclus in?
Een veilige ontwikkelcyclus verweeft beveiligingscontroles door elke fase van het ontwikkelproces. In plaats van pas vlak voor implementatie te controleren, omvat ze risicoanalyse bij de architectuurdefinitie, veilige programmeerstandaarden tijdens het coderen, geautomatiseerde controles in de releasepijplijn en onafhankelijke validatie vóór ingebruikname.
Waarom volstaat een geautomatiseerde scanner niet?
Scanners analyseren vooraf gedefinieerde patronen en bekende handtekeningen, maar begrijpen de context van uw toepassing niet. Autorisatiefouten, rechtenstructuren tussen klanten en omzeilingen van de bedrijfslogica blijven daardoor onzichtbaar. Alleen menselijke onderzoekers kunnen nagaan of uw workflows manipuleerbaar zijn vanuit het perspectief van een aanvaller.
Wat is dreigingsmodellering en wanneer doet u dat?
Dreigingsmodellering brengt potentiële kwetsbaarheden, aanvalspaden en vertrouwensgrenzen van uw architectuur in kaart. Dat gebeurt tijdens de ontwerpfase, voordat er code geschreven wordt, zodat conceptuele fouten tegen minimale kosten verdwijnen.
Wat is een softwarestuklijst en waarom is die verplicht?
Een softwarestuklijst is een gestructureerde, machineleesbare inventaris van alle externe bibliotheken en modules in uw toepassing. Daarmee stelt u bij een nieuw ontdekte kwetsbaarheid onmiddellijk vast welke delen risico lopen. De Cyber Resilience Act maakt het verstrekken ervan wettelijk verplicht.
Hoe vaak moet een applicatiepentest herhaald worden?
Idealiter jaarlijks, en daarnaast na elke ingrijpende architectuurwijziging of grote functionele release. Enterprise-opdrachtgevers, auditors en verzekeraars hanteren in de praktijk een rapport van hoogstens twaalf maanden oud als norm.
Wat regelt een beleid voor gecoördineerde kwetsbaarheidsmelding?
Het beschrijft hoe externe onderzoekers gevonden problemen op een verantwoorde manier kunnen melden: via welk kanaal, binnen welke reactietermijn en onder welke voorwaarden voor wie te goeder trouw handelt. Dat voorkomt dat een kwetsbaarheid meteen publiek wordt en geeft uw team tijd om te herstellen.
Blijft u verantwoordelijk voor kwetsbaarheden in opensourcepakketten?
Ja. Als fabrikant blijft u volledig aansprakelijk voor het opgeleverde product, met inbegrip van alle ingebouwde componenten van derden.
Hoe voorkomt u dat ontwikkelaars meldingsmoe worden?
Stel uw analysetools uitsluitend in op bevindingen met hoge betrouwbaarheid en prioriteer op werkelijke aanroepbaarheid in plaats van op theoretische ernst. Koppel elke melding aan een concrete herstelinstructie binnen uw bestaande backlog, niet in een apart rapport.
Welke actie neemt een ontwikkelteam als eerste?
Activeer geautomatiseerde controle op achtergebleven inloggegevens in uw repositories, en voer een eerste componentenscan uit om verouderde en kwetsbare pakketten op te sporen. Dat kost weinig tijd en levert bijna altijd meteen werk op.
