Samenvatting

Shift-Left-on-Security is niet alleen essentieel voor het voorkomen van dure en tijdrovende problemen later in de Software Development Lifecycle, maar het kan ook aantrekkelijk en motiverend worden gemaakt voor developers. Dit whitepaper bespreekt hoe je de transitie succesvol maakt.

Key takeaways:
Verlaag risico’s en bespaar kosten: Vroeg in het proces investeren in security verkleint de kans op incidenten en versnelt releases.
Maak security leuk voor developers: Door spelelementen en uitdagingen toe te voegen, wordt security onderdeel van hun dagelijkse werkplezier.
Overwin organisatie- en team uitdagingen: Creëer eigenaarschap, faciliteer kennisontwikkeling, en pas security best practices consistent toe.
Bevorder samenwerking en innovatie: Gebruik informele discussies, hackathons, en security champions om teams te verbinden en kennis te delen.

Wil je weten hoe BBTG deze aanpak succesvol heeft toegepast en hoe jouw organisatie hier ook van kan profiteren? Lees verder en ontdek de mogelijkheden.

Inleiding

Je hebt waarschijnlijk al gehoord van Shift-Left-on-Security en hoe belangrijk het is*. Misschien heb je zelfs al gekeken hoe je dit kunt toepassen binnen je organisatie of team. Heb je developers security trainingen aangeboden of zelf trainingen gevolgd? Toch blijkt het niet altijd eenvoudig om daadwerkelijk security vroeg in het proces te integreren. Hoe komt dat? In dit whitepaper bespreken we de obstakels en hoe je die kunt overwinnen. Zo maken we security leuker voor developers!

* Hoe meer “naar rechts opschuiven” (later in het proces) des te vervelender en kostbaarder security is, maar bovenal levert het naar links opschuiven (vroeger in het proces) uiteindelijk een hogere business waarde, want het verkleint het risico op beveiligingsincidenten en het bespaart tijd. Volgens DORA besparen teams die security vroeg in het proces integreren tot wel 50% tijd op het oplossen van beveiligingsproblemen.

Left shiften op security loont

Laten we kort herhalen waarom Shift Left on Security zo belangrijk is. Zoals Wouter van Vegchel in zijn whitepaper ‘Beveiligd vanaf de start‘ beschrijft, is het een proactieve aanpak waarbij beveiliging vroeg in de Software Development Lifecycle wordt geïntegreerd. Dit is steeds urgenter geworden, met als belangrijkste conclusie: beveiligingsproblemen achteraf oplossen is duur en complex. Dit komt door drie hoofdoorzaken:

1. Het is moeilijker om bestaande code te repareren.
2. Er staat vaak veel druk op snelle reparaties.
3. Er ontstaat wrijving tussen security experts en developers.

Het oplossen van beveiligingsproblemen is lastiger als je rekening moet houden met bestaande code. Je moet het probleem vinden en ook de code eromheen checken, die mogelijk afhankelijk is. Als de code al live is, staat er vaak druk op om snel te repareren. Dit verhoogt de kans op fouten. Ook als de code nog niet live is, kan er frictie en stress ontstaan als de verantwoordelijkheid voor security buiten het team ligt. Dit zie je vaak in grote organisaties. De aanpak leidt tot twee mogelijke scenario’s: de lat wordt lager gelegd om deadlines te halen, wat experts frustreert en de kwaliteit schaadt, of de release wordt last minute geblokkeerd, wat frustratie veroorzaakt bij de business en developers.

Waarom gebeurt het dan niet (overal)?

Hoewel het duidelijk is waarom we security best practices vroeg in het proces moeten toepassen (zie Wouter van Vegchels whitepaper), wordt er in de praktijk nog niet genoeg naar links opgeschoven. Soms wordt het geprobeerd, maar zonder succes. Dit is niet vreemd, omdat het een verandering vraagt in de werkwijze van zowel de organisatie als de developers. En daar ontstaan obstakels.

De dingen waar je als organisatie tegenaan loopt

Organisaties moeten eerst begrijpen wat non-functionele eisen zijn: alles wat nodig is om software beheersbaar en duurzaam te houden. Denk aan infrastructuur, het build- en releaseproces, leesbare code, flexibele architectuur, en natuurlijk security. Deze eisen zijn vaak lastig meetbaar, waardoor de waarde niet altijd zichtbaar is. Het voelt soms als een kostenpost vooraf, zelfs als het logisch is dat ze nodig zijn.

Dit maakt het moeilijk voor de business om grip te krijgen en leidt ertoe dat er op vertrouwen wordt gewerkt. Als dat vertrouwen nog niet is opgebouwd, kan dit eng zijn om mee te starten. Gelukkig toont onderzoek van DORA aan dat vroeg investeren in security positieve effecten heeft. Ook strengere wetgeving, zoals AVG (GDPR) en AML, dwingt organisaties om hier aandacht aan te geven. Uiteindelijk draait het om vertrouwen opbouwen binnen de business dat deze aanpak loont.

