Moderne toepassingen nemen in omvang en complexiteit toen en vragen n het licht van de veiligheid om geavanceerde hulpmiddelen. Ontwikkelaars en securityexperts vertrouwen op twee belangrijke categorieën voor hulpmiddelen om hun toepassingen en data te beschermen: static application security testing (sast) en software composition analysis (sca). Met verschillende doelen.
Sast is een gevestigde security-aanpak, met tientallen tools op de markt om uit te kiezen. Het scant de broncode of bytecode van de toepassing op bekende kwetsbaarheden in de software – defecten die een aanvaller toegang zouden kunnen verschaffen. Deze tools gaan automatisch over alle mogelijke paden en gebeurtenissen waarin een applicatie zich zou kunnen bevinden en kunnen naast de bugs waarnaar ze zochten, ook bugs ontdekken waar de ontwikkelaars zich niet bewust van waren.
Sast-tools hebben ook nadelen: ze zijn te traag, leiden tot valse positieven en zijn onhandig in gebruik. Uiteindelijk moeten de makers een compromis sluiten tussen de tijd die nodig is om een test uit te voeren, de volledigheid van de test en het aantal vals-positieven dat aanvaardbaar wordt geacht. Natuurlijk is geen van deze compromissen wenselijk, maar in het verleden hebben applicatieontwikkelaars er ten minste één moeten kiezen.
Sca helpt bij het beperken van risico’s die buiten de broncode van de ontwikkelaar liggen. Zo heeft de recente Log4Shell-kwetsbaarheid de potentiële impact laten zien van aanvallen op softwarepakketten van derden en opensource-pakketten die worden gebruikt als de basis van applicaties.
Moderne softwareapplicaties kunnen afhankelijk zijn van honderden opensource-pakketten die worden aangeduid als ‘dependencies’. Deze dependencies zijn vervolgens ook afhankelijk van andere opensource-pakketten waarvan de ontwikkelaars misschien niet eens op de hoogte zijn: de zogeheten transitive dependencies. Opensource-pakketten zijn beschikbaar voor duizenden bewerkingen en taken die ontwikkelaars anders zelf zouden moeten coderen. Het heeft geen zin het wiel opnieuw uit te vinden. Het is dan ook geen verrassing dat 98 procent van de applicaties opensource-software bevat en dat meer dan driekwart van de totale code in een applicatie waarschijnlijk opensource is.
Helaas kunnen de nauwkeurigheid en de mate waarin opensource-pakketten worden getest op securitylekken sterk variëren, vooral bij pakketten die niet langer actief worden onderhouden. Veel pakketten hebben meerdere varianten en oudere versies actief in omloop.
Sca-tests zijn gespecialiseerd in dit domein. Hierbij worden applicaties gescand op hun dependencies en transitive dependencies en deze worden gecorreleerd met databases met kwetsbaarheden om te begrijpen waar risico’s en securitylekken zijn verkregen van de code die van buiten de organisatie is gehaald. In het ideale geval worden het type en de ernst van de gevonden kwetsbaarheden vastgesteld en wordt advies gegeven over oplossingen en workarounds. Sca helpt organisaties ook met juridische risico’s door de licenties die bij de pakketten horen en de eventuele verantwoordelijkheden of aansprakelijkheden die daaruit voortvloeien te identificeren.
Reputatie
Zowel sast als sca spelen een belangrijke rol in de levenscyclus van softwareontwikkeling. Door ze te combineren, krijgen ontwikkelaars een holistisch beeld van de security van hun toepassing: sast voor het testen van broncode om securitylekken te vinden, en sca als een securitymethode voor applicaties voor het beheren van opensource-componenten.
Echter hebben veel sca-tools, net als sast-tools, de reputatie moeilijk te integreren te zijn en grote aantallen valse meldingen te veroorzaken. Als gevolg daarvan blijft de adoptie misschien laag, met minder dan de helft van organisaties die melden gebruik te maken van securitycontroles voor hun open source dependencies (blijkt het ‘State of Open Source Security-rapport’ van Snyk). Het combineren van beide benaderingen kon tot nu toe op weinig bijval rekenen in de ontwikkelingsgemeenschap. Hoewel de tekortkomingen op zichzelf vervelend zijn, is er weinig enthousiasme voor het verdubbelen van de tijd die nodig is voor het testen en het doorzoeken van twee keer zoveel resultaten voor valse positieven. Maar door moderne ontwikkelingen zijn er nieuwe hulpmiddelen gekomen die deze bezwaren opvangen en een weg voorwaarts bieden die zowel de veiligheid als de snelheid verbeteren.
Honderden wijzigingen
In moderne softwareontwikkeling waarbij ci/cd en devops volledig zijn omarmd, is het gewoon geen optie om een dag te wachten totdat de tests zijn voltooid en daarna nog een aantal voordat de fouten zijn verholpen. Ontwikkelteams kunnen elke dag honderden wijzigingen doorvoeren. Om dit beheersbaar te maken, moeten ze tijdens het bouwen zelf securitycontroles kunnen uitvoeren, ondersteund door tools die ervoor zorgen dat ze niet plotseling expert hoeven te zijn in een ander, gespecialiseerd domein.
Wat nodig is, is dat sast- en sca-tools in de eerste plaats ontwikkelaars helpen en zichzelf aanpassen aan de workflow en tools die door de ontwikkelaars worden gebruikt, in plaats van hen te dwingen zich te buigen over wat nodig is voor nieuwe tools. Een devsecops-workflow betekent dat ontwikkelaars hun best doen om ervoor te zorgen dat code veilig is terwijl deze wordt geschreven, niet als een afzonderlijke, latere stap die vertragingen veroorzaakt en ervoor zorgt dat code voortdurend heen en weer wordt doorgegeven tussen ontwikkel- en securityteams.
Ten tweede hebben de twee toolsets, in de huidige softwareomgeving, hoewel ze verschillende doelen vervullen, een gemeenschappelijk doel om ontwikkelaars in staat te stellen het voortouw te nemen op het gebied van applicatiesecurity, terwijl de code wordt gemaakt en bewerkt. Daarom is er een aanzienlijk voordeel in het feit dat de twee tools op een bepaalde manier worden geconsolideerd, gelijktijdig worden uitgevoerd of binnen dezelfde tool worden gefaciliteerd, om het aantal stappen, de leercurve en de vereiste complexiteit te verminderen.
Ten slotte omdat de testsoftware cloudgebaseerd is en de code geoptimaliseerd, loopt de ontwikkelaar geen vertraging op. Het flexibele, continue karakter van de moderne wereld van softwareontwikkeling vereist tools die in hetzelfde tempo werken. Praktijken en tools die in het verleden gebruikelijk waren, toen software-releases in een geleidelijk tempo kwamen, zijn gelukkig aan het verdwijnen en zowel de kwaliteit als de keuze die nu beschikbaar is, is hierdoor de beloning. Security kan als gevolg daarvan echter niet in gevaar komen, en daarom is het noodzakelijk om tools te kiezen die geschikt zijn voor het doel van de huidige omstandigheden.
