3min

Security van applicaties is steeds vaker een onderwerp van gesprek. Want wie is ervoor verantwoordelijk? Het security team? De gebruiker? Of moet security al tijdens de applicatie-ontwikkeling worden meegenomen en is de developer verantwoordelijk? Duidelijk is dat developers de beveiliging letterlijk kunnen maken of breken. Daarom is het belangrijk om te zorgen dat zij zich bewust zijn van het feit dat security al in de code begint, dat hun kennis up-to-date moet zijn om fouten te vermijden en dat testen en go-no-go-momenten meerdere malen in de app productie- en levenscyclus voorkomen. Dat was altijd al zo, maar security checks moeten daarin meegenomen worden en kunnen zelfs een bepalende factor zijn.

Laten we even stil staan bij de huidige trends in applicatiebeveiliging. De benadering van applicatie security wordt steeds holistischer, er is behoefte aan het beveiligen van de complete software supply chain omdat kwetsbaarheden anders kunnen uitgroeien tot aanvallen van ongekende grootte. Een bekend voorbeeld is de kwetsbaarheid in Apache Log4j software, die door veel verschillende applicaties wordt gebruikt. Aanvallers kregen de mogelijkheid de rechten van webservers en andere systemen waarin deze software is verwerkt (ongeveer een kwart van alle websites draait op Apache!) op afstand te misbruiken. Daarnaast is de vraag naar API-security momenteel groter dan ooit. Gartner zegt dat in 2023 meer dan 50% van de B2B transacties plaatsvindt door middel van real-time APIs. Applicatie security moet overal in het ontwikkelproces verankerd worden, we zien een verandering van ‘shift left’ naar ‘shift everywhere’ met toenemende focus op cloud-native AppSec. Developers krijgen hierdoor een steeds belangrijkere rol in het securityproces!

Organisaties moeten een veilige omgeving creëren waarin developers applicaties kunnen ontwikkelen en veilige code kunnen schrijven. Daarvoor moeten zij de omgeving maar ook de developer begrijpen. Het speelveld waarin het security team en developers zich begeven is bij iedere organisatie anders.

Een grote overheidsinstelling maakte bijvoorbeeld nog gebruik van een old-school security gate, waarbij ze een penetratietest tijdig moesten aanvragen, maar het wel zes maanden kon duren voordat ze feedback kregen. Dit hebben ze aangevuld met SAST- en DAST-technologie van Fortify, waardoor ze nu veel sneller inzicht hebben in de risico’s van de code. In het team is een AppSec security champion actief; een developer die van security houdt en ervoor zorgt dat de code die wordt opgeleverd en in productie gaat veilig is.

Een Nederlandse bank transformeert naar een digitale bank. Bij het ontwikkelen van de software die hiervoor nodig is, heeft de bank besloten om security in iedere stap van het proces mee te nemen en zo tot secure coding, met als gevolg een veilige applicatie, te komen. De levenscyclus van een regel code is vastgelegd en de code wordt al in een vroeg stadium aan testen onderworpen. Het fixen van een bug als de app al in productie is genomen kost immers veel meer. Maar welke tools geeft deze bank aan de developers zodat zij secure code kunnen schrijven? Zij krijgen lokaal de mogelijkheid om te scannen, zodat hun code tijdens het schrijven al geanalyseerd wordt, waardoor deze – indien nodig – direct aangepast kan worden. Ook kunnen zij op aanvraag hun code laten reviewen. Developers worden zich op deze manier steeds meer bewust van (het belang van) secure coding.   

Lees ook: Applicatiebeveiliging moet in de haarvaten van de organisatie zitten

Organisaties proberen constant grenzen te verleggen maar erkennen ook dat de snelheid van het testen van applicatiebeveiliging niet belangrijker kan zijn dan de grondigheid en kwaliteit van code security. Zij moeten de juiste balans vinden tussen innoveren om de business te laten groeien en het verkleinen van risico’s in software. Een secure developer helpt daarbij en voorkomt dat applicatiebeveiliging de bedrijfsvoering verlamt.

Meer weten? De CyberRes 2022 Appsec Trend Webinar Series gaan dieper in op de diverse actuele trends.