Werken als Application Security Engineer

Wat doet een Application Security Engineer?

Een Application Security Engineer zorgt dat software veilig wordt gebouwd en onderhouden, door beveiliging mee te nemen in ontwerp, code, het bouwproces en de reactie op meldingen. De rol hoort bij het vakgebied cybersecurity en draait om application security, dus om de beveiliging van de applicaties die een organisatie zelf bouwt. De titel is vakduiding. Het ECSF van ENISA, uitgegeven in september 2022, kent twaalf rolprofielen en geen profiel met de naam Application Security Engineer. Bij sommige organisaties heet de functie Product Security Engineer of Software Security Engineer.

Volgens de inhoud ligt de functie het dichtst bij het ECSF-profiel Cybersecurity Implementer. Dat profiel noemt als alternatieve titels onder meer Cybersecurity Developer, Cybersecurity Engineer en Development, Security & Operations (DevSecOps) Engineer. Het gaat om het ontwikkelen, uitrollen en beheren van cybersecurityoplossingen op infrastructuren en producten.

Neem een team dat een nieuwe betaalfunctie bouwt in een webapplicatie. In het ontwerp vraagt de Application Security Engineer wie welke gegevens mag zien, wat er gebeurt als iemand het webadres aanpast en wat er gebeurt als het systeem van een leverancier uitvalt. Tijdens het bouwen helpt de engineer een controle in het bouwproces in te richten die onveilige onderdelen en bekende zwakke plekken in gebruikte bibliotheken markeert. Bij de code die gevoelige gegevens verwerkt, kijkt de engineer mee. Aan een ontwikkelaar legt de engineer uit waarom een zoekopdracht naar de database de invoer van gebruikers niet ongecontroleerd mag overnemen, want dan ontstaat een injectierisico. Daarna houdt de engineer bij welke bevindingen nog openstaan.

Waar in het bouwproces werkt een Application Security Engineer?

De engineer werkt langs het hele bouwproces, van de eisen tot de meldingen die na een uitgave binnenkomen:

1. Eisen en ontwerp. Wat moet de applicatie beschermen, en welke aanvallen zijn denkbaar? Dat is threat modelling, een methode om die vraag systematisch te beantwoorden.
2. Code schrijven. Richtlijnen voor veilig programmeren en een codereview van de gevoelige delen.
3. Bouwen en controleren. Automatische controles die in de bouwstraat draaien en bevindingen vroeg zichtbaar maken.
4. Testen. Testen op kwetsbaarheden, soms door een Penetration Tester die het werk aanvult.
5. Uitbrengen. Controleren of de applicatie veilig is ingesteld voordat die live gaat.
6. Na uitbrengen. Meldingen van kwetsbaarheden afhandelen en onderdelen bijwerken.

Twee kaders helpen om dit werk te structureren. Het Secure Software Development Framework van NIST groepeert de werkwijzen in vier groepen: Prepare the Organization, Protect the Software, Produce Well-Secured Software en Respond to Vulnerabilities. OWASP SAMM kent vijf business functions: Governance, Design, Implementation, Verification en Operations. De verdeling van het werk verschilt per organisatie. Bij de ene leunt de rol meer op ontwerp, bij de andere meer op testen.

Welke taken horen bij de functie?

Er is geen officiële taaklijst voor deze titel. De dichtstbijzijnde bron is het profiel Cybersecurity Implementer uit het ECSF van ENISA, aangevuld met "code beoordelen op veiligheid" uit het profiel Penetration Tester. Dit is dus geen officiële taakomschrijving, maar een overzicht van de profielen die er het meest op lijken. Daaruit komen onder meer deze taken:

• veilige werkwijzen opzetten en uitleggen aan de teams die ermee werken
• systemen, diensten en producten veilig configureren
• controles in het bouwproces inrichten en bewaken dat de maatregelen worden uitgevoerd
• code en ontwerp beoordelen op veiligheid
• bevindingen documenteren, prioriteren en opvolgen
• patches voor gebruikte onderdelen beheren om technische kwetsbaarheden aan te pakken
• nauw samenwerken met IT- en OT-medewerkers

Welke skills heb je nodig?

Het technische deel bestaat uit deze vaardigheden:

• Programmeren en code lezen. Je schrijft scripts en leest code van anderen, zodat je bij een codereview ziet dat een functie gebruikersinvoer ongecontroleerd doorgeeft.
• Webapplicaties en API's. Je weet hoe inloggen, sessies, toegangsrechten en invoercontrole werken, zodat je ziet waar een controle ontbreekt.
• Secure coding. Je kent richtlijnen voor veilig programmeren en past ze toe op het werk van een ontwikkelaar.
• Kwetsbaarheden herkennen. Je ziet aan een stuk code of een gedrag wat er mis kan gaan.
• Automatiseren in een bouwproces. Je zet een controle op die bij elke wijziging draait, zodat de feedback snel komt.
• Cloud en containers. Je begrijpt de omgeving waarin de applicatie draait, zodat je weet welke instellingen ertoe doen.

Daarnaast heb je niet-technische vaardigheden nodig:

• Uitleggen zonder schuld. Je zegt "deze invoer wordt niet gecontroleerd" en niet "jij hebt dit fout gedaan". Zo blijft het gesprek over de oplossing.
• Prioriteren. Je bepaalt wat nu moet en wat later kan. Een bevinding die gegevens kan lekken gaat voor een kleine stijlfout.
• Onderhandelen. Je bespreekt met het team welke bevinding eerst wordt hersteld, en waarom.
• Samenwerken met deadlines. Een team dat een release moet halen, heeft andere prioriteiten. Je zoekt een oplossing die het team haalbaar vindt.

Een bevinding die in begrijpelijke taal komt, met een voorstel voor de oplossing, wordt vaak sneller opgepakt dan een lijst met alleen codes.

Welke tools, standaarden en kaders horen bij het vak?

Eerst de standaarden. Het zijn hulpmiddelen, geen wetten.

Volgens OWASP is de OWASP Top 10 de referentiestandaard voor de belangrijkste beveiligingsrisico's van webapplicaties. De meest recente uitgave is de Top 10:2025. Drie categorieën die je snel tegenkomt zijn A01:2025 Broken Access Control, A05:2025 Injection en A06:2025 Insecure Design. Gebruik de lijst om te laten zien waar je op let, niet als volledige checklist. Zie de OWASP-pagina over de Top 10.

De Application Security Verification Standard (ASVS) is een kader van beveiligingseisen voor het ontwerpen, ontwikkelen en testen van webapplicaties en webservices. De huidige stabiele versie is ASVS 5.0.0, gepubliceerd op 30 mei 2025. Je gebruikt ASVS om per applicatie vast te leggen welke eisen gelden en om ze te toetsen. Zie asvs.owasp.org.

De Web Security Testing Guide van OWASP is bedoeld voor ontwikkelaars en securityprofessionals die webapplicaties effectief willen testen. Die gids hoort bij het testen van beveiliging. Zie de OWASP-pagina over de testgids.

OWASP SAMM helpt een organisatie bepalen waar haar aanpak van softwarebeveiliging staat en wat de volgende stap is. Het model kent vijf business functions met elk drie beveiligingspraktijken, samen vijftien. Zie owaspsamm.org.

Het Secure Software Development Framework van NIST (SP 800-218, versie 1.1, februari 2022) geeft een reeks werkwijzen voor softwareproducenten. Zie csrc.nist.gov.

Threat modelling is de methode om vooraf te bepalen welke aanvallen denkbaar zijn. Zie de skillpagina voor threat modelling.

Dan het gereedschap, in gewone taal. Scanners controleren broncode en gebruikte bibliotheken op bekende zwakke plekken. Een proxy zoals Burp Suite laat je het verkeer tussen browser en webapplicatie bekijken. Bouwstraten zoals GitHub Actions en GitLab CI draaien de controles bij elke wijziging. Containers draai je met Docker en beheer je op schaal met Kubernetes. Python is handig voor scripts. Dit zijn voorbeelden, geen advies over welk merk je moet kiezen. De vacature noemt de tools die de werkgever gebruikt.

Voor producten met digitale elementen bestaat Europese regelgeving over beveiliging, zie de Cyber Resilience Act.

Welke opleiding en certificeringen passen bij een Application Security Engineer?

Een hbo- of wo-opleiding in ICT, software engineering of security past bij deze functie. De bronnen noemen geen vaste opleidingseis.

ISC2 beschrijft het CSSLP (Certified Secure Software Lifecycle Professional) als certificering voor software- en securityprofessionals die verantwoordelijk zijn voor goede werkwijzen in elke fase van de softwareontwikkelcyclus. ISC2 noemt als vereiste werkervaring 4 jaar. Voor de voorwaarden is de ISC2-pagina leidend.

Uit het testvak komen OSCP en CEH. Ze zijn handig als je ook zelf test. CompTIA Security+ is een brede basis. Vacatures die erom vragen, staan op de skillpagina's voor OSCP, CEH en Security+.

Een certificering vervangt geen ervaring. Of een werkgever er waarde aan hecht, verschilt per organisatie, en de pagina van de uitgever is leidend.

Hoe word je Application Security Engineer?

Een route loopt via softwareontwikkeling. Wie de code en het team al kent, kan collega's al informeel op veiligheid beoordelen. Een tweede route loopt via de Penetration Tester: je vindt bevindingen nu achteraf en wilt ze voorkomen. Een derde route loopt via DevOps of platformwerk: je kent het bouwproces en wilt de controles erin zetten.

Je kunt zelf beginnen met vier stappen:

• Leer de OWASP-materialen, zoals de Top 10 en de testgids.
• Vind en herstel een kwetsbaarheid in een eigen project.
• Zet een eenvoudige beveiligingscontrole op in een bouwproces.
• Schrijf een bevinding op voor een ontwikkelaar, met een voorstel voor de oplossing.

Wat je kunt laten zien helpt: een project met een herstelde kwetsbaarheid, een bouwproces met een controle en een bevinding die helder is opgeschreven. Hoe snel dat tot een functie leidt, valt niet te zeggen.

Waar werk je als Application Security Engineer?

Bij sommige organisaties werk je bij een softwarebedrijf of platform, bij andere bij een organisatie met eigen webapplicaties, zoals een financiële instelling, en bij weer andere bij een adviesbureau. Vacatures per sector staan bij IT, SaaS en technologie, financiële dienstverlening en e-commerce en platforms. Welke werkgevers deze functie zoeken, staat op de werkgeverspagina.

Application Security Engineer of Penetration Tester?

Beide rollen werken aan de beveiliging van applicaties, maar vanaf een andere kant.

Wie graag meebouwt en werkt aan het voorkomen van fouten, past bij de Application Security Engineer. Wie graag een bestaand systeem onderzoekt en de aanvaller nabootst, past bij de Penetration Tester. De rollen vullen elkaar aan, en sommige organisaties laten één persoon beide doen. Lees de rolgids voor de Penetration Tester en de rolgids voor de Ethical Hacker om de andere kant te zien.

Waar groei je naartoe?

• Senior Application Security Engineer of teamlead. Een stap verder in dezelfde rol, bij sommige organisaties met leiding over een team. Zie de vacatures voor Application Security Engineers.
• Security Architect. Je ontwerpt beveiligde oplossingen. Het ECSF-profiel Cybersecurity Architect noemt het inrichten van een veilige omgeving tijdens de ontwikkelcyclus als taak. Zie de vacatures, de rolgids en security architecture.
• Security Engineer. Je werkt breder dan alleen applicaties. Zie de vacatures en de rolgids.
• Cloud Security Engineer. Je beveiligt de omgeving waarin applicaties draaien. Zie de vacatures en de rolgids.
• Penetration Tester. Je test in plaats van mee te bouwen. Zie de vacatures.

Dit is een overzicht van rollen, geen belofte. Welke route openstaat, hangt af van de organisatie en van wat je laat zien. Er is geen baangarantie en geen vaste doorgroeitijd.

Vacatures en werkgevers

Op de vacaturepagina voor Application Security Engineers zie je welke vacatures open staan. Op de werkgeverspagina zie je welke werkgevers deze functie zoeken.