Het klassieke pad waarbij een app op een server komt, getest wordt en dan in productie gaat, verdwijnt met DevOps. Dankzij deze agile ontwikkelmethode schrijf je tegenwoordig code in een omgeving die blijft draaien. Je krijgt een realtime-coderingsproces waarbij dagelijks nieuwe versies van de app – of soms meerdere per dag – worden vrijgegeven. Alles gebeurt geautomatiseerd.
Over DevOps (een samentrekking van developer en system operator) zeggen we weleens: ‘It became technical after ‘hello’’. Zonder hier al te technisch te worden: de code (in GitHub of andere opensource geschreven) wordt gepusht naar een builder (genre Jenkins) die de app begint te bouwen. En dan gaat deze quasi-automatisch live. De cyclus gaat ook altijd sneller, dus manueel checken is niet meer mogelijk. Automated security is nu met andere woorden een must om deze apps te beveiligen.
Is de code ‘oké’, dan mag ze door
Besmet
Een van de gevaren van DevOps is dat ze steeds vaker gebruik maken van bestaande bibliotheken. Een beetje zoals Lego-blokken die ze dan op elkaar stapelen. Als een van deze blokken besmet is, zijn in principe al je apps kwetsbaar. Dat is wat er in het verleden gebeurde met de Heartbleed-aanval.
De menselijke factor speelt ook een grote rol, want echt veilige apps ontwikkelen, duurt veel langer dan de tijd die de gemiddelde ontwikkelaar vandaag vaak krijgt. En onder (tijds)druk durven deze developers codes te gebruiken die minder op veiligheid zijn getest. Niet alleen DevOps dragen dus een belangrijke verantwoordelijkheid, maar ook hun leidinggevenden en cto’s.
Het antwoord op besmette bibliotheken en tijdsdruk is om vroeg in de pipeline de code al te scannen. Is de code ‘oké’, dan mag ze door naar de volgende fase. Bij gevaar krijgt de developer een waarschuwing en houdt de tool de code tegen. Meestal gaat het dan om ‘vuile code’, ‘cryptominers’ en ook de ‘silver bullet’.
De tool kan ook scannen op access tokens of private keys. Dat laatste is volgens DevOps een echte meerwaarde omdat ze tijdens het ontwikkelen soms shortcuts maken in hun code, maar die er later vergeten uithalen en deze dus ongewenst publiceren. Op deze manier gebeurt dit niet meer.
Ingebakken
Een les die developers zeker moeten meekrijgen: security mag geen after-effect zijn. Als een app-ontwikkelaar code schrijft, moet hij ervoor zorgen dat de code direct goed geschreven is. Het moet in de pipeline ingebakken zitten. En liefst zo snel mogelijk. Want hoe verder in het ontwikkelproces, hoe duurder het wordt om de tool te beveiligen.
Om een idee te geven: uit het rapport The Economic Impacts of Inadequate Infrastructure for Software Testing van het National Institute of Standards & Technology blijkt dat een app in de coderingsfase veilig maken al tweemaal duurder is dan in de planningsfase. Wie wacht tot in de testfase mag die kostpost al maal tien doen. In de stagefase (app op server voorbereiden voor productie) gaat de kostprijs als factor vijftien en eenmaal de app live is, ga je tot dertig keer meer moeten uitgeven dan in de planningsfase om de app veilig te maken. Iets om over na te denken.
Auteur Chris van den Abeele is global solution architect for cloud & datacenter security bij Trend Micro.
