CI/CD-sårbarhetsskanning – så påbörjar du din DevSecOps-resa

DevSecOps är en naturlig utveckling

DevOps (Development och Operations) är en uppsättning metoder och kulturella principer som automatiserar och integrerar processer mellan utveckling och drift. Det är en naturlig utveckling av de arbetssätt som infördes med CI/CD.

DevSecOps (Development, Security och Operations) är ett förhållningssätt till kultur, automatisering och plattformsdesign som integrerar säkerhet som ett gemensamt ansvar genom hela utvecklingscykeln. Inte oväntat är det bara nästa steg i utvecklingen av hur vi utvecklar mjukvara.

DevSecOps omfattar mycket

DevSecOps handlar om mer än att bara skanna efter sårbarheter. Titta på bilden nedan, framtagen av SANS Institute.

Källa: https://twitter.com/sanscloudsec/status/968590339371126784

Som du kan se omfattar en säker DevOps-verktygskedja allt från statisk applikationssäkerhetstestning (SAST) och dynamisk applikationssäkerhetstestning (DAST) till säkerhetsgranskning och övervakning, och mycket, mycket mer. DevSecOps kan kännas lite överväldigande eftersom det finns mycket att tänka på och ett stort område att täcka.

Men ur ett automatiseringsperspektiv är det en bra början att leta efter sårbarheter i dina CI/CD-pipelines.

Att skanna din kod efter sårbarheter, fel eller svagheter är en viktig del av effektiv mjukvarusäkerhet. Det är den naturliga platsen att börja på och där du har störst kontroll i ett ständigt föränderligt hotlandskap.

CI/CD-pipelines ligger tidigt i utvecklingsprocessen. De är en viktig kontrollpunkt för att säkerställa Continuous Delivery, kräver vanligtvis inte någon stor investering för att komma i gång och kan implementeras i många olika CI-servrar. Om du kan köra dem framgångsrikt i en pipeline är chansen stor att du också kan integrera dem med ditt buildsysten längre fram. Det innebär i praktiken att förskjuta arbetet så långt åt vänster som möjligt.

Pipelines är också utmärkta för att utvärdera olika verktyg utan att störa befintliga utvecklingsprocesser eller utvecklare, åtminstone tills du har hittat lämpliga verktyg och tekniker.

Resten av den här bloggen är därför främst skriven med fokus på att automatisera sårbarhetsidentifiering i CI/CD-pipelines.

Håll fokus på målet

Teknikstackar varierar en hel del mellan olika organisationer. Det vore omöjligt att täcka alla tänkbara stackar. Men om du har ett någorlunda modernt sätt att arbeta med mjukvaruutveckling är det sannolikt klokt att införa sårbarhetsskanning i dina pipelines inom följande områden.

Analysera källkod efter sårbarheter

Var annars skulle du börja om inte med säkra kodningsmetoder? Pull requests/kodgranskningar och riktlinjer för kodning är förstås till stor hjälp för att införa säkra kodningsmetoder. Men utvecklare är människor, och misstag händer.

Dessutom förändras hotlandskapet ständigt, och det som tidigare ansågs vara en säker kodningsmetod kanske inte fortsätter att vara det. Att automatisera kodanalysen med ett verktyg eller en teknik som kan hålla jämna steg med det föränderliga hotlandskapet är ett mer hållbart och sammanhängande arbetssätt.

Analysera tredjepartsberoenden efter sårbarheter

Applikationers beroendegrafer är djupare än någonsin, och användningen av open source-mjukvara har ökat explosionsartat jämfört med för bara fem år sedan.

Jag läste en äldre rapport från 2014 av Contrast Security, som hävdade att nedladdningar av komponenter fördubblades från 6 miljarder till 13 miljarder under två år. Det är en hisnande tillväxt, men helt trovärdigt. Jag skulle till och med säga att open source-beroenden från tredje part är allestädes närvarande i dagens mjukvara.

Det har nyligen förekommit flera uppmärksammade attacker mot mjukvarans leveranskedja. Det har blivit tydligt att tredjepartsberoenden medför betydande sårbarhetsrisker och bör ingå i all sårbarhetsidentifiering du gör.

