Applicatie code beveiligen zonder ontwikkelaars?

Is het niet een bekend feit dat ontwikkelaars niks geven om applicatie beveiliging, laat staan dat het schrijven van veilige applicatie code aandacht heeft bij de ontwikkelaars. Is het dan niet fantastisch dat er tooling is die applicatie code op bekende kwetsbaarheden scant! Maar hoe werkt het dan en hoe werkt het nou goed?


De uitdaging blijft, hoe kan ik de veiligheid van de applicatie code verbeteren?

Steeds meer bedrijven doen aan geautomatiseerde ‘Secure Code Review’, het laten valideren van applicatie broncode op kwetsbaarheden door een tool. De een vertrouwt op open source producten, de ander denkt met betaalde producten beter af te zijn. Het product wordt aangeschaft, geïnstalleerd, er wordt een proces ingericht en geen enkel software product wordt meer in productie genomen als de code niet gescand is en alle bevindingen zijn opgelost. Alle bevindingen? Het aantal bevindingen dat door het tool als kritiek of hoog worden ingeschat, loopt al gauw in de honderden, bij een grote applicatie in de duizenden. Deze allemaal op te lossen lijkt een onmogelijke opgave. Wat fijn, dat de tool een inschatting geeft van de ernst van een bevinding. Voor het gemak richt men zich op de door het tool als kritiek geclassificeerde bevindingen, want het moet wel werkbaar blijven!

Secure Code Review in de praktijk

Maar, wie gebruikt de tool? De ontwikkelaars zijn kostbaar en moeten doen waarvoor zij worden betaald, software ontwikkelen! Oh ja, en ze hebben helemaal geen boodschap aan veilige applicaties. Dus die gaan we ermee niet lastig vallen. Indien voorhanden, laten we de secure code scans uitvoeren door penetratietesters. Die hebben immers de kennis omtrent applicatie security. Anders zijn er gelukkig nog de functionele testers. Het software testen is in Nederland op een hoog niveau, en met een weekje cursus is de kennis ook vast voldoende…. Als het écht niet anders kan, dan laten we de code toch maar door het ontwikkelteam scannen. Een mooie taak voor de minder ervaren ontwikkelaars, want onze cracks, die zijn hier te duur voor. Snel wordt het scannen van de code opgenomen in de kwaliteitsrichtlijnen en wordt erop los gescand. De tooling levert mooie rapporten met de geconstateerde bevindingen op. De minder ernstige fouten kunnen we er mooi uit laten filteren, en het PDF-je wordt naar de ontwikkelteams gemaild. Een tool heeft altijd gelijk, dus oplossen maar! De aanbeveling hoe te verbeteren leveren de betere tools natuurlijk ook gelijk mee!

Gaat dit werken?

Wat wordt met deze aanpak bereikt? Net als met alle vinkjes in een proces waarvan het nut niet duidelijk wordt gemaakt, wordt het doel het “vinkje halen”. Het behalen van het akkoord op de secure code review wordt aan het einde van de ontwikkelcyclus gepland, of het nu een iteratie of een sprint wordt genoemd. Het beste is dan om een test aan te vragen kort voordat de applicatie van de business live moet. De kans is dan hoger dat het risico van de bevindingen door de business wordt geaccepteerd. Want de business, die heeft het laatste woord en ook zij vinden het toch allemaal gedoe, dat security geneuzel. Oh, en de geconstateerde kwetsbaarheden lossen we bij de volgende release wel op. De beschreven aanpak kost geld, tijd en levert weinig veiligheid op in relatie tot de moeite die erin wordt gestoken.

Waar gaat het fout?

Om de code te kunnen beoordelen heb je kennis nodig van de technologie, de omgeving en architectuur. Het terug koppelen van de scan-resultaten wordt al gauw en wel/nietes discussie, omdat de benodigde technologie kennis niet aanwezig is bij wie de scan heeft uitgevoerd. Niet alle bevindingen zijn relevant , omdat de maatregel buiten de applicatie liggen. Deze worden al te graag als ‘false positives’ van de tafel geveegd en al snel wordt het tool als onwerkbaar bestempeld.  Net zo erg, moet het maar opgelost worden, of het in de praktijk wel of geen probleem is. Het tool heeft gelijk, toch! De bevindingen worden in rapporten aan het team gemeld. Hoe dikker hoe beter, maar voor het ontwikkelteam niet werkbaar.

