Secure software development zonder security als sluitpost

Veilige software ontstaat niet door één controle aan het einde. Deze gids laat zien hoe eigenaarschap, eisen, code, dependencies, build, tests en productiebeheer vanaf het begin deel uitmaken van het normale ontwikkelproces.

Het korte antwoord

Secure software development betekent niet dat een securityteam aan het einde nog één controle doet. Het betekent dat eigenaarschap, eisen, code, dependencies, build, tests, deployment en productiebeheer vanaf het begin onderdeel zijn van het normale ontwikkelproces. Security is dan geen sluitpost, maar een eigenschap van de manier van werken.

Vier nuanceringen horen daar direct bij. Niet ieder team heeft alle rollen of tools nodig: een team van vier met een interne tool richt dit anders in dan een betaalplatform. Meer scanners betekenen niet automatisch veiligere software: een scan die niemand leest, voegt niets toe. Automatische controles ondersteunen menselijk oordeel, ze vervangen het niet. En het benodigde niveau hangt af van de data die je verwerkt, de bedrijfsimpact van een incident, de dreigingen die voor jouw product realistisch zijn en de risicotolerantie van je organisatie.

Deze gids is geschreven voor founders van softwarebedrijven, CTO's, engineering managers, product owners en technische inkopers die security structureler willen organiseren zonder meteen een securityafdeling op te richten. We leunen op primaire bronnen: het NIST Secure Software Development Framework (SSDF 1.1) als framework met praktijken en gewenste uitkomsten, OWASP ASVS als verificatiestandaard, OWASP SAMM als volwassenheidsmodel, de OWASP Web Security Testing Guide als testgids en de Nederlandse NCSC-richtlijnen als praktische begeleiding. Waar wij zelf een keuze of weging doen, staat er expliciet bij dat het analyse van tre plus is.

Wat valt er wel en niet onder?

De markt gebruikt dezelfde woorden voor heel verschillende dingen. Deze tabel zet de begrippen naast elkaar, zoals wij ze in deze gids gebruiken.

Drie expliciete grenzen. Secure software development is geen synoniem voor pentesten: een pentest is één controle op één moment, geen manier van ontwikkelen. Security testing is niet hetzelfde als alle QA: functionele tests controleren of de software doet wat hij moet doen, securitytests controleren of hij niets doet wat hij niet moet doen. En DevSecOps betekent niet dat iedere developer securityspecialist moet zijn: het betekent dat de pipeline controles draait die voor developers bruikbaar zijn. Algemene IT-beveiliging, endpoints, awareness en netwerkmonitoring vallen bewust buiten deze pagina.

Eigenaarschap: security is gedeeld, maar niet eigenaarloos

"Iedereen is verantwoordelijk" klinkt mooi, maar betekent in de praktijk vaak dat niemand een bevinding oppakt. De NIST SSDF begint daarom niet bij tools maar bij de organisatie: bereid de organisatie voor, bescherm de software, produceer goed beveiligde software en reageer op kwetsbaarheden. Die vier groepen van praktijken lopen van eigenaarschap naar uitvoering. Het framework is risicogestuurd en aanpasbaar: je kiest per praktijk of die past bij jouw risico's, in plaats van alles af te vinken.

De matrix hieronder laat per onderdeel zien wie uitvoert, wie beslist en wie onafhankelijk verifieert. Het is een praktisch startpunt, geen voorschrift: in een klein team vervult één persoon meerdere kolommen, en dat is prima zolang het benoemd is.

Let op de laatste kolom. Onafhankelijke verificatie hoeft niet altijd een externe partij te zijn: een tweede developer die een pull request beoordeelt is ook onafhankelijke verificatie. Het punt is dat de maker niet de enige controleur is.

Van idee tot productie: zeven fasen

Deze levenscyclus volgt de opbouw die ook de NIST SSDF en de NCSC-richtlijnen voor veilige softwareontwikkeling hanteren: veiligheid hoort in elke fase, niet alleen aan het einde. Per fase noemen we het doel, de minimale praktische controle, mogelijke verdieping, de normale eigenaar en het bewijs dat overblijft.

