Komt de omschakeling naar DevSecOps er eindelijk aan?

Waar blijft de shift van DevOps naar DevSecOps? Dat vraagt Brian Vermeer van Snyk zich af. Tijdens een virtuele sessie georganiseerd door Snyk, doet hij uit de doeken waarom het belangrijk is aandacht te besteden aan de beveiliging van onder andere containers.

Brian Vermeer vertelt dat hij groot voorstander is voor de shift naar DevSecOps. Volgens menig onderzoeksbureau komt de shift er al jaren ‘heel snel aan’. Een relatief begrip, zo blijkt. DevSecOps werd in 2018 verwacht snel tot belangrijke term uit te groeien, maar dat laat toch op zich wachten.

DevOps is ondertussen wel bij veel bedrijven ingelijfd. Voor wie nog niet weet wat het betekent, leggen we het graag nog eens uit. In de shift naar DevOps werd in essentie de silo neergehaald tussen het operationele team en het ontwikkelaarsteam. Dat nieuwe, vergrote team heeft de ambitie om op constante basis verbeteringen aan apps uit te rollen. Dit is bovendien nodig om aan de vereisten van de markt en de vraag naar een snel werktempo van de werkgever, te voldoen.

Toen in het proces vergeten en nog steeds aan de kant geschoven is de beveiliging. Een afbraak van de laatste silo is volgens Vermeer de enige gepaste oplossing om applicaties veilig te lanceren.

Uit een recent rapport van VMware blijkt dat slechts één op de vijf (22%) ontwikkelaars precies weet welk beveiligingsbeleid hij of zij zich moet volgen. De overige personen tasten wat meer in het duister, of voelen zich niet genoodzaakt om eens te polsen achter het beveiligingsbeleid. Waarvoor trouwens net zo goed met een beschuldigende vinger naar het managementteam moet worden gewezen. 

Opensource populair

Dat opensource gewild en begeerd is, bewijst ook het recent uitgebrachte onderzoek van Linux Foundation. HR-managers willen in het komende half jaar namelijk massaal nieuw opensourcetalent aanwerven. Iedereen die de benodigde kennis heeft, is fel begeerd. Want de meeste mensen zouden niet weten waar in het opensourceverhaal te beginnen.

In die context blijkt beveiliging naast het tekort aan talent eveneens een groot probleem te zijn. Wie opensource in huis haalt, weet namelijk vaak niet of hiermee de duivel is binnengeglipt. Beveiligingsproblemen doen zich bijvoorbeeld voor wanneer teams applicaties uitrollen en updaten op basis van opensourcecodes. Dat gebeurt vaak om snelheid te kunnen leveren.

Voornamelijk in kleine ondernemingen wordt vaak gedacht: “We zijn een klein bedrijf, waarom zouden cybercriminelen geïnteresseerd zijn in ons?” Jammer maar helaas voor de kleine bedrijven die op opensource vertrouwen. Het zijn namelijk niet de specifieke namen van bedrijven waar aanvallers hun aanvallen op richten, maar wel de opensourcecodes. Gebruikt een klein bedrijf de opensourcecode waar criminelen het op gemunt hebben, zou dit een jammere samenloop van omstandigheden zijn. Maar het gebeurt.

Containers niet in de regel veilig

Ontwikkelaars die een opensourcecontainer gebruiken denken daarbij ook dat ze veiliger zijn, maar dat is niet waar, zegt Vermeer. Als bewijs scande hij de tien meest gebruikte Docker images op kwetsbaarheden. Zo bleek geen enkele van de geteste images volledig veilig te zijn.

Een Docker image maakt het mogelijk om een werkomgeving te voorzien voor een container. Hiervoor bestaat een image uit een collectie van bestanden: systeemfuncties, bibliotheken, code en andere benodigdheden.

Containers zijn een dankbaar gegeven voor DevOps om applicatieontwikkeling en -updates te versnellen. Doordat een container geen virtuele machine vereist, is het flexibeler en laat het kleinere toepassingen toe. Dat verlaagt de hardwarevereisten en stelt teams in staat sneller code in productie te stellen.

Problemen mogelijk door versnelde ontwikkeling

