DevOps naar DevSecOps verplaatsen

Tijdens het maken of moderniseren van een Ontwikkelingsbeveiligingsdiscipline wordt in dit artikel beschreven hoe de integratie van beveiliging in ontwikkelprocedures de overstap maakt van ontwikkelaarsbewerkingen (DevOps) naar developer-security-operations (DevSecOps) en helpt bij het beveiligen van de levering van toepassingen.

Moderne organisaties vertrouwen op snelle softwareontwikkeling om innovatie te leveren, te reageren op veranderende bedrijfsvereisten en concurrentievoordeel te behouden. DevOps maakt deze flexibiliteit mogelijk via continue integratie en levering. Hogere snelheid brengt echter ook nieuwe beveiligingsrisico's met zich mee.

Continue releasecycli verminderen de tijd tussen ontwerpbeslissingen en productie-implementatie, waardoor de kans toeneemt dat zwakke plekken in productieomgevingen worden geïntroduceerd, waaronder:

• Zwakke punten in toepassingsontwerp
• Kwetsbare afhankelijkheden
• Configuratiefouten
• Fouten in infrastructuurautomatisering
• Slechte geheimenbeheer of hygiëne.

DevOps-risico

Moderne DevOps-omgevingen breiden het aanvalsoppervlak uit over ontwikkel-, pijplijn- en productiesystemen. DevOps-hulpprogramma's zoals broncodeopslagplaatsen, pijplijnen en automatiseringssystemen zijn hoogwaardige doelen voor aanvallers.

Als schadelijke code vroeg wordt geïntroduceerd, kan deze bestaande beveiligingscontroles passeren en productiesystemen bereiken.

Veelvoorkomende aanvalsdoelstellingen zijn:

• Schadelijke code injecteren in build-artefacten.
• Identiteiten of serviceaccounts van ontwikkelaars in gevaar brengen.
• Productiegegevens openen of exfiltreren.

Aanvallers richten zich vaak op aangepaste toepassingen en ontwikkelomgevingen om toegang te krijgen tot:

• Gevoelige organisatie- of klantgegevens.
• Bedrijfslogica en intellectueel eigendom.
• Productie-infrastructuur via gecompromitteerde ontwikkelsystemen.
• Downstreamklanten via inbreuk op softwareleveringsketen.

Mogelijke beveiligingsrisico's worden samengevat in het volgende diagram:

Toepassings- en ontwikkelingsrisico's

Toepassingsworkloads kunnen worden aangetast door zwakke plekken die tijdens de ontwikkeling zijn geïntroduceerd of door inbreuk te maken op de infrastructuur die wordt gebruikt om ze te bouwen en te implementeren.

Risico	Doel	Potentieel resultaat
App-ontwerp/implementatie	Beveiligingsproblemen die tijdens het ontwerpen of ontwikkelen zijn geïntroduceerd, kunnen workloads blootstellen aan aanvalstechnieken zoals: - Onjuiste invoervalidatie - Onveilige verificatie of autorisatielogica - Zwakke of onjuist geïmplementeerde cryptografie - Blootstelling van gevoelige gegevens via toepassingslogica	Door deze zwakke punten kunnen aanvallers het volgende doen: - Toepassingsgegevens openen of bewerken - Niet-geautoriseerde bewerkingen uitvoeren - Permanente toegang behouden via geïmplanteerde logicafouten.
Ontwikkelinfrastructuur/automatisering	Aanvallen kunnen zich richten op: - Opslagplaatsen van broncode - Pijplijnen bouwen - Automatisering van implementatie - IaC-sjablonen (Infrastructure-as-Code) - Eindpunten of service-identiteiten ontwikkelen	Bij compromittering kunnen aanvallers het volgende doen: - Schadelijke code invoegen in buildartefacten - Implementatieconfiguraties wijzigen - Permanente toegang behouden via geïmplanteerde logicafout - Inloggegevens of geheimen ophalen die in productieomgevingen worden gebruikt.
Supply chain voor ontwikkelaarssoftware	Toepassingen zijn vaak afhankelijk van: - Bibliotheken van derden - Opensource-pakketten - Containerinstallatiekopieën - Platformdiensten	Beveiligingsproblemen of schadelijke code die via deze afhankelijkheden zijn geïntroduceerd, kunnen van invloed zijn op: - Productieworkloads van organisaties - Klant- of partneromgevingen

De integratie van beveiliging in ontwikkelingsprocessen vermindert de kans dat deze risico's worden doorgevoerd in productierelease.

Naar links verschuiven

Shift left is een benadering van beveiligingstechniek die eerder in de ontwikkelingslevenscyclus beveiliging integreert.

In plaats van de beveiliging pas laat in het proces te valideren, integreren organisaties deze in:

• Visualiseren
• Design
• Ontwikkeling
• Operations

Dit vermindert herstelkosten en risicoblootstelling.

Om deze aanpak te ondersteunen, moeten organisaties het volgende doen:

• Gebruik vroeg in het proces gestructureerde best practices, zoals de SDL (Security Development Lifecycle), in plaats van te laat wanneer problemen duur en moeilijk op te lossen worden.
• Om deze aanpak te ondersteunen, integreert u governance, risico en naleving (GRC) in de ontwikkelingsstrategie.

Wat is DevSecOps?

DevSecOps biedt de Shift Left-benadering door DevOps uit te breiden en beveiliging in elke fase van de levenscyclus van softwareontwikkeling in te sluiten, van idee tot ontwerp, ontwikkeling en bewerkingen.

• In traditionele ontwikkelingsmethoden werd beveiligingsvalidatie vaak uitgevoerd als een laatste kwaliteitspoort vóór de release. Hierdoor zijn vertragingen ontstaan, verhoogde herstelkosten en kunnen beveiligingsproblemen tot laat in de levenscyclus blijven bestaan.

• DevSecOps verschuift de beveiliging eerder en sluit deze continu in in ontwikkelings- en operationele processen.

• DevSecOps vermindert wrijving tussen ontwikkelings-, operationele en beveiligingsteams, waarbij ze worden afgestemd op gedeelde doelstellingen van innovatiesnelheid, betrouwbaarheid en tolerantie voor beveiliging, en waardoor teams de belangrijkste problemen vroeg en continu kunnen aanpakken.

• DevSecOps integreert beveiliging in:

  • Architectuurontwerp
  • Toepassingsimplementatie
  • Automatisering van infrastructuur
  • Implementatie- en operationele processen

Voordelen

Met DevSecOps kunnen ontwikkel-, beveiligings- en operationele teams:

• Identificeer en herstel problemen eerder in de levenscyclus.
• Verminder de blootstelling in productie.
• Houd de leveringssnelheid bij het beheren van risico's.

Beveiliging wordt onderdeel van de wijze waarop software wordt gebouwd en geleverd, in plaats van een controle die na levering wordt toegepast.

Levenscyclus van veilige innovatie

Innovatie verloopt doorgaans in twee fasen van de levenscyclus:

Fase	Bijzonderheden
Ideevorming	Een mogelijkheid is ontworpen, geïmplementeerd en gevalideerd voor het eerste productiegebruik. Het begint met een nieuw idee
Eerste release	Een eerste productierelease voldoet aan de minimale productcriteria voor veilig productgebruik. - Ontwikkeling: Functionaliteit voldoet aan de minimale bedrijfsvereisten. - Beveiliging: mogelijkheden voldoen aan de wettelijke naleving, beveiliging en veiligheidsvereisten voor productiegebruik. - Operaties: Functionaliteit voldoet aan de minimale vereisten voor kwaliteit, prestaties en ondersteuning als productiesysteem.

Na de eerste release wordt de ontwikkeling iteratief naarmate workloads zich ontwikkelen met:

• Risicotolerantie wijzigen
• Toepassingsvereisten en volwassenheid
• Wettelijke verplichtingen
• Bedreigingsvoorwaarden

Beveiliging integreren in ontwikkeling

Traditionele ontwikkelingsmethoden valideren de beveiliging te laat in de levenscyclus, als laatste poort voordat de release na het ontwerp en de implementatie is voltooid. In moderne ontwikkelomgevingen neemt de vertraging van de validatie toe:

• Complexiteit van beveiligingsproblemen
• Kosten voor herstel
• Operationele vertragingen en onderbrekingen
• Verhoogde risicoblootstelling aan actieve exploitatie

DevSecOps integreert de beveiliging continu in ontwikkeling en bewerkingen, om eerder problemen op te lossen, risico's te verminderen en consistentie te verbeteren.

Belangrijke procedures

Beveiliging moet worden ingesloten in bestaande ontwikkelingsprocessen om effectief, schaalbaar en duurzaam te zijn. Deze moet rechtstreeks worden geïntegreerd in de wijze waarop apps worden ontworpen, gebouwd, geïmplementeerd en beheerd, niet in een afzonderlijke of parallelle werkstroom worden geïmplementeerd. We raden het volgende aan:

• End-to-end-workflows in kaart brengen, van idee tot en met ontwikkeling, implementatie en doorlopend beheer.
• Duidelijke rollen, hulpprogramma's en verantwoordelijkheden definiëren voor beveiliging in elke fase van de levenscyclus.
• Consistente herstelpaden tot stand brengen voor beveiligingsproblemen, defecten en ontwerpproblemen.

Pas beveiligingsmaatregelen aan op basis van het risico van de workload. Bedrijfskritieke toepassingen vereisen meer rigor, terwijl scenario's met lagere risico's gestroomlijnde benaderingen kunnen volgen.

Zorg er minimaal voor dat u:

• Identificeer de fasen, personen en technologieën die betrokken zijn bij uw ontwikkelingslevenscyclus.
• Definieer hoe beveiligingsactiviteiten in elke fase worden geïntegreerd in plaats van ze als afzonderlijke controlepunten te behandelen.
• Stel processen vast voor het verwerken van zowel belangrijke wijzigingen als routineoplossingen gedurende de hele levenscyclus.