Analysera container images efter sårbarheter

Har du hört uttrycket ”software is eating the world”? Ibland känns det som att containrar äter upp mjukvaruutvecklingen. Och det av goda skäl.

Möjligheten att använda ett standardiserat paketeringsformat och samtidigt leverera en oföränderlig miljö där vår mjukvara kan köras är ett stort steg framåt på många sätt. Men som med alla framsteg finns det saker att ta hänsyn till:

• Sårbara bibliotek kan läggas till i en image under byggtiden.

• Sättet som images byggs med hjälp av lager innebär att sårbarheter kan döljas och vara svåra att upptäcka.

• Längst ner i en image finns en basimage som representerar ett operativsystem. Precis som alla operativsystem kan det innehålla sårbarheter.

• Processen som körs i en container kan ha utökade behörigheter som den inte behöver.

Det ovanstående betyder inte att du inte ska använda containrar, utan att du bör skanna dina images. Då kan du upptäcka sårbarheter i din mjukvara och i den miljö där den ska köras, när allt levereras som ett enda paket.

Analysera Infrastructure as Code (IaC) för sårbarheter

I takt med att DevOps-metoder och -kultur får allt större genomslag blir det allt vanligare att definiera infrastrukturen som kod.

Men kod är kod, oavsett om den används för infrastruktur eller något annat. Möjligheten att snabbt använda och skala infrastrukturresurser innebär också att felkonfigurationer kan skapa säkerhetsproblem snabbare och i större skala.

Därför är det viktigt att upptäcka felkonfigurationer och säkerhetsproblem i IaC, och det bör vara en standarddel av processen för sårbarhetsskanning.

Några erfarenheter

Utifrån de erfarenheter jag har samlat på mig genom att implementera sårbarhetsskanning i pipelines rekommenderar jag att du tar hänsyn till faktorerna nedan när du börjar arbeta med DevSecOps i dina CI/CD-pipelines.

Tänk på kompatibilitet och användarvänlighet

Hitta en teknik eller ett verktyg som täcker så mycket som möjligt. Om din nuvarande teknikstack bara består av node.js och .Net betyder det inte att den alltid kommer att vara så begränsad eller statisk. Till exempel kan `npm audit` eller `yarn audit` hjälpa dig att komma igång snabbt, men de håller sannolikt inte över tid.

Du bör naturligtvis också ta hänsyn till hur väl en teknik eller ett verktyg integreras i ditt CI/CD-arbetssätt. Det är trots allt huvudfokus. Ställ dig själv frågor som:

• Returnerar det rimliga exitkoder som fungerar bra med automatisering?

• Hur väl integreras det med de många CI-servrar som finns tillgängliga i dag?

• Behöver jag implementera speciallösningar eller wrappers för att få det att fungera väl i mitt pipelineflöde?

Du förstår vad jag menar. Bredast möjliga stöd för språk och CI-servrar, tillsammans med användarvänlighet, är de viktigaste faktorerna.

Konfigurerbarhet är avgörande

Min erfarenhet är att du med stor sannolikhet kommer att stöta på falska positiva resultat. Alla säkerhetsproblem är inte lika kritiska för alla kodbaser, och det kommer att finnas fynd som inte är relevanta.

Därför är det viktigt att kunna definiera vad som gäller för en viss kodbas genom konfiguration, helst på ett sätt som kan spåras och granskas tillsammans med kodbasen. Till exempel genom en konfigurationsfil eller annoteringar i kodbasen.

Antalet problem kan vara stort, särskilt i äldre applikationer, och det behövs ofta ett gradvis tillvägagångssätt för att åtgärda dem. I sådana fall måste du kunna ange tröskelvärden som avgör när pipelinen ska avbrytas om de överskrids.

• Du bör kunna konfigurera en allvarlighetsnivå så att pipelinen misslyckas om det finns kritiska fynd.

• Du bör kunna konfigurera ett tröskelvärde baserat på en allvarlighetsgrad som stoppar din pipeline. Exempelvis har jag nu tre (3) fynd med hög allvarlighetsgrad. Låt pipelinen misslyckas om antalet fynd med hög allvarlighetsgrad överstiger tröskelvärdet tre (3).