Snelheid bij de ontwikkeling is één deel van het verhaal, maar als de beveiliging ontbreekt, stort alles zo in elkaar als een peperkoekenhuisje. In de sessie wordt Vermeer bijgevallen door Nanne Baars, ontwikkelaar bij het Nederlandse bedrijf Xebia. Hij geeft een voorbeeld van een beveiligingsprobleem waar reeds gelanceerde apps vaak mee te kampen krijgen.

Hij begint zijn verhaal als volgt: “Als ontwikkelaar maak je gebruik van veel bibliotheken om een code te ontwikkelen.” Deze bibliotheken vind je in programmeertalen zoals Java, Python en C. Door middel van bibliotheken kunnen ontwikkelaars snel de benodigde code vinden en de applicatieontwikkeling versnellen.

In bibliotheken is het mogelijk op zwak geconfigureerde XML-parsers uit te komen, die XML-input met een verwijzing naar een externe entiteit verwerkt. Dat brengt beveiligingsproblemen met zich mee en is niet altijd zichtbaar voor ontwikkelaars. Ideaal dus voor cybercriminelen om aanvallen op te lanceren.

Voor de volledigheid zullen we de term XML-parser eerst nader verklaren. XML is een afkorting voor Extensible Markup Language. Eigenlijk is het een opmaaktaal waarmee gestructureerde gegevens worden weergegeven in platte tekst. Op die manier is de tekst leesbaar voor zowel computer als mens. Een andere bekende opmaaktaal is HTML.

Een parser is dan weer een component van een programma dat enerzijds controleert of de input de correcte structuur heeft. Anderzijds breekt het data op in kleine elementen, zodat een computer ermee aan de slag kan.

XXE-aanval

Door middel van een XML external entity (XXE)-aanval, kunnen cybercriminelen onder andere confidentiële gegevens lospeuteren. Verder is het mogelijk een applicatie tijdelijk ontoegankelijk te maken, door een hoog aantal opdrachtverzoeken naar de server te sturen. 

Dit probleem is bij veel ontwikkelaars gekend, volgens Baars. Hij vertelt dat door een misvatting die onder ontwikkelaars leeft, velen onterecht denken dat Java 8 bescherming biedt tegen een XXE-aanval. Baars zegt dat het enige probleem waar Java 8 tegen beschermt de denial of service-attack is. Die maakt een applicatie tijdelijk ontoegankelijk.

Door een misvatting die onder ontwikkelaars leeft, denken velen onterecht dat Java 8 bescherming biedt tegen een XXE-aanval.

Nanne Baars, ontwikkelaar bij Xebia

Een betere beveiliging van de parser is mogelijk door in de bibliotheken waar de applicatie gebruik van maakt, na te gaan of er kwetsbaarheden staan aangegeven. Om dit snel te laten verlopen, bestaan er handige tools. Die zetten ontwikkelaars meermaals in tijdens de ontwikkeling van een update of applicatie.  

Geen blind vertrouwen

Volgens Baars zijn de tools een goed hulpmiddel, maar tegelijk blijken die tijdens het ontwikkelingsproces niet altijd betrouwbaar. Dit komt doordat een XML-parser opnieuw kwetsbaarheden kan bevatten wanneer de applicatie wordt overgezet naar een nieuw platform.

Verder geeft Baars ook aan dat eens een applicatie is uitgerold of de update is doorgevoerd, ontwikkelaars echter zo goed als nooit meer snuisteren door de bibliotheken. Baars raadt aan hiervoor een routine te ontwikkelen, waarbij uitgewerkte projecten op vaste tijdstippen worden gescand op kwetsbaarheden. 

De glorieperiode van DevOps duurt te lang en het is hoog tijd om in te zetten op DevSecOps. Die laatste silo moet in veel bedrijven eindelijk is verdwijnen. Het onderzoek van VMware zet hiervoor een nieuwe deadline op de ‘snelle’ shift naar DevSecOps. VMware voorspelt dat 2023 het jaar van de verlossing wordt. Al verwacht dan nog maar net meer dan de helft (53%) van de bedrijven dat DevSecOps in hun bedrijf een feit is. Volgens de cijfers verkort de applicatiecyclus nochtans tot wel vijf dagen in bedrijven waar security- en ontwikkelteams als twee handen op één buik werken.