Beveiliging automatiseren in ontwikkeling en implementatie

Automatisering is essentieel om beveiliging consistent en op schaal af te dwingen in ontwikkeling en bewerkingen.

• Integreer beveiligingsmaatregelen en hulpprogramma's rechtstreeks in CI/CD-pijplijnen.
• Automatiseer belangrijke activiteiten zoals bedreigingsmodellering, codescans, validatie en beleidshandhaving.
• Gebruik Infrastructure as Code (IaC) om herhaalbare, veilige implementaties in te schakelen.

Platformfundamenten zoals Azure landingszones kunnen deze aanpak ondersteunen door

Platformfundamenten zoals Azure landingszones kunnen deze aanpak ondersteunen door gestandaardiseerde patronen te bieden voor beveiliging, governance en DevOps-integratie.

Verwachte resultaten

Organisaties die overstappen van DevOps naar DevSecOps kunnen:

• Verminder de kans dat kwetsbaarheden in productieworkloads terechtkomen
• De mogelijkheid van aanvallers beperken om gebruik te maken van de ontwikkelinfrastructuur of automatisering
• De tolerantie van toepassingen verbeteren voor veranderende aanvalstechnieken
• Ondersteuning voor nalevingsvereisten voor regelgeving en organisatie
• De snelheid van innovatie behouden zonder de operationele of beveiligingsrisico's te vergroten

Tips voor het navigeren in het traject

Voor het aannemen van DevSecOps zijn organisatie- en culturele wijzigingen vereist.

Veranderingen in onderwijs en cultuur

Dit zijn kritieke vroege stappen. Het team dat u hebt, moet nieuwe vaardigheden ontwikkelen en nieuwe perspectieven gebruiken om het DevSecOps-model te begrijpen.

Onderwijs- en cultuurverandering vergt tijd, focus, executive sponsorship en regelmatige opvolging om personen te helpen de waarde van de wijziging volledig te begrijpen en te zien.

Het veranderen van culturen en vaardigheden kan soms drastisch gebruikmaken van de professionele identiteit van individuen, waardoor het potentieel voor sterke weerstand ontstaat. Het is essentieel om te begrijpen en uit te drukken waarom, wat en hoe de verandering voor elke persoon en hun situatie is.

Verandering kost tijd

U kunt zich alleen zo snel verplaatsen als uw team zich kan aanpassen aan de gevolgen van het doen van dingen op nieuwe manieren. Teams moeten hun bestaande taken uitvoeren terwijl ze transformeren.

Het is essentieel om zorgvuldig te prioriteren wat het belangrijkst is en om de verwachtingen te beheren van hoe snel deze wijziging kan plaatsvinden.

Door te kiezen voor een stapsgewijze aanpak, waarbij de belangrijkste en meest fundamentele elementen eerst aan bod komen, is goed voor uw organisatie.

Verandering introduceert (tijdelijke) wrijving

Alle nieuwe technologieën, methodologieën en andere wijzigingen zorgen voor wrijving en verwarring. Het is essentieel om te focussen op gezonde wrijving die kritisch denken stimuleert om risico's te verminderen terwijl beschadigde wrijving wordt vermeden die processen met een beperkt voordeel of risicovermindering vertragen.

Beperkte bronnen

Een uitdaging waarmee organisaties doorgaans vroeg te maken krijgen, is om talent en vaardigheden te vinden in zowel beveiliging als toepassingsontwikkeling.

Naarmate organisaties effectiever gaan samenwerken, kunnen ze verborgen talent vinden, zoals ontwikkelaars met een beveiligingsmentaliteit of beveiligingsprofessionals met een ontwikkelingsachtergrond.

Doorlopende diensten

Apps veranderen snel. Naast nieuwe functies verandert de technische definitie en samenstelling van een toepassing fundamenteel met de introductie van technologieën zoals cloud, serverloos en AI.

Deze verschuiving verandert ontwikkelingsprocedures, toepassingsbeveiliging en biedt zelfs niet-ontwikkelaars de mogelijkheid om toepassingen te maken.

Een SRE-model overwegen

Sommige DevSecOps-implementaties combineren bewerkingen en beveiligingsverantwoordelijkheden in een SRE-rol (Site Reliability Engineer).

Hoewel een dergelijk model kan werken, is het vaak een extreme verandering van bestaande ondernemingscultuur en -praktijken.

Als u een SRE-model overweegt, raden we u aan om eerst beveiliging in Te sluiten in DevOps met praktische snelle overwinningen en incrementele voortgang die in deze richtlijnen worden beschreven om ervoor te zorgen dat u een goed rendement op investeringen (ROI) krijgt en aan onmiddellijke behoeften voldoet.

Hierdoor worden beveiligingsverantwoordelijkheden stapsgewijs toegevoegd aan uw operationele en ontwikkelingspersoneel, waardoor teams dichter bij een SRE-eindstatus komen.

Volgende stappen 

Meer informatie over aanbevolen procedures voor veilige ontwikkeling.