We leven in een ander tijdperk: één waarin de snelheid van nieuwe releases van softwareproducten noodgedwongen veel hoger ligt dan ‘vroeger.’ Gebruikers in de business zijn daar blij mee, maar security-mensen hebben er moeite mee. Onderdeel van de oplossing: DevOps omarmen.
Over deze blogger
Ron Tolido is Chief Technology Officer van Capgemini voor de regio’s Noord-Europa en Azië-Pacific Hij behaald een Bachelor of Science in informatietechnologie aan de Haagse Hogeschool. Daarvoor studeerde hij Nederlandse Taal- en Letterkunde aan de Universiteit Leiden. Opgeleid bij AT & T’s Bell Labs, was hij een van de eerste Unix System V kernel-specialisten in Nederland. Tijdens zijn carrière is de heer Tolido betrokken geweest bij veel verschillende opdrachten met betrekking tot (commerciële) software productontwikkeling, technologie consulting, architectuur en IT-strategie, zowel in operationele als in leidinggevende functies.
Vroeger was een nieuwe release van een softwareproduct letterlijk een life-changing gebeurtenis. Het was zwaar, het was ingrijpend en het pakte niet zelden ook negatief uit. Een nieuwe versie van een ERP-pakket liet je als CIO maar liever over aan je opvolger. Nu volgen nieuwe releases elkaar steeds sneller op. Niet alleen van mobiele apps maar ook van cloud-gebaseerde oplossingen en zelfs hele besturingssystemen. Zie alleen al de versnelling die bedrijven als Apple en Microsoft hebben ingezet om op heel regelmatige basis nieuwe versies van hun oplossingen – inclusief de besturingssystemen – uit te kunnen brengen.
Derde ‘IT-bevolkingsgroep’
Als een antwoord op die toegenomen dynamiek speelt er in IT-land de trend van DevOps. Dit is de samenvoeging van de IT-begrippen ‘development’ en ‘operations’ waarbij er een vloeiende, voortdurende overgang is van software-ontwikkeling naar de ingebruikname en het beheer ervan. Dit is mogelijk dankzij de ondertussen befaamde ‘tools-treintjes:’ een geautomatiseerde keten van tools die zorgen voor het bouwen, compileren, integreren, testen, packagen en uitrollen van nieuwe releases. Deze automatisering maakt het mogelijk snel nieuwe release uit te brengen, indien nodig tien keer per uur, in plaats van eens in de zoveel maanden.
Niet alleen development, operations en testing moeten in deze keten meedoen, ook security en security-mensen zouden moeten aanhaken. Zo kan er zelfs met tien releases per uur ook tien keer goed en aantoonbaar gecontroleerd worden op beveiliging. Eigenlijk voeg je hiermee een IT-bevolkingsgroep toe aan de populatie die nu DevOps-teams vormen. En teamvorming is cruciaal, vooral ook om de bijna klassieke spanning tussen de verschillende rollen in de levenscyclus van applicaties weg te nemen. Je wilt niet alleen maar beren op de weg zien – net zoals van oudsher sommige security-mensen lijken te doen – maar in plaats daarvan gezamenlijk werken aan een ononderbroken cadans van ontwikkelen en vrijgeven.
Meerijden in het tools-treintje
Vergis je niet: er zijn altijd goede redenen geweest voor behoedzaamheid, vooral in de relatie tussen ontwikkelaars en operations. Zeker nu er dankzij social media grote gevolgen kunnen ontstaan als gevolg van één misstapje in een applicatie. Zelfs als je fout maar 3 seconden live heeft gestaan, kan iemand al een screen capture hebben gemaakt. De resultaten kunnen desastreus zijn. Maar het antwoord is niet altijd op de rem te trappen en actief business-preventie te bedrijven. Dan loop je eeuwig achter en daar wordt de organisatie – en de buitenwereld – ongeduldig en ongedurig van. DevOps is daarom niet voor niets zo populair: het voldoet aan een sterk gevoelde behoefte.
Security kan en moet leren van DevOps. Zelfs als je maar één keer in de drie maanden een nieuwe release uitbrengt (wat voor sommige organisaties al een enorme stretch is). De vrees vanuit security is vaak dat agile ontwikkelen en het grote broertje DevOps het risico brengt van ‘shoot and test’: we zien wel in de praktijk of het werkt of niet. De slechtste reactie is dan om ervóór te gaan liggen. Developers willen een goed idee snel uitbrengen, gebruikers willen vernieuwing snel ontvangen. Daarbij accepteren ze beperkingen en functionele tekortkomingen, want die worden als het goed is snel aangepakt in een volgende versie.
Security mag echter bij dit alles niet tekort schieten, moet zelfs minder ter discussie staan dan ooit. Het is daarvoor noodzakelijk om industrieel te werken, door security in te bouwen in de aanpak en in het platform. En door geautomatiseerd, voortdurend op security te testen. Net zoals er in DevOps-teams voortdurend geautomatiseerde regressietesten worden uitgevoerd.
Zorg voor geïntegreerd team
Mijn pleidooi – nee wacht: mijn dringende uitnodiging – is om security te laten leren van alle verworvenheden van DevOps. En andersom: zorg voor de garantie van security als er op de knop van het DevOps tools-treintje wordt gedrukt. Kernvraag daarbij is hoe je een geïntegreerd team creëert: een team dat vanaf het begin samenwerkt aan development, security én operations en dat gedurende de hele levenscyclus van de oplossing blijft doen.
Het is één ding om software op hoge snelheid te maken en vrij te geven, maar hoe vermijd je dat de trein op een gegeven moment op een muur rijdt? Met Secure DevOps.
