DevSecOps: Security begint bij Development

Zoals de naam al zegt, werken bij DevOps de Developers samen met de collega’s van Operations. Deze samenwerking zorgt voor continuïteit in het proces: ontwikkelen zonder overhead. Veel bedrijven zijn bezig met deze stap, maar uit recent onderzoek is gebleken dat slechts zo’n 7% van de bestaande DevOps teams daadwerkelijk op het gewenste niveau samenwerken. Denk hierbij aan ‘on demand’ kunnen deployen, serverproblemen binnen een uur kunnen herstellen en het hebben van een ‘failure rate’ van hooguit 15%. Hier is dus nog een verbeterslag te maken.

Onbewust

Het grootste probleem van dit alles is dat men zich eigenlijk niet bewust is van het hele onderwerp van software beveiliging. Wat we niet kennen is er niet, of het overkomt ons niet. Als het gebeurt, handelen wij daar reactief naar. Onderstaande toont aan dat het “probleem” er wel degelijk is, en hoe sneller wij ons hiervan bewust worden, hoe sneller wij hiernaar kunnen gaan handelen.

• Hooguit 20% van de code die naar productie gaat, is eigen code.
• 1 van de 16 Open Source componenten die gedownload worden heeft een kwetsbaarheid die bekend is (CVE: Common Vulnerabilities and Exposures).
• 31% van de bedrijven is gehackt of vermoedt dat het gehackt is door een kwetsbaarheid in een Open Source component.
• 97% van alle succesvolle exploits leiden terug naar 10 bekende kwetsbaarheden.
• 8 daarvan zijn al lang geleden gepatcht.
• Weet jij welke package naar productie gaat? Welke versie dit is? En of deze kwetsbaarheden bevat?
• Op het moment dat je een nieuw project start op basis van Open Source componenten, bevat dit meteen beveiligingsproblemen. Bijvoorbeeld bij een Angular/.NET Core project, bestaat deze meteen uit 20 security vulnerabilities en 123 outdated packages, waar je normaal gesproken geen weet van hebt.

Tijd voor een nieuwe mindset. Tijd voor DevSecOps.

Om de veiligheid van je software, en daarmee de kwaliteit en continuïteit, te waarborgen is het van belang om het Security-team direct te betrekken bij het ontwikkelproces. Zo kan veel al worden afgestemd bij het bepalen van de architectuur van de applicatie. Preventief werken in plaats van reactief. Deze werkwijze staat ook bekend als Shift-Left-Security. Een simpele term voor een nieuwe uitdaging: security nauwer bij het ontwikkelproces betrekken betekent (nog) meer samenwerking tussen verschillende teams. Door eerder en intensiever samen te werken, voorkom je dat men een mogelijk beveiligingsrisico doorschuift tot aan de release, of dat men niet genoeg tijd of focus heeft om dit tijdig te verhelpen.

Er zijn voordelen aan het Shift-Left-proces: zo leert development en operations meer over potentiële risico’s en hoe deze te voorkomen. Ook leren zij hoe en waarom bepaalde maatregelen genomen moeten worden.

De eerste stap in dit proces is om ontwikkelaars bekend te maken met security: zij moeten begrijpen dat het Security-team geen groep boemensen is die veranderingen tegenhouden, maar dat ze daar zitten met een reden. De rol van het Security-team is het bewaken van de veiligheid van de applicatie en het wijdere IT-landschap. Men moet begrijpen dat je elkaar kan helpen risico’s vooraf in kaart te brengen en deze te tackelen. Veiligheid begint dus bij de Developer. Wanneer een Developer zich van begin af aan meer bewust is van de security, en het effect op zijn werkzaamheden daarvan, houdt hij er van begin af aan ook meer rekening mee. Zo hoeft hij niet later weer terug te gaan naar zijn eerdere werk om daarin security-gerelateerde aanpassingen te doen. Dit is fijn voor zowel de continuïteit van het werk en de focus van de Developer. Daar wordt iedereen blij van.

Risico’s zijn er in alle formaten. Van phishing mails, social engineering en rondslingerende USB-sticks tot aan ‘gratis’ extra (geïnfecteerde) servers bij een bestelling geleverd krijgen of het per ongeluk online zetten van van Secret Access Keys (zie afbeelding hieronder).

Nog enkele voorbeelden van hoe goed iets mis kan gaan

Zoals hierboven beschreven, kan het goed mis gaan wanneer je jezelf afhankelijk maakt van Open Source-componenten. Een voorbeeld van zo’n afhankelijkheid was “left-pad”. Een JavaScript component waar weer duizenden andere componenten van afhankelijk waren.

Na een discussie met een ander bedrijf besloot de eigenaar om zijn component te verwijderen uit NPM. Resultaat: duizenden mislukte builds en deployments.

Een ander voorbeeld was Heartbleed. Dit was een bug in de meest gebruikte implementatie van het SSL-protocol. Een bug waar men nog steeds last van heeft.

Maar; het gevaar stopt niet bij Open Source. Ook duurbetaalde softwarepakketten zoals Telerik kunnen fouten bevatten. Hier word je wel van op de hoogte gehouden, daar betaal je ten slotte ook voor. Je moet echter wel zelf je softwarepakket updaten, dat gaat niet automatisch. En als je dat niet doet, heb je toch weer een risico.

Zoals je ziet is security vandaag de dag een essentieel onderdeel van het algemene ontwikkelproces en zou elke organisatie van DevOps naar DevSecOps moeten overstappen. Mijn ShareValue-collega’s en ik weten hoe waardevol zo’n team is en vinden het dan ook heel leuk om daaraan mee te werken.

Wil je hiermee aan de slag en kan je wel een Developer in je team gebruiken die hier ervaring mee heeft? Neem contact met ons op om vrijblijvend de mogelijkheden te bespreken.