Beveiliging is voor applicaties van iedere grootte een uitdaging: niet alleen bleken dit jaar tienduizenden Android-apps gebruikersdata te lekken, maar ook duizenden grotere softwareprogramma’s zijn kwetsbaar. Uit het recente State of Software Security-rapport van Veracode bleek dat maar liefst 76% van 130.000 gescande applicaties minstens één beveiligingslek heeft.
Hoe komt het dat dit percentage zo hoog ligt? Het is makkelijk om naar de ontwikkelaars te wijzen, maar de waarheid zit anders in elkaar. Applicatiebeveiliging is namelijk te beschrijven in termen van nature en nurture. Met andere woorden: ontwikkelaars hebben niet op alle aspecten van applicatiebeveiliging invloed. Maar ze moeten er wel mee leren werken.
Nature: de aard van het beestje
Net zoals je geen invloed hebt op je genen, hebben ontwikkelaars geen invloed op bepaalde aspecten van hun organisatie. Denk aan de grootte van een organisatie, hoe oud en hoe groot de applicatie is waar ze aan werken, of de security debt van een bestaande applicatie.
De uitdaging is dat deze aspecten applicatiebeveiliging significant kunnen bemoeilijken. Een grote organisatie vertraagt het verhelpen van kwetsbaarheden met gemiddeld 12 dagen. En werken ontwikkelaars aan een grote applicatie? Dan zijn ze gemiddeld maar liefst 49 dagen langer bezig om een kwetsbaarheid te verhelpen.
Nurture: een goede opvoeding
Tegenover deze vertragende factoren staan gelukkig een reeks aan beveiligingsaspecten waar ontwikkelaars wél invloed op hebben. Hoe vaak en met welke intervallen ze de applicatie scannen op kwetsbaarheden bijvoorbeeld, of de scantypes die ze gebruiken. Bij applicaties die maar een handjevol keer worden gescand, duurt het gemiddeld 217 dagen om de helft van alle openstaande kwetsbaarheden te verhelpen (de halveringstijd). Wanneer applicaties dagelijks worden gescand, dan gebeurt dit ruim een derde sneller.
Daarnaast hebben keuzes tijdens het ontwikkelen een directe impact op het aantal kwetsbaarheden. Externe libraries kunnen een ernstige risicofactor zijn: zo heb je door het gebruik van een willekeurige PHP-library meer dan 50% kans om een veiligheidsfout te introduceren.
Het conflict tussen nature en nurture
Niet alle nature-uitdagingen zijn makkelijk te compenseren met nurture-initiatieven. Een grote legacy-applicatie voegt gemiddeld 57 dagen vertraging toe aan de halveringstijd van openstaande kwetsbaarheden. Een hoge security debt voegt daar gemiddeld 63 dagen aan toe. Zelfs als je alle best practices qua scanning implementeert, wordt 50% van de openstaande kwetsbaarheden in 13 dagen verholpen, terwijl het gebruik van bad practices betekent dat dit bijna twee keer zo lang duurt.
De ideale omgeving voor applicatiebeveiliging is een kleine organisatie met een team dat werkt aan een kleine applicatie. Helaas is dit voor veel organisaties niet realistisch, met name in Europa. In Europa gevestigde organisaties zijn bij het verhelpen van kwetsbaarheden 31 dagen langzamer dan organisaties in andere delen van de wereld.
Die vertraging is vooral toe te schrijven aan organisatorische aspecten en het type applicaties waaraan wordt gewerkt. Vergeleken met andere delen van de wereld, zijn de Europese organisaties die in het onderzoek zijn geanalyseerd de grootste die zijn opgenomen in het rapport, en werken zij ook nog eens aan zeer grote applicaties. Europese ontwikkelaars werken daardoor vaker met legacy codebases.
Ondanks deze uitdagingen, zijn Europese organisaties fervente gebruikers van DevSecOps-technieken, waardoor zij voorop lopen op het gebied van scancadans, software composition analysis (SCA) en dynamic analysis (DAST). Hoewel er dus nog een lange weg te gaan is voordat de historische bagage van grote organisaties en legacy-applicaties wordt overwonnen, worden er genoeg stappen in de goede richting gemaakt.
Weg van nature-uitdagingen
Het is zoals gezegd mogelijk om zelfs gigantische, verouderde applicaties met een enorme security debt door te ontwikkelen en te verbeteren. Naast verschillende scantechnologieën en een hogere scanfrequentie, zijn er ook stappen die genomen kunnen worden om het nature-aspect te verbeteren. Bestaande applicaties kunnen bijvoorbeeld worden opgedeeld in kleinere stukken, waardoor ieder individueel component beter te beveiligen is.
Maar dit soort beslissingen liggen niet altijd bij de developers. Het zijn beslissingen die breed moeten worden gedragen door de organisatie. Zo moet de product roadmap ruimte bieden voor initiatieven om de security debt te verminderen. En dat is niet altijd een makkelijke discussie, aangezien het op korte termijn impact kan hebben op de bedrijfsresultaten.
Een applicatie hoeft niet perfect te zijn, of vanaf versie één volledig veilig te zijn. Dat is een illusie. Wat organisaties wél moeten doen, is een balans vinden tussen applicatiebeveiliging en zakelijke overwegingen zoals time-to-market. Wanneer applicatiebeveiliging in die vergelijking het onderspit delft, blijft de security debt zich ophopen en wordt applicatiebeveiliging uiteindelijk nóg uitdagender. Het is dus belangrijk om te onthouden dat er voor organisaties áltijdmogelijkheden tot hun beschikking zijn die de veiligheid van hun applicaties zo vroeg mogelijk kunnen verbeteren.
Dit is een ingezonden bijdrage van Julian Totzek-Hallhuber, Senior Principal Solution Architect bij Veracode. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.
18 uur geleden
