AST: Continuous Visibility on Modern Application Development Security Risks
AST: Continuous Visibility on Modern Application Development Security Risks
Wat is Modern Application Development? (MAD)
In het nieuwe tijdperk van softwareontwikkeling kunt u zich voorstellen dat u applicaties ontwikkelt die overal en op elke basisinfrastructuur op schaal kunnen worden uitgevoerd.
MAD brengt dit in de praktijk via de cloudgebaseerde, native faciliteiten die de services die software biedt, loskoppelt van eerdere ontwerp-, ontwikkelings- en implementatiepraktijken, waardoor teams uiteindelijk op grotere schaal kunnen werken dan voorheen mogelijk was. Tegenwoordig moeten we ervan uitgaan dat voor organisaties het grootste deel van een applicatie bestaat uit code, dat alles code is en dat niets gedefinieerd wordt met de oude operationele aspecten van eerdere monolithische software builds.
In het verleden werd van software verwacht dat deze op een traditionele, goed gedefinieerde manier werd ontwikkeld, vaak onpremise of in een datacenter. Die aanpak vereiste een groot aantal fysieke servers om de verschillende delen van een applicatie uit te voeren, de ene server werd gebruikt voor de webgebaseerde gebruikersinterface, een andere voor een gegevenstoegangslaag weer een andere om een gegevensarchief aan te bieden, enzovoort.
MAD verlegt de operationele softwaregrenzen, waardoor teams in staat worden gesteld om meer tijd te besteden aan het bouwen van innovatieve features en functies in plaats van te verspillen tijd om na te denken over de effecten op onderliggende systemen. Met MAD, zullen kleine storingen systeemuitval niet veroorzaken of beïnvloeden omdat services zijn losgekoppeld van waar ze op draaien. Wat ontwikkelaars verplicht hun manier van denken fundamenteel te veranderen.
De snelheid van MAD
MAD werkt met zeer korte doorvoertijden. In eerste instantie kan dit frictie oproepen bij de ontwikkelaars vanwege de lineaire mindset die is ingebakken door hun eerdere ervaringen.
Alles binnen MAD is geïntegreerd en geautomatiseerd, waarbij alle door mensen veroorzaakte vertragingen worden verwijderd of worden overwonnen. MAD beïnvloedt ontwikkeling, levering en ontwikkeling zo radicaal dat velen in eerste instantie de potentie ervan misschien niet accepteren door puur onbegrip of angst voor het onbekende.
MAD maakt het in veel gevallen mogelijk om een equivalent van 5 jaar softwareontwikkeling te leveren in 1 jaar tijd.
Waarom juist nu MAD?
Traditionele softwareontwikkeling is vaak te vergelijken met een trein. Treinwagons (goederenwagon, personenwagon, tankwagon, etc.) zijn fysiek één voor één in een lijn verbonden met een locomotief, waardoor uiteindelijk een lange trein in ontstaat. De wagons goed aan elkaar verbinden zorgt ervoor dat de trein als geheel veilig op reis kan is een zeer belangrijk onderdeel van het proces. Echter kan de trein pas gaan rijden als alles op de juiste manier aan elkaar verbonden is.
Tijdens softwareontwikkeling kunnen vertragingen ontstaan doordat de teams te lang moeten wachten op interne zaken en procedures welke veelal niet veel van doen hebben met het daadwerkelijk ontwikkelen van de software.
MAD is gecreëerd met de gedachten om de lineaire interne processen te elimineren en te vervangen voor een parallel opgezette methode.
Time-to-market-eisen in het huidige competitieve applicatie landschap vragen om snelheid. MAD stelt ontwikkelaars in staat om te profiteren van cloud-native technologieën tijdens het ontwerpproces en vervolgens dezelfde logica toe te past op het modelleren, bouwen en opleveren van de verschillende fasen. Het laat ontwikkelaars innoveren door middel van een “bouwstenen” aanpak voor het optimaliseren van softwareontwikkeling, het versnellen van levering en een verbetering van de kwaliteit van hun deliverables.
Het doet de barrières tussen ontwikkeling, operations en infrastructuur verdwijnen. Steeds meer organisaties beginnen ten tijde van de huidige digitale transformatie meer en meer de pluspunten van MAD te ontdekken.
MAD Architectuur
Een iteratieve mindset is de kern van MAD, en het vereist een soort van hersenspoelen. Ervoor zorgdragen dat de feedbackloops tussen interne processen en de externe klant ervaringen op orde zijn. MAD incorporeert de feedback in het samenstellings-proces wat standaard plaatsvindt omdat een van de uitgangsposities van MAD is, het verhogen van het automatiseringsniveau.
MAD draait ook om de kwaliteit van het eindproduct sinds continu functioneel en applicatie security testen fundamentele onderdelen van MAD zijn.
MAD vertrouwt niet op een monolithische, lineaire benadering van softwareontwikkeling en implementatie. In plaats daarvan zou je het kunnen vergelijken met een lego bouwwerk. Elk blokje heeft zijn eigen doel, maar ze passen allemaal perfect bij elkaar en versterken samen het gehele bouwwerk.
De componenten (legoblokken) van MAD die deze nieuwe architectuur ondersteunen zijn:
Applicatie code:
- Open source (3rd party) code
- Microservices/Serverless code
- API-code
Container code
Infrastructure as code
Security Risico’s volgens MAD
In de context van een bedrijf zijn beveiligingsrisico's - in de vorm van gegevensverlies, inbreuken, ransomware, en meer zeer actueel. In software worden beveiligingsrisico's worden voornamelijk afgeleid van exploiteerbare kwetsbaarheden, zeker wanneer de software draait in productie.
Met betrekking tot softwarerisico's zoals deze beschreven worden in de OWASP Top 10, CWE/ SANS Top 25 en andere soortgelijke standaarden, hebben organisaties normaal gesproken applicatie security testing (AST) processen ingericht om deze risico's te helpen detecteren en te adresseren.
Deze lijsten zijn uitstekende uitgangspunten om softwareontwikkelaars en AppSec-professionals (Application Security) te helpen om veilige applicaties te bouwen en softwarerisico's kunt beperken.
Echter specifiek met betrekking op MAD wordt het risicolandschap steeds groter door een steeds groter wordende reeks risico’s die zich voordoen. Het gemiddelde risico wordt als maar groter ook door de kwetsbaarheden welke (nog) niet beschreven zijn in de verschillende standaarden. MAD kijkt naast de standaarden ook verder en stelt organisaties in staat ook de risico’s aan te pakken welke niet in de verschillende standaarden beschreven maar ook een geheel nieuwe reeks risico's die zich voordoen in MAD-initiatieven.
Checkmarx AST2.0 en MAD
Checkmarx heeft een nieuw applicatie security testing platform (AST 2.0) ontwikkeld dat inspeelt op de MAD methodologie.
Dit platform brengt de verschillende testtechnieken samen en correleert de bevindingen van deze technieken in een uniform dashboard. Niet alleen wordt de code getest op basis van SAST (Statische applicatie security testing) maar ook de opensource componenten worden doormiddel van SCA geïnspecteerd en de infrastructure as code wordt gecontroleerd door de KICS Engine.
In combinatie met de naadloze integratie met de bestaande tooling welke dagelijks gebruikt wordt stelt de organisatie in staat te werken volgens de MAD methodologie.
AST: Continuous Visibility on Modern Application Development Security Risks
AST: Continuous Visibility on Modern Application Development Security Risks
Wat is Modern Application Development? (MAD)
In het nieuwe tijdperk van softwareontwikkeling kunt u zich voorstellen dat u applicaties ontwikkelt die overal en op elke basisinfrastructuur op schaal kunnen worden uitgevoerd.
MAD brengt dit in de praktijk via de cloudgebaseerde, native faciliteiten die de services die software biedt, loskoppelt van eerdere ontwerp-, ontwikkelings- en implementatiepraktijken, waardoor teams uiteindelijk op grotere schaal kunnen werken dan voorheen mogelijk was. Tegenwoordig moeten we ervan uitgaan dat voor organisaties het grootste deel van een applicatie bestaat uit code, dat alles code is en dat niets gedefinieerd wordt met de oude operationele aspecten van eerdere monolithische software builds.
In het verleden werd van software verwacht dat deze op een traditionele, goed gedefinieerde manier werd ontwikkeld, vaak onpremise of in een datacenter. Die aanpak vereiste een groot aantal fysieke servers om de verschillende delen van een applicatie uit te voeren, de ene server werd gebruikt voor de webgebaseerde gebruikersinterface, een andere voor een gegevenstoegangslaag weer een andere om een gegevensarchief aan te bieden, enzovoort.
MAD verlegt de operationele softwaregrenzen, waardoor teams in staat worden gesteld om meer tijd te besteden aan het bouwen van innovatieve features en functies in plaats van te verspillen tijd om na te denken over de effecten op onderliggende systemen. Met MAD, zullen kleine storingen systeemuitval niet veroorzaken of beïnvloeden omdat services zijn losgekoppeld van waar ze op draaien. Wat ontwikkelaars verplicht hun manier van denken fundamenteel te veranderen.
De snelheid van MAD
MAD werkt met zeer korte doorvoertijden. In eerste instantie kan dit frictie oproepen bij de ontwikkelaars vanwege de lineaire mindset die is ingebakken door hun eerdere ervaringen.
Alles binnen MAD is geïntegreerd en geautomatiseerd, waarbij alle door mensen veroorzaakte vertragingen worden verwijderd of worden overwonnen. MAD beïnvloedt ontwikkeling, levering en ontwikkeling zo radicaal dat velen in eerste instantie de potentie ervan misschien niet accepteren door puur onbegrip of angst voor het onbekende.
MAD maakt het in veel gevallen mogelijk om een equivalent van 5 jaar softwareontwikkeling te leveren in 1 jaar tijd.
Waarom juist nu MAD?
Traditionele softwareontwikkeling is vaak te vergelijken met een trein. Treinwagons (goederenwagon, personenwagon, tankwagon, etc.) zijn fysiek één voor één in een lijn verbonden met een locomotief, waardoor uiteindelijk een lange trein in ontstaat. De wagons goed aan elkaar verbinden zorgt ervoor dat de trein als geheel veilig op reis kan is een zeer belangrijk onderdeel van het proces. Echter kan de trein pas gaan rijden als alles op de juiste manier aan elkaar verbonden is.
Tijdens softwareontwikkeling kunnen vertragingen ontstaan doordat de teams te lang moeten wachten op interne zaken en procedures welke veelal niet veel van doen hebben met het daadwerkelijk ontwikkelen van de software.
MAD is gecreëerd met de gedachten om de lineaire interne processen te elimineren en te vervangen voor een parallel opgezette methode.
Time-to-market-eisen in het huidige competitieve applicatie landschap vragen om snelheid. MAD stelt ontwikkelaars in staat om te profiteren van cloud-native technologieën tijdens het ontwerpproces en vervolgens dezelfde logica toe te past op het modelleren, bouwen en opleveren van de verschillende fasen. Het laat ontwikkelaars innoveren door middel van een “bouwstenen” aanpak voor het optimaliseren van softwareontwikkeling, het versnellen van levering en een verbetering van de kwaliteit van hun deliverables.
Het doet de barrières tussen ontwikkeling, operations en infrastructuur verdwijnen. Steeds meer organisaties beginnen ten tijde van de huidige digitale transformatie meer en meer de pluspunten van MAD te ontdekken.
MAD Architectuur
Een iteratieve mindset is de kern van MAD, en het vereist een soort van hersenspoelen. Ervoor zorgdragen dat de feedbackloops tussen interne processen en de externe klant ervaringen op orde zijn. MAD incorporeert de feedback in het samenstellings-proces wat standaard plaatsvindt omdat een van de uitgangsposities van MAD is, het verhogen van het automatiseringsniveau.
MAD draait ook om de kwaliteit van het eindproduct sinds continu functioneel en applicatie security testen fundamentele onderdelen van MAD zijn.
MAD vertrouwt niet op een monolithische, lineaire benadering van softwareontwikkeling en implementatie. In plaats daarvan zou je het kunnen vergelijken met een lego bouwwerk. Elk blokje heeft zijn eigen doel, maar ze passen allemaal perfect bij elkaar en versterken samen het gehele bouwwerk.
De componenten (legoblokken) van MAD die deze nieuwe architectuur ondersteunen zijn:
Applicatie code:
- Open source (3rd party) code
- Microservices/Serverless code
- API-code
Container code
Infrastructure as code
Security Risico’s volgens MAD
In de context van een bedrijf zijn beveiligingsrisico's - in de vorm van gegevensverlies, inbreuken, ransomware, en meer zeer actueel. In software worden beveiligingsrisico's worden voornamelijk afgeleid van exploiteerbare kwetsbaarheden, zeker wanneer de software draait in productie.
Met betrekking tot softwarerisico's zoals deze beschreven worden in de OWASP Top 10, CWE/ SANS Top 25 en andere soortgelijke standaarden, hebben organisaties normaal gesproken applicatie security testing (AST) processen ingericht om deze risico's te helpen detecteren en te adresseren.
Deze lijsten zijn uitstekende uitgangspunten om softwareontwikkelaars en AppSec-professionals (Application Security) te helpen om veilige applicaties te bouwen en softwarerisico's kunt beperken.
Echter specifiek met betrekking op MAD wordt het risicolandschap steeds groter door een steeds groter wordende reeks risico’s die zich voordoen. Het gemiddelde risico wordt als maar groter ook door de kwetsbaarheden welke (nog) niet beschreven zijn in de verschillende standaarden. MAD kijkt naast de standaarden ook verder en stelt organisaties in staat ook de risico’s aan te pakken welke niet in de verschillende standaarden beschreven maar ook een geheel nieuwe reeks risico's die zich voordoen in MAD-initiatieven.
Checkmarx AST2.0 en MAD
Checkmarx heeft een nieuw applicatie security testing platform (AST 2.0) ontwikkeld dat inspeelt op de MAD methodologie.
Dit platform brengt de verschillende testtechnieken samen en correleert de bevindingen van deze technieken in een uniform dashboard. Niet alleen wordt de code getest op basis van SAST (Statische applicatie security testing) maar ook de opensource componenten worden doormiddel van SCA geïnspecteerd en de infrastructure as code wordt gecontroleerd door de KICS Engine.
In combinatie met de naadloze integratie met de bestaande tooling welke dagelijks gebruikt wordt stelt de organisatie in staat te werken volgens de MAD methodologie.