Nooit bevatte code meer kwetsbaarheden. Logisch, want nooit was er meer code, maar toch groeit het risico asymmetrisch. In het jaar 2000 waren er amper 1.020 geregistreerde CVE-kwetsbaarheden. In 2010 waren dat er niet zo heel veel meer: 4.155. In 2017 explodeerde dat aantal tot 14.714 CVE’s, komende van 6.454 een jaar eerder. En in 2021 werden er maar liefst 20.149 nieuwe kwetsbaarheden gedetecteerd.

Niet iedere softwarebug is even ernstig, maar de cijfers tonen aan dat het aantal lekken in software sterk toeneemt. Bovendien is het geen geheim dat organisaties niet altijd even snel zijn met de installatie van belangrijke patches, waardoor ook oudere kwetsbaarheden blijven nazinderen. Bedenk daar nog bij dat criminele cyberorganisaties vandaag de vorm aannemen van heuse georganiseerde bedrijven met een stevige honger naar winst, en je begrijpt waarom het belangrijker is dan ooit om je code waterdicht te maken.

1. Volg de regels van de kunst

Dat is gemakkelijker gezegd dan gedaan. Als ontwikkelaar kan je je eerst en vooral aan enkele best practices houden. Sommige bugs vloeien voort uit luiheid en kunnen eenvoudig vermeden worden. Bouw je een applicatie die input van gebruikers verwerkt? Zorg er dan voor dat al die input goed gevalideerd wordt. SQL-injectie is een veelvoorkomend en gevaarlijk euvel.

Zorg verder voor kwalitatieve foutmeldingen, voldoende encryptie voor gevoelige data, HTTPS als standaard bij webpagina’s, een veilig inlogsysteem wanneer toepasselijk, … Voor een gebruiker die getrakteerd wordt op de melding ‘je wachtwoord is te lang’, bestaat geen excuus meer. Iedereen maakt fouten, maar door veiligheid bij het schrijven van een toepassing vanaf het begin in het achterhoofd te houden, kom je al een heel eind.

2. Kwetsbare dependencies

De gevaarlijkste kwetsbaarheden zijn echter niet jouw schuld. De meeste toepassingen vertrouwen op populaire externe bibliotheken. Wanneer daar een zero day insluipt, is het hek van de dam. Denk maar aan de onschuldige logbibliotheek Log4j, waarin de Log4Shell kwetsbaarheid de halve wereld plots blootstelde aan cybercriminelen.

Zelf alle externe bibliotheken analyseren is natuurlijk onbegonnen werk. Gelukkig bestaan er tooltjes om je te helpen. Die tonen via geautomatiseerde scans aan wanneer je toepassing vertrouwt op een bibliotheek met een gekende kwetsbaarheid. Daarbij kijken de beveiligingsoplossingen niet noodzakelijk naar de code zelf, maar checken ze of de opensource-componenten wel te vertrouwen zijn. Die oude versie van Log4j integreer je misschien toch maar beter niet.

3. Eigen code scannen

Dergelijke geautomatiseerde tools bestaan ook voor je eigen code. De oplossingen komen van zowel klassieke beveiligingsbedrijven als gespecialiseerde partijen. Ze zijn in staat om veelvoorkomende fouten te vinden die je op een drukke dag misschien zelf over het hoofd zou zien. Dat kan in het GitHub-repository waar je project geparkeerd staat, of rechtstreeks in je IDE. Zo zet je fouten recht nog voor je code gecompileerd is, en al zeker voor ze in productie terechtkomt. Voorkomen kost minder tijd dan genezen. Bijkomend voordeel: sommige tools suggereren ook meteen een oplossing.

Tot slot ga je er best vanuit dat zelfs best practices en handige tools geen absolute zekerheid bieden. Hoe veiliger de omgeving waarin je app draait is, en hoe beter de configuratie rondom, hoe kleiner de kans dat er iets drastisch misloopt. Die samenwerking tussen ontwikkelaar en het operationele IT-team op het vlak van security is ook een deel van DevOps. Wanneer iedereen zijn verantwoordelijkheid neemt en best practices volgt, is de kans kleiner dat er iets misloopt.

4. Meer dan een pleister

En tot slot: als er toch ergens een component een bug heeft, of je maakte zelf een fout: patch dan onmiddellijk, maar klap daarna niet meteen de laptop dicht. Is de kern van het probleem aangepakt met de patch? Of plakte je een pleister op de wonde? Recent onderzoek van Google Project Zero bracht aan het licht dat de helft van de zero days ontdekt in de eerste helft van 2022 een variatie was op een eerder ontdekte en slecht gepatchte bug.

De ontwikkelaar die beveiliging serieus neemt, de juiste cultuur hoog in het vaandel draagt en waar mogelijk tools en hulpmiddelen inzet, is in ieder geval zo goed mogelijk gewapend tegen de alsmaar toenemende bedreigingen. Daar kan je zelf trots op zijn, en dat wordt hopelijk ook geapprecieerd in het bedrijf waar je aan de slag gaat.

Safety first! Doet jou dat ook meteen aan cybersecurity denken? Ben je een krak in het leveren van eerste hulp bij kwetsbaarheden? Dan hebben we zeker een job die je op het lijf geschreven is. Bekijk onze vacatures hier.