Valkuilen in DevSecOps
‘Security is een van de grootste uitdagingen in software development’, stelt Davide Cioccia, senior application security architect bij Veralto. Hij geeft enkele best practices mee. ‘Leer beveiliging aan ontwikkelaars en ontwikkeling aan beveiliging.’
Voor IT-vereniging SAI, een van de partners van Cybersec Europe, deelde Davide Cioccia onlangs zijn visie rond de aanpak van DevSecOps, wat staat voor development, security & operations. DevSecOps is een approach van cultuur, automatisering en platformontwerp die beveiliging integreert als gedeelde verantwoordelijkheid gedurende de gehele IT-levenscyclus, met development als belangrijk aspect. ‘Een van de meest vooraanstaande pitfalls daarbij is dat security geen deel uitmaakt van development’, stelt Davide Cioccia.
Bij veel organisaties heerst ook een slechte beveiligingscultuur. ‘Een uiting daarvan is bijvoorbeeld dat het management niet is betrokken bij discussies over security’, stelt Cioccia. ‘Ook het feit dat bijvoorbeeld het security department owner is van de security van het product is een teken aan de wand. Net als de verdeling van de workforce. Als er bijvoorbeeld 1 security persoon of expert is tegenover 1.000 developers. Dan zit die verhouding niet goed.’
Beveiliging is geen bijzaak
Een sterke security cultuur brengt om te beginnen al security experts binnen met een development background en laat ze samenwerken met het ontwikkelingsteam, stelt Cioccia, en hij wijst op ieders rol en focus. ‘De security mensen moeten de product tech en de business goed begrijpen. De ontwikkelteams zijn op hun beurt eigenaar van de beveiliging van hun producten. En het management spreekt regelmatig over security.’
Een andere valkuil is dat security iets is wat achteraf gebeurt, als soort van nasleep. ‘Implementeer beveiliging in verschillende fasen van de ontwikkelingscyclus’, raadt hij aan. ‘En leer beveiliging aan ontwikkelaars en ontwikkeling aan beveiliging.’
Sommige tools zoals SAST en SCA, of een combinatie van beide, kunnen teams zeker helpen. SAST (= static application security testing) analyseert voornamelijk bedrijfseigen code op potentiële veiligheidsrisico’s. SCA (= software composition analysis), aan de andere kant is het ontworpen om kwetsbaarheden in open-sourcecomponenten te identificeren, zodat organisaties deze kunnen herstellen vóór implementatie of levering. ‘Maar weet dat tools op zich niet de oplossing zijn. Die zit in jouw proces. Richt je daar zeker op.’
Betere beveiliging tijdens de ontwikkeling: 10 concrete adviezen
• Begin met een of twee tools (SAST en SCA) voor het scannen van uw pipelines op beveiligingsproblemen.
• Hanteer één volwassenheidsmodel en houd je daaraan.
• Integreer kwetsbaarheden in de tools van de ontwikkelaars (zoals Jira).
• Ontwikkelaars zijn verantwoordelijk voor het definiëren van hun pijplijnen.
• Forceer niet één beveiligingspijplijn voor iedereen.
• Betrek de beveiliging alleen bij veranderingen met een hoog risico.
• Voeg het beveiligingsteam niet toe als goedkeurder voor alle Pull Request en Merge Request.
• Gebruik een dreigingsmodel waarmee u een reeks dreigingen kunt categoriseren en identificeren.
• Identificeer mensen die geïnteresseerd zijn in beveiliging binnen uw (ontwikkel)team.
• Creëer een ‘Security Champions’-programma en curriculum voor training en continue verbetering.
Dit artikel verscheen eerder in het Engels in het Cybersec e-Magazine #4 (april 2024):
