Cloud-native-applicaties bevatten infrastructure-as-code (in het kort iac) die bepalen hoe applicaties werken binnen een cloud-infrastructuur en hoe gecontaineriseerde applicaties op Kubernetes draaien. Iac betekent snellere, herhaalbare implementaties, maar verhoogt tegelijkertijd de druk voor ontwikkelaars om niet alleen hun code te beveiligen, maar ook de infrastructuurconfiguratie, code-afhankelijkheden en containers.
Organisaties hebben nog niet dé manier gevonden van iac-gebruik en bepaalt wie verantwoordelijk is voor het schrijven en onderhoud ervan. Uit recent onderzoek blijkt echter dat de personen die geautomatiseerde securitytesten voor hun iac-definities gebruiken, verkeerde configuraties sneller vinden en oplossen. Deze high-performers vinden en repareren binnen een dag problemen in hun iac-definities; terwijl collega’s hier meer dan een week over doen.
De voordelen op het gebied van snelheid en betrouwbaarheid zijn groot wanneer alles in code en geautomatiseerd is, maar zorgt zoals gezegd voor een toenemende druk op ontwikkelaars om meer dan alleen hun eigen code te beveiligen. Veel bedrijven zijn pas net met iac begonnen: twee derde begint de technologie net te verkennen en slechts zeven procent geeft aan dat ze iac hebben geïmplementeerd volgens de huidige mogelijkheden van de sector. Hoewel er veel tools in gebruik zijn, standaardiseert 71 procent liever een gemeenschappelijke toolset/workflow voor alle iac-configuratietypen en -formats.
Security vaak op de achterbank
Moderne applicaties worden vaak automatisch geïmplementeerd op infrastructuur die is gemaakt en geconfigureerd via code. Hierdoor zit security vaak op de achterbank bij een snelle implementatie en worden configuratieproblemen pas na implementatie ontdekt. Gartner stelt zelfs dat tegen 2025 zeventig procent van de aanvallen op containers het gevolg zijn van bekende kwetsbaarheden en verkeerde configuraties die verholpen hadden kunnen worden.
Dit betekent niet dat snelheid altijd risicovol is. Geautomatiseerde test- en releasegates kunnen voor andere vormen van code worden gebruikt met iac en helpen om best practices op het gebied van security onderdeel te maken van het ontwikkel- en releaseproces. Qua security staat dit type geautomatiseerd testen echter nog in de kinderschoenen. Zo’n zestig procent van de organisaties zegt dat hun huidige workflow voor iac en configuratiecode continue integratietests (ci) doorloopt, maar slechts een derde neemt securitycontroles op in hun pijplijn.
De meeste securityproblemen worden ontdekt na implementatie, doorgaans na penetratietesten, audits en het onderzoeken van incidenten. Bij bedrijven die controles na de implementatie uitvoeren, duurt het in de helft van de gevallen minimaal een week om een securityprobleem te ontdekken en in bijna twee derde van de gevallen meer dan een dag om die op te lossen. Zij hebben acht dagen langer een securityprobleem dan de beste performers die vaak binnen een dag een probleem ontdekken en oplossen.
De grootste uitdaging voor respondenten die ci-tests gebruiken, is de integratie van securitycontroles door een gebrek aan gestandaardiseerde best practices over wat ze moeten controleren. Teams nemen nu vaak hun eigen beslissing over wat ze moeten testen. Als je dat koppelt aan de 41 procent die zegt dat onduidelijke benchmarks een grote barrière voor security is, moeten we betere tools inzetten die duidelijke begeleiding bieden terwijl teams de vrijheid behouden om te bepalen wat voor hen het belangrijkst is.
Stukje van de puzzel
Het vinden van het probleem is een stukje van de puzzel. Zodra een probleem is ontdekt, moet iemand het oplossen. Als ze de keuze hebben, beweert iets meer dan de helft van de respondenten dat ze een securityprobleem meestal oplossen door de infrastructuur rechtstreeks aan te passen in plaats van de iac-broncode. Dit kan voor problemen op de lange termijn zorgen, omdat de gewijzigde infrastructuur bij de volgende implementatie is te resetten naar de verkeerd geconfigureerde staat. Respondenten die handmatig herstellen, zeggen dat dit komt door een gebrek aan standaardisatie, kennis en communicatie, maar ook omdat ze reparaties zo snel mogelijk willen uitvoeren.
Een van de barrières voor het verschuiven van iac-security naar links, was dat teams moeite hadden met standaardisatie in hun organisatie, waardoor elk team iac op een eigen manier controleert. Naast de voor de hand liggende securityproblemen die dit meebrengt, laat dit een gat in verantwoordelijkheid zien.
Devsecops-modellen
Er lijkt geen consensus over wie verantwoordelijk is voor security van cloud-infrastructuur. Ontwikkelaars en devops-rollen hebben een iets grotere rol dan andere teams. Veel respondenten vinden security een gedeelde verantwoordelijkheid, mogelijk passend bij de nieuwere devsecops-modellen. Als iac-security geen gedeelde verantwoordelijkheid mag zijn, kiest het merendeel van de respondenten voor ontwikkelaars en devops-teams. De reden dat securityverantwoordelijkheden niet verder naar links verschuiven is het vertrouwen in het vermogen van de organisatie om problemen in de code snel te herkennen en op te lossen.
Een schaalbare oplossing voor iac-securityuitdagingen is het investeren in de tools en training die nodig zijn om het vertrouwen en de reikwijdte van teams te vergroten en ervoor te zorgen dat zij code snel en veilig kunnen implementeren. Gartner ziet ook het potentieel van deze geautomatiseerde tools en voorspelt dat organisaties tegen 2025 hun herstel van codekwetsbaarheden met een derde zullen versnellen met codesuggesties die worden toegepast vanuit geautomatiseerde oplossingen, waardoor ze de helft minder tijd besteden aan het oplossen van bugs.