Hoe kan het beter, en wie scant de code?

Geen enkel proces wordt goed nageleefd, aan geen enkele regel houdt men zich, als het nut ervan niet duidelijk is gemaakt en erachter wordt gestaan. Houden wij ons op de verkeerswegen aan de snelheid in verband met de veiligheid of vanwege de hoge boetes? Wie het vanwege de mogelijke bekeuringen doet, zal gauw te hard rijden wanneer hij geen controle verwacht! Boven aan staat dus bewust maken. Hiervoor is het ook van belang dat de ontwikkelaars worden meegenomen in het belang van de applicatie, bedrijfsrisico en wat zoal mogelijk is indien beveiligingsrisico’s in een applicatie te misbruiken zijn.  Het is belangrijk juist hen bewust te maken wat het (technische) risico is van onveilige code, en wat de risico’s zijn voor de gebruiker of het bedrijf. Dit is niet altijd zo duidelijk als bijvoorbeeld bij een online bank applicatie, dus dat behoeft aandacht. Maximale werkbaarheid door minimale overhead. Awareness gecombineerd met een uitleg voorafgaand aan een goede implementatie, verhoogt de kennis binnen het ontwikkelteam. De kwaliteit van de code zal worden verhoogd en er zullen steeds minder bevindingen worden gedaan. Zoals eerder gesteld, het aantal bevindingen kan al snel tot onoverzienbare aantallen oplopen. De gehele code base scannen kan soms wel uren duren en niet alle bevindingen zijn relevant.

Wat is gevaarlijker, een “false positive” (een bevinding die niet klopt) of een “false negative” (een kwetsbaarheid die het tool niet gevonden heeft?)

Het antwoord hierop is afhankelijk van aan wie je de vraag stelt. Voor een security-expert is een “false negative” niet acceptabel. Toch voor de ontwikkelaar is het niet werkbaar als hij de bevindingen eerst moet valideren of deze juist zijn. De betere tools hebben de mogelijkheid verschillende lijsten van bevindingen te tonen, afhankelijk van de gebruiker.  Door de ontwikkelaars alleen de bevindingen te tonen die met een hoge waarschijnlijkheid moeten worden opgelost houd je het werkbaar voor de ontwikkelaars.  De overige worden door een security expert beoordeeld en met het ontwikkelteam besproken. Hierdoor wordt het ontwikkelteam opgeleid in het ontwikkelen van veilige code. De ontwikkelaars kunnen zich op het ontwikkelen van software concentreren en de security specialisten op het toetsen van de uitkomsten en het adviseren en ondersteunen van minder voor de hand liggende security problemen. Net als andere code quality tooling kan (lees moet) het tool worden geoptimaliseerd voor een maximale rendement. Dit vergt kennis en kost tijd en heeft alleen zin als het voortdurend wordt gebruikt. Bij een halfjaarlijkse inzet is de inspanning voor het optimaliseren niet in verhouding tot het nut.

Secure Code Review Checklist:

-       Inrichten en onderhouden van een secure coding awarness programmas

o   Secure code trainingen

o   Hack-yourself sessies

-       Richt ‘best practises’ in voor het goed en juist gebruik van de tooling

o   Laat het tool aansluiten aan het ontwikkelproces en omgeving

-       Optimaliseer het gebruik van de tooling

o   Configureer het tool zodat het de architectuurstandaard ondersteund

o   Bevindingen mogen de ontwikkelstandaard niet tegenspreken

-       Richt een expert team op voor ondersteuning

o   Geef de mogelijkheid om drempelvrij en makkelijk advies en ondersteuning te leveren aan de ontwikkelteams