1. Requirements en risico

Doel: vastleggen wat de software mag doen en wat hij nooit mag doen. Minimale controle: bij risicovolle wijzigingen expliciet noteren welke data geraakt wordt en wat er mis kan gaan. Verdieping: securityrequirements op basis van een verificatiestandaard als OWASP ASVS, gekoppeld aan de risico's van jouw product. Eigenaar: product owner, met de tech lead voor de technische invulling. Bewijs: securityrequirements bij de betreffende tickets of in de projectspecificatie.

2. Ontwerp en architectuur

Doel: keuzes maken die later moeilijk te herstellen zijn, zoals autorisatiemodel, datastromen en trust boundaries. Minimale controle: bij nieuwe onderdelen een korte beoordeling van wie waar bij mag en welke data waarheen stroomt. Verdieping: threat modelling voor de onderdelen met de hoogste impact. Eigenaar: tech lead of senior developer. Bewijs: een vastgelegd ontwerpbesluit of threat model, hoe kort ook.

3. Ontwikkeling en code review

Doel: fouten vangen terwijl ze nog goedkoop zijn. Minimale controle: iedere wijziging wordt door een tweede developer beoordeeld, met aandacht voor invoervalidatie, autorisatie en foutafhandeling. Verdieping: reviewrichtlijnen met een expliciete securitychecklist, bijvoorbeeld afgeleid van ASVS-eisen die voor jouw product gelden. Eigenaar: het developmentteam, de tech lead bewaakt de regels. Bewijs: reviewregels en een reviewspoor in je versiebeheer.

4. Dependencies en software supply chain

Doel: weten wat je meeneemt in je product. Minimale controle: een actuele inventaris van dependencies en runtimes, met een afspraak wie updates volgt en uitvoert. Verdieping: een SBOM als formele inventaris, dependency scanning in de pipeline en beleid voor verlopen of verlaten packages. Eigenaar: developers voor de code, de tech lead voor het beleid. Bewijs: dependency-inventaris of SBOM en een updatelog.

5. Build en CI/CD

Doel: de weg van code naar productie beheersbaar maken. Minimale controle: geheimen buiten de code, een reproduceerbare build en een pipeline die tests en basiscontroles altijd draait. Verdieping: SAST, SCA en secret scanning als onderdeel van de pipeline, met afspraken over wanneer een bevinding een release blokkeert. Eigenaar: DevOps- of platformverantwoordelijke. Bewijs: pipeline-uitvoer en de releasebeslissingen die eruit volgden.

6. Test en release

Doel: voor go-live vaststellen dat de software zich gedraagt zoals bedoeld, ook onder ongewone invoer. Minimale controle: geautomatiseerde functionele tests plus een bewuste controle van risicovolle flows zoals login, betalingen en rechten. Verdieping: DAST of API-securitytests tegen een draaiende testomgeving, en voor kritische releases een onafhankelijke test of pentest. Eigenaar: QA samen met development, de product owner beslist over go-live. Bewijs: testresultaten en een releasebesluit.

7. Productie, updates en reactie op kwetsbaarheden

Doel: na release beheersbaar blijven. Minimale controle: weten welke versie draait, een urgente patchprocedure en een benoemde eigenaar voor binnenkomende kwetsbaarheidsmeldingen. Verdieping: logging en monitoring die afwijkingen zichtbaar maken, periodieke evaluatie van uitzonderingen en een geoefende reactie op ernstige meldingen. Eigenaar: beheerder of hostingpartij voor de runtime, het productteam voor de applicatie. Bewijs: patchlog, wijzigingsregistratie en een incidentprocedure.

Eén waarschuwing bij al deze fasen: documentatie is ondersteunend, geen bewijs dat software veilig is. Een threat model dat niemand leest en een SBOM die niemand bijwerkt zeggen niets over de veiligheid van de release van gisteren. Bewijs telt alleen als het actueel is en er een eigenaar aan hangt.

