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.
Zonder al te technisch te worden: een builder (genre Jenkins) begint een app 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.
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’ of ‘cryptominers’.
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 Abbeele is global solution architect for cloud & datacenter security bij Trend Micro.
Lees ook eens het artikel https://www.computable.nl/artikel/opinie/security/6305688/1509029/security-by-design-in-9-stappen.html (Security by design in 9 stappen) van begin vorig jaar. Dat artikel biedt meer tips.
De toekomst van de coder :
5 GB leek ons ook een beetje veel voor alleen een mooier frontendje, maar er zaten ook 2 cryptominers,
4 private keys en nog een paar tokens in.
Gelukkig heeft de pipeline ze gevonden.
Zoiets.
Toch moet de coder moet wel zorgen dat “de code direct goed geschreven is”.
“Want hoe verder in het ontwikkelproces, hoe duurder het wordt om de tool te beveiligen.”
Waar het artikel begint met realtime-codering gaat het blijkbaar ineens weer over planning, test, stage en productie.
Tot zover agile en DevOps.
Nog wat wazigheid over silver bullet. Daar moet je ook op letten, of juist niet, of de pipeline doet het voor je. In ieder geval is het genoemd.
Auteur is global solution architect for cloud & datacenter security
Iets om over na te denken