Rapportering är avgörande

Eftersom de flesta utvecklare och DevOps-utövare inte är säkerhetsexperter bör resultatet och rapporteringen från den valda tekniken eller det valda verktyget fokusera på att hjälpa dem att förstå fynden, hur de introduceras och vad de faktiskt kan göra åt dem. Tänk därför på följande:

• En rapport bör ge omfattande vägledning om hur och var fynd har introducerats. Till exempel den specifika filen och raden samt hela beroendekedjan, om fyndet introducerades genom användning av en viss modul och version.

• En rapport bör ge en tydlig, kortfattad och lättförståelig beskrivning av fyndet.

• En rapport bör ge utmärkt vägledning om hur du kan åtgärda eventuella fynd. Till exempel att uppgradera beroende Y från version 3 till version 4.

• En rapport bör endast innehålla relevanta fynd. Den bör inte rapportera fynd som du har konfigurerat som irrelevanta för kodbasen.

• Tekniken/verktyget bör generera rapporten. Du ska inte behöva använda något annat verktyg för att skapa den. Det kommer sannolikt inte att uppfylla dina behov.

OWASP är din vän

Open Web Application Security Project (OWASP) är en ideell stiftelse som arbetar för att förbättra säkerheten i mjukvara. OWASP:s mål är att: "Göra det möjligt för organisationer att utforma, utveckla, anskaffa, drifta och underhålla applikationer som går att lita på."

OWASP erbjuder mängder av värdefull information, utöver projekt och verktyg, som hjälper dig att nå dina säkerhetsmål. Om du är begränsad till programvara med öppen källkod rekommenderar jag att du tittar på de relevanta projekten.

Om du utvecklar webbapplikationer behöver du definitivt känna till OWASP Top Ten, som i huvudsak är en sammanställning av de tio vanligaste och mest kritiska säkerhetsriskerna för webbapplikationer. Jag skulle till och med säga att den teknik eller det verktyg du använder bör ha stöd för OWASP Top Ten.

Du måste åtgärda dem

Att identifiera sårbarheter i din pipeline är en bra start på din DevSecOps-resa. Men du är inte klar. Du måste göra något åt dem.

Definiera en åtgärdsstrategi för att hantera sårbarheterna:

• Definiera åtgärdsprioriteringar. Till exempel måste kritiska fynd av typ X åtgärdas omedelbart.

• Definiera processen för att klassificera en sårbarhet som irrelevant.

• Inför sårbarheter som kriterier vid kodgranskningar och se till att de är synliga under granskningsprocessen.

• Och mycket annat, beroende på din situation …

Sammanfattningsvis

Att enbart använda verktyg och tekniker med öppen källkod leder sannolikt till en fragmenterad lösning. Även om dessa verktyg och tekniker definitivt skapar värde har de alla sina egenheter, och det är inte alltid lätt att se vad de täcker och hur väl de gör det. De har också olika utdataformat, vilket gör det svårt att få en övergripande bild av din säkerhetsstatus.

Att implementera sårbarhetsskanning i dina pipelines är en bra start, men det räcker på inget sätt i sig självt. Du bör använda detta för att förhindra att nya sårbarheter hamnar i din kod. Men du hittar bara sårbarheter under pipelinekörningen. Nya sårbarheter kan upptäckas mellan pipelinekörningar, vilket gör din mjukvara sårbar under en viss tid. Detta gäller särskilt stabila kodbaser som inte ändras ofta.

Jag rekommenderar att du tittar på några betalda tekniker/plattformar i stället för att välja en renodlad open source-strategi. Jag gillar Snyk eftersom det integreras väl med CI/CD och många CI-servrar och därmed täcker mina huvudsakliga fokusområden. Det ger också utmärkta rapporter med bra vägledning och låter dig övervaka din kodbas för att hitta nya sårbarheter mellan pipelinekörningar. Slutligen gillar jag verkligen hur Snyk samlar fynden i en enda dashboard, vilket ger en bättre förståelse för din övergripande säkerhetsstatus.