Welke controle doet wat?

Er zijn veel controles en ze overlappen bewust. De tabel laat per controle zien wat er wordt onderzocht, wanneer je hem uitvoert, wat hij goed kan vinden, wat hij waarschijnlijk mist en bij wie hij hoort. Geen van deze controles bewijst op zichzelf dat een applicatie veilig is.

De feitelijke grenzen zijn belangrijker dan de mogelijkheden. SAST onderzoekt code zonder de applicatie uit te voeren en ziet daarom geen runtimegedrag. DAST test het gedrag van een draaiende applicatie, maar alleen de paden die de test bereikt. SCA onderzoekt gebruikte componenten en bekende kwetsbaarheden, niet de kwetsbaarheden die nog niemand heeft gevonden. Een SBOM is primair een inventaris en geen veiligheidsscan. Secret scanning kan bekende patronen detecteren, maar voorkomt niet ieder geheim in code of logs. Een pentest is een momentopname en vervangt continue controles niet. Geen enkele tool bewijst dat een applicatie volledig veilig is.

Waarom scanners alleen niet genoeg zijn

Automatische controles zijn waardevol, maar ze hebben structurele beperkingen die je moet kennen voordat je erop vertrouwt.

False positives: tools melden problemen die er niet zijn. Zonder iemand die meldingen beoordeelt, ontstaat ruis, en ruis leidt tot genegeerde waarschuwingen. False negatives: tools missen problemen die er wel zijn. Een groene scan betekent dat de tool niets vond, niet dat er niets te vinden was.

De diepere beperking is context. Een scanner kent je business niet. Autorisatie- en businesslogicafouten, zoals een klant die bij andermans facturen kan, zijn zelden een patroon dat een tool herkent. Configuratiefouten buiten de code, zoals een verkeerd ingestelde header op de load balancer, vallen buiten wat een codescanner ziet. En een bevinding zonder eigenaar verdwijnt in een lijst: scans die wel draaien maar releases nooit blokkeren, uitzonderingen die permanent worden en waarschuwingen die door te veel ruis worden genegeerd zijn organisatieproblemen, geen toolproblemen.

Het NCSC onderzocht de nieuwe ontwikkelingen in statische analyse: een literatuurstudie gecombineerd met een enquête onder 44 Nederlandse softwareprofessionals, waarin drie nieuwere tools (CodeQL, Infer en Semgrep) worden vergeleken met SonarQube. De conclusies zijn nuchter: maatwerk-detectieregels voegen veel toe en tools vullen elkaar aan, dus geen enkele tool dekt alles. Wij trekken uit dat begrensde onderzoek geen conclusies over alle Nederlandse bedrijven of alle tools. Wel ondersteunt het wat practitioners al langer weten: een scanner is een hulpmiddel voor een reviewer, geen vervanging.

De praktische les: koppel iedere geautomatiseerde bevinding aan een eigenaar en een termijn, leg vast wanneer een bevinding een release blokkeert en beoordeel uitzonderingen periodiek opnieuw. Dat is organisatiewerk, en precies daarom hoort het bij eigenaarschap en niet bij tooling.

Welke rol heb je nodig?

Niet ieder team heeft elke rol nodig, en zeker niet tegelijk. Deze beslismatrix helpt je bepalen welk profiel past bij het gat dat je werkelijk hebt. Per rol: wanneer passend, wanneer onvoldoende en welke interne eigenaar er altijd blijft.

Developer

Passend voor: veilig implementeren, dependencyupdates uitvoeren, code review doen en herstelwerk binnen de eigen codebase. Onvoldoende wanneer: er niemand is die richting geeft aan wat veilig genoeg is, of wanneer het probleem in de pipeline of infrastructuur zit. Interne eigenaar die blijft: de tech lead, die reviewregels en prioriteiten bewaakt.

QA/Test Automation Engineer

Passend voor: herhaalbare functionele, integratie-, API-, regressie- en end-to-endtests, inclusief securitygerelateerde scenario's zoals rechten tussen gebruikers. Onvoldoende wanneer: je verwacht dat testautomatisering automatisch application security dekt; een QA-engineer is niet automatisch een application-securityspecialist. Interne eigenaar die blijft: de product owner, die bepaalt welke risico's getest moeten worden.

DevSecOps Engineer

Passend voor: securitycontroles in CI/CD, dependency- en imagecontrole, secrets, deploymentregels, cloud- of containerconfiguratie en het bruikbaar maken van bevindingen voor developers. Onvoldoende wanneer: het probleem in de applicatiecode of de architectuur zit, of wanneer er geen pipeline is om controls in te plaatsen. Interne eigenaar die blijft: de platform- of technische eigenaar die beslist welke bevindingen een release blokkeren.

Application Security Specialist

Passend voor: threat modelling, securityrequirements, complexe code- of architectuurbeoordeling en het begeleiden van secure-developmentpraktijken in teams. Onvoldoende wanneer: er geen developmentcapaciteit is om de bevindingen ook op te lossen. Interne eigenaar die blijft: de technische leiding, die de aanbevelingen vertaalt naar de roadmap.

Pentester

Passend voor: een onafhankelijke, afgebakende beoordeling van een draaiende applicatie of omgeving, bijvoorbeeld voor een grote release of op verzoek van een klant. Onvoldoende wanneer: je continue zekerheid zoekt; een pentest is een momentopname en zegt niets over de release van volgende week. Interne eigenaar die blijft: degene die de bevindingen ontvangt, prioriteert en laat oplossen.

Bewust benoemd: dit is een beslismatrix voor jouw organisatie, geen aanbod. tre plus levert niet standaard al deze rollen. Waar wij wel capaciteit toevoegen, staat verderop in deze gids.

Een minimum viable securityproces

Voor een productteam zonder eigen securityafdeling is dit een realistisch basismodel. Het is een praktisch groeimodel van tre plus: geen certificering, en niet de officiële niveaus van OWASP SAMM. Wie een erkend volwassenheidsmodel zoekt, kan SAMM gebruiken om de eigen situatie te toetsen en te vergelijken.

Basis

Wijs een eigenaar aan voor security in het ontwikkelproces. Draai op ondersteunde runtimes en houd dependencies bij. Maak review verplicht voor iedere wijziging. Houd geheimen buiten de code. Draai automatische tests bij iedere build. Leg een urgente patchprocedure vast: wie beslist, wie voert uit, wie controleert.

Herhaalbaar

Leg securityrequirements vast bij risicovolle wijzigingen. Plaats SAST, SCA en secret scanning in de CI-pipeline. Houd een dependency-inventaris bij. Maak de build reproduceerbaar. Leg releasecriteria vast, inclusief wanneer een bevinding een release blokkeert. Geef iedere bevinding een eigenaar en een termijn.

Verdiept

Voer threat modelling uit voor de onderdelen met de hoogste impact. Baseer requirements op ASVS voor de delen die voor jou gelden. Voeg DAST of API-securitytests toe tegen een draaiende testomgeving. Onderhoud een SBOM. Laat periodiek een onafhankelijke test of pentest uitvoeren. Evalueer uitzonderingen en incidenten periodiek, zodat tijdelijke maatregelen niet permanent worden.

De volgorde is bewust: eerst eigenaarschap en basisgewoonten, dan automatisering, dan verdieping. Een team dat op Basis staat en dat consequent doet, staat er beter voor dan een team met dure tools op Verdiept en geen eigenaar voor de bevindingen.

De eerste dertig dagen

Een nuchter startplan voor een team dat vandaag begint. Het levert geen garantie dat je organisatie veilig of compliant is; het levert een werkend begin met een eigenaar.

Week 1: inventariseer je kritieke applicaties, de runtimes en dependencies waar ze op draaien en de eigenaren per onderdeel. Neem oudere omgevingen en losse containers mee; die worden het vaakst vergeten.

Week 2: leg reviewregels, updatebeleid en de minimale geautomatiseerde controles vast. Schrijf op wie toekomstige runtime- en dependencyupdates volgt, beslist en valideert.

Week 3: plaats de controles in CI/CD en bepaal de verantwoordelijkheden voor bevindingen: wie krijgt ze, wie beoordeelt ze, binnen welke termijn.

Week 4: toets één kritieke releaseflow of applicatie tegen het nieuwe proces en stel bij. Wat bleek onwerkbare administratie? Welke bevinding had geen eigenaar? Pas het proces aan, niet de werkelijkheid.

Wat het PHP-incident hiervan laat zien

In oktober 2026 publiceerde PHP patches voor twee kritieke kwetsbaarheden in de runtime zelf. De technische details laten we hier bewust weg; die staan in ons artikel over de kritieke PHP-kwetsbaarheden van oktober 2026. Hier gaat het om wat het incident laat zien over de inrichting van je ontwikkelproces.

De kwetsbaarheid zat onder de applicatiecode, in de runtime. Plugin-, Composer- of applicatieupdates werken de PHP-runtime niet automatisch bij, dus een team dat alleen de applicatie bijwerkt, blijft kwetsbaar zonder het te merken. Dat is precies het gat dat een dependency- en runtime-inventaris dicht: je moet weten welke runtimes in productie draaien en welke versies daarvan ondersteund zijn.

Het tweede punt is eigenaarschap. Bij veel organisaties zit de runtime tussen productteam, hostingpartij en leverancier in, en bleek bij dit incident niemand zich eigenaar te voelen van de vraag of PHP gepatcht was. Die verdeling moet vooraf duidelijk zijn, niet tijdens een spoedupdate.

Het derde punt is dat tijdelijke maatregelen patching niet vervangen. De officiële mitigaties bij dit incident waren expliciet onvolledig. Wie tijdelijke maatregelen als oplossing behandelt, bouwt een permanente uitzondering. Precies daarom hoort de periodieke evaluatie van uitzonderingen in het verdiepingsniveau van het groeimodel hierboven.

AI-gegenereerde code

Eén compacte paragraaf, want dit onderwerp verdient geen aparte hype. AI kan codeproductie versnellen, maar neemt verantwoordelijkheid niet over. Gegenereerde code doorloopt dezelfde review-, test- en securityeisen als handgeschreven code. Een plausibel antwoord is geen bewijs van correcte autorisatie, dataverwerking of foutafhandeling: modellen produceren code die er goed uitziet en toch een verkeerde aanname kan bevatten.

AI kan ook helpen bij analyse en testvoorstellen, bijvoorbeeld bij het bedenken van randgevallen of het lezen van een onbekende codebase. Ook die uitkomsten moeten worden gecontroleerd. De bredere vraag wat AI betekent voor de samenstelling van developmentteams behandelen we in ons artikel over AI en nearshore development.

Waar tre plus wel en niet past

tre plus is een nearshore developmentpartner, geen cybersecuritybedrijf. Waar wij capaciteit toevoegen: developers die binnen het bestaande klantteam werken, QA- en testautomationcapaciteit, en DevOps- of DevSecOps-capaciteit wanneer het profiel aantoonbaar aansluit bij het werk. Structureel onderhoud, testen, review en CI/CD horen bij ons bij het developmentwerk zelf. De klant behoudt altijd de roadmap, de architectuur, de toegang en de technische richting.

Waar wij nadrukkelijk niet passen: een SOC of 24/7 securitymonitoring, managed detection and response, incident response of forensics, een onafhankelijk pentestcertificaat, een complianceaudit, NIS2-, AVG- of andere juridische garanties, een eenmalige securityscan als los product en volledige resultaatverantwoordelijkheid voor een afgebakend securityproject. Voor dat werk zijn gespecialiseerde partijen de juiste keuze.

Wil je weten hoe samenwerking met ons er praktisch uitziet, dan staan de modellen op onze dienstenpagina, met de details bij Developer as a Service en Team as a Service. Specifiek voor PHP-teams staat meer op de pagina over nearshore PHP developers. Lees je dit als engineering leader, dan is de pagina voor engineering leaders geschreven voor jouw vragen. En wie een bredere vergelijking van nearshore-partners maakt, kan onze buyer guide voor het kiezen van een nearshore-partner gebruiken.

Checklist voor engineering leaders

Vijftien vragen om je eigen situatie te toetsen. Geen formulier, geen download: print ze of neem ze mee naar je volgende teamoverleg.

1. Weten we welke runtimes en dependencies er in productie draaien?

2. Is duidelijk wie kritieke updates uitvoert?

3. Zijn securityrequirements gekoppeld aan productrisico's?

4. Wordt iedere wijziging gereviewd door een tweede developer?

5. Zijn geautomatiseerde bevindingen toegewezen aan een eigenaar?

6. Kunnen we aantonen welke versie momenteel draait?

7. Hebben we vastgelegd wanneer een release moet stoppen?

8. Weten we wie handelt bij een ernstige kwetsbaarheid?

9. Worden tijdelijke uitzonderingen opnieuw beoordeeld?

10. Weten we wanneer onafhankelijke verificatie nodig is?

11. Staan geheimen buiten de code en de logs?

12. Draaien we op ondersteunde versies van runtimes en frameworks?

13. Is er een geoefende procedure voor urgente patches?

14. Weet het team welke data niet in externe tools hoort?

15. Is per fase van de levenscyclus benoemd wie uitvoert, wie beslist en wie verifieert?

Beantwoord je een vraag met "dat moeten we even uitzoeken", dan heb je je eerste actiepunt. Begin bij eigenaarschap, niet bij tooling.

Veelgestelde vragen

Wat is secure software development?

Het inbouwen van veiligheid in het hele ontwikkelproces, van requirements tot productiebeheer, in plaats van één controle aan het einde. Eigenaarschap, eisen, code, dependencies, build, tests en deployment doen allemaal mee.

Is DevSecOps hetzelfde als secure software development?

Nee. DevSecOps gaat over securitycontroles in de build- en deploymentpipeline. Secure software development is breder: het omvat ook requirements, ontwerp, code review en productiebeheer. DevSecOps is een deelgebied, geen synoniem.

Wat is het verschil tussen SAST, DAST en SCA?

SAST onderzoekt broncode zonder de applicatie uit te voeren. DAST test het gedrag van een draaiende applicatie van buitenaf. SCA onderzoekt welke componenten je gebruikt en welke bekende kwetsbaarheden daarin zitten. Ze vinden verschillende dingen en vullen elkaar aan.

Is een pentest voldoende?

Nee. Een pentest is een momentopname van een draaiende applicatie, waardevol als onafhankelijke controle maar geen vervanging voor continue controles in het ontwikkelproces. De release van volgende week valt buiten de scope van de pentest van vorige maand.

Heeft ieder team een security engineer nodig?

Nee. Kleine productteams komen vaak ver met een benoemde eigenaar, goede reviewgewoonten, basiscontroles in de pipeline en een duidelijke patchprocedure. Een application-securityspecialist wordt passend bij hogere risico's, strengere eisen van klanten of complexe architecturen.

Wat is het verschil tussen QA en security testing?

QA controleert of de software doet wat hij moet doen. Security testing controleert of hij niets doet wat hij niet moet doen. Een QA-engineer kan securityscenario's automatiseren, maar is daarmee niet automatisch een application-securityspecialist.

Hoe begin je zonder eigen securityafdeling?

Begin met eigenaarschap: wijs iemand aan, inventariseer runtimes en dependencies, maak review verplicht en leg een urgente patchprocedure vast. Automatiseer daarna de basiscontroles in de pipeline. Het 30-dagenplan in deze gids geeft een concrete volgorde.