… en waar als je developer of team tegenaan loopt

Als de organisatie de ruimte en prioriteit geeft aan security, kunnen developers aan de slag. Maar waarom gebeurt dat nog niet overal? Er zijn drie belangrijke redenen:

1. Security ligt buiten het team.
2. Kennis ontbreekt in het team.
3. Developers vinden het niet leuk, vooral achteraf niet.

In grote organisaties ligt security vaak bij een Chief Information Security Officer (CISO) en zijn team. Dit zorgt voor minder eigenaarschap bij het developmentteam en creëert een kennisgat. De oplossing is om de verantwoordelijkheid bij het team te leggen en de juiste ondersteuning te bieden om dat gat te dichten. Vooral dat laatste is de uitdaging.

Trainingen zijn hierbij cruciaal. Idealiter kiezen developers zelf hun trainingen, maar een suggestie voor goede trainingen helpt vaak om ze op weg te helpen. Kies iets wat aansluit bij hun manier van leren, zoals online cursussen op eigen tempo. Voor security zijn er veel platforms die met challenges en gamification kennis overbrengen. Zodra developers kennis hebben opgedaan, willen ze die ook toepassen, wat eigenaarschap versterkt.

Maar wat als developers geen interesse hebben om die kennis op te doen, omdat ze het niet leuk vinden? Developers willen vaak het liefst ‘features knallen’ en houden zich minder graag bezig met non-functionele eisen. Dat komt omdat die vaak als ‘niet leuk’ worden ervaren. Idealiter komt de motivatie vanuit de developers zelf. Vaak is dat ook zo, want ze weten dat ze aan security moeten werken om hun software veilig te houden. Maar niet iedereen is altijd even gemotiveerd. In dat geval moet je een manier vinden om ze te laten inzien dat security niet alleen nodig is, maar ook leuk kan zijn.

Maak het leuk!

Zelfs met voldoende budget en kennis blijft het een uitdaging als developers security niet leuk vinden. Plezier is subjectief, maar vaak betekent het werken aan een uitdagend probleem met een duidelijk doel, variatie, beloning en invloed op het resultaat. Ook als je achterloopt op security, kun je het leuk maken.

Hoe doe je dat? Deze onderdelen kunnen helpen:

• Bewustwording: Begin met bewustzijn over het belang van security.
• Security mindset: Laat developers niet alleen aan features denken, maar ook aan mogelijke risico’s. Dit vereist geen technische vaardigheden, dus je kunt direct beginnen.
• Maak het klein: Grote, vervelende taken worden vaak uitgesteld. Deel ze op in kleine, behapbare stukken en maak ze onderdeel van de dagelijkse workflow.
• Gamification: Voeg een spelelement toe om het leuker te maken.
• Kennisdeling: Moedig teams aan om kennis te delen.
• Kennisontwikkeling: Stimuleer het blijven leren over security.
• Ondersteuning van bovenaf: Zorg dat management security als een essentieel onderdeel van het werk ziet, niet als een kostenpost. Geef teams erkenning en waardering.

Informele discussie

Bewustwording begint vaak met een informele discussie. Organiseer bijvoorbeeld een lunch of pizza-sessie om met verschillende teams over security te praten. Je zult merken dat er heel verschillende perspectieven zijn. Zo wordt vanzelf duidelijk waarom security belangrijk is en wat het voor iedereen betekent.

Gebruik deze sessies ook om op een laagdrempelige manier te bespreken hoe je kunt bijdragen aan security, simpelweg door de juiste vragen te stellen. Zo help je om die security mindset te ontwikkelen.

Een bijkomend voordeel: deze gesprekken verbeteren de kennisdeling tussen teams. Vaak komen er ook ‘war stories’ voorbij – ervaringen met securityproblemen – die het onderwerp levendiger maken en mensen enthousiast maken. Bij BBTG hebben we hier goede ervaringen mee!

Threat modelling

Threat modelling is een proactieve aanpak om potentiële risico’s en kwetsbaarheden in software te identificeren en te analyseren. Elk risico krijgt een score, zodat het team objectief kan prioriteren.

Voeg regelmatig threat modelling sessies toe aan je sprint. Dit kan saai zijn, maar ook leuk. Probeer mensen te enthousiasmeren met uitdagende vragen. Uit ervaring weten we dat de beste sessies ontstaan met vragen als:

• “Hoe kunnen we als team hier stinkend rijk van worden?”
• “Hoe kunnen we de naam van de organisatie door het slijk halen?”
• “Hoe zou je wraak nemen als je als developer met een achterbakse reden ontslagen zou worden
• “Kunnen we onze app gebruiken om chaos te creëren in de organisatie?”

Begin met de eigen code van het team, maar laat ook collega’s van andere teams meekijken. Een frisse blik helpt vaak. Zo deel je meteen kennis en ervaring (“Wij hadden een vergelijkbare kwetsbaarheid en hebben het zo opgelost”). Dit versterkt ook de onderlinge band en maakt toekomstige hulpvragen makkelijker.

Interne hackathon

Developers kennen de software vaak beter dan wie dan ook. Ze weten precies waar de zwakke plekken zitten. Maak hier gebruik van door een interne hackathon te organiseren. Laat teams proberen elkaars applicaties te hacken of misbruiken, eventueel met een rollenspel vanuit threat modelling. Voeg een competitief element toe, zoals een prijs, bijvoorbeeld een teamuitje of een lunch, en maak er een teambuildingactiviteit van.

Een bijkomend voordeel is dat je direct feedback krijgt op je code. Door alle bevindingen van teams te verzamelen, kun je veelvoorkomende problemen en kennisgaten identificeren. Dit biedt kansen voor verdere kennisontwikkeling of om tools aan te schaffen die deze issues systematisch aanpakken.
Hackathons zijn ideaal voor op een andere locatie en werken ook uitstekend als teambuilding events.

Bug bounty programma

Een stap verder dan een interne hackathon is een bug bounty programma. Hierbij nodig je externe experts uit om beveiligingsbugs in jullie applicaties op te sporen. Meestal wordt er een financiële beloning gegeven, afhankelijk van de ernst van de gevonden kwetsbaarheid.

Je kunt zo’n programma ook intern opzetten. Zorg dan wel voor duidelijke afspraken, zodat iedereen (developers, management, etc.) weet waar ze aan toe zijn. Dit voorkomt problemen zoals het ‘cobra effect’ (bewust bugs inbouwen).

Sommige bedrijven geven een deel van de beloning aan de medewerker die de bug vond. Het resterende bedrag kan naar een goed doel, of in een pot voor een feest zodra er een bepaald bedrag is verzameld.

Post mortem

Ondanks goede voorbereidingen kan er altijd iets misgaan. Dit is vervelend, maar biedt ook een kans om te leren en beter te worden. Het is belangrijk om niet naar elkaar te wijzen, want dan wil niemand verantwoordelijkheid nemen. In plaats daarvan moet je ervan leren door een post-mortem te doen.

Bij een post-mortem schrijf je op wat er misging en hoe het kon gebeuren. Je documenteert de impact van het incident en de genomen stappen om het op te lossen. De vraag “hoe heeft dit kunnen gebeuren” (root cause) wordt zo volledig mogelijk beantwoord. Daarnaast stel je concrete acties voor om herhaling te voorkomen. Zo zet je een negatieve gebeurtenis om in iets positiefs.

Laat het team deze lessen delen met de rest van de ontwikkelaars en de organisatie, zodra het probleem is opgelost. Op deze manier draag je de kennis breed uit en verbeter je het proces structureel.

Security champions faciliteren

Niet iedereen heeft affiniteit met security, en dat hoeft ook niet. Maar geef de mensen die hier wel enthousiast over zijn de ruimte. Misschien willen ze een workshop organiseren of een voorstel doen voor een nieuwe security feature. Deze ‘security champions’ hebben vaak meer impact binnen hun team dan een melding tijdens een bedrijfspresentatie of op een slide.

Geef deze mensen erkenning en waardering. Dit kan financieel, maar het hoeft niet. Benoem hun bijdrage tijdens een company call of geef ze de kans om een congres of training te volgen. Ze zullen dit waarderen en de opgedane kennis weer meenemen naar hun werk.

Zorg dat security champions onderling kennis kunnen uitwisselen en bijvoorbeeld een lijst van best practices en aanbevolen trainingen opstellen. Door ze goed over de organisatie te verdelen, voorkom je dat ze op een eilandje werken. Zo kunnen ze anderen binnen de organisatie stimuleren om vaker over security na te denken.

En wat dan nu?

Het is niet eenvoudig om security leuk te maken, en de aanpak kan per organisatie of team verschillen. Het belangrijkste is om gewoon te beginnen. Nodig een groep developers uit voor een lunch of pizzasessie en kijk welke ideeën er zijn. Is er motivatie om kennis op te doen? Zorg dan dat je met de juiste mensen verder gaat.

Bij BBTG hebben we deze transformatie ook doorgemaakt. We hebben nu een security community waar kennis gedeeld wordt en casussen worden besproken. Bij onze klanten helpen we continu de security mindset te verbeteren. Wil je security bij jouw organisatie naar een hoger niveau tillen? Neem vandaag nog contact met ons op, en samen maken we van security niet alleen een noodzaak, maar iets waar je team enthousiast van wordt!

‍