Bygg en säker CI/CD-pipeline med hjälp av DevSecOps

I denna, vår andra, artikel om resan mot DevSecOps tittar vi på ett specifikt område – hur man säkrar sin Continuous Integration / Continuous Delivery (CI/CD). I vår förra artikel; Varför DevSecOps behövs diskuterade vi övergripande om vad DevSecOps är och varför det är ett måste. Nu tittar vi närmare på de säkerhetshot man dagligen utsätts för i sin CI/CD-pipeline, varför de är farliga och vad man kan göra åt dem. Vi jämför också två av de mest kraftfulla verktygen på marknaden och kommer fram till vilket som skyddar bäst.

Vad är CI/CD?

CI/CD är en metod för att öka hastigheten i applikationsleveransen till dina miljöer genom att införa automatisering i de olika stegen av utvecklingsprocesserna. Innan containers började användas och skapade en mängd fördelar, släppte man normalt applikationer och uppdateringar en gång per kvartal eller ännu mer sällan. Driftsättning kunde innebära timmar, eller till och med dagar, av driftstopp utöver att det kräver stora arbetsinsatser från många personer och funktioner i organisationen.

CI/CD innebär alltså en pågående automatisering och kontinuerlig övervakning genom appens hela livscykel, från integrations- och testfaser till leverans och driftsättning. En s.k CI/CD-pipeline kompletteras genom att man integrerar verktyg som Common Vulnerabilities and Exposures (CVE), malware-scanners, Private Library Repo, Secret Management och Certificate Management. Tillsammans hanteras denna verktygslåda av utvecklare och driftsteam som agilt arbetar tillsammans med antingen en DevOps- eller Site Reliability Engineering (SRE) -strategi.

Typiska hot

En stor fördel hos alla containermiljöer är det underliggande operativsystemets runtime (kärna) som delas mellan containers. Denna typ av systemarkitektur kan minska applikationernas resursåtgång med 90 % ge motsvarande effekt på tiden det tar att distribuera applikationen. Att använda containers i sin infrastruktur har dock även en baksida. I en standardkonfiguration är kärnan inte isolerad. Detta betyder att om en container får root-åtkomst kan en container ändra det ursprungliga systemets runtime på servern och få kontroll över hela systemet. Detta kan i sin tur ge inkräktare åtkomst till hela servern, inklusive autentiseringsuppgifter. Detta är bara ett exempel på de hot som de flesta organisationer står inför, ofta utan att ens veta om det.

Ett annat typiskt hot är skadliga eller okontrollerade (rogue) processer, följderna av sådana processer kan innebära oönskad nätverkskommunikation, avlyssning eller att data exponeras.

Var har dessa hot sitt ursprung?

Låt oss börja med en kort introduktion till container images och hur man bygger dem. En container image består av kod, ett exempel på detta är en Docker-fil. En container image förpackar ditt operativsystem (OS) med några grundläggande verktyg tillsammans med din applikation för att komma igång. Varje version av applikationen har sin egen image som ger fullständig autonomi. En Docker-fil definierar:

  • Distributioner eller befintliga images
  • Applikationens beroenden
  • Applikationen
  • Start upp script (Entrypoint)

När en containerimage är byggd så kan sårbarheten existera i den men utgör ännu inte ett direkt hot. Detta är alltså ett bra tillfälle att scanna en containerimage för att kontrollera om det finns några sårbarheter eller malware.

Ovanstående diagram visar det typiska flöde som används av de flesta organisationer. Detta flöde visar hur utvecklaren laddar upp sin kod till sitt Git-repository. När en uppdatering till repositoryt utförs så utlöses en webhook som säger till CI / CD-tjänsten att köra den. I en fullt utbyggd pipeline kan körningen bestå av Build, Scan, Push, Deploy. Den viktiga delen som de flesta organisationer saknar är Scan. Så frågan är vad kan scanningsteget göra för dig och vilka alternativ har du?

Hur du ska skydda dig

Idag erbjuder marknaden, både den kommersiella och Open Source, ett antal väl fungerande produkter som ger containersäkerhet. Majoriteten av dessa verktyg innehåller liknande funktioner, skillnaden tenderar att ligga i vilka databaser som används för att få CVE och hur informationen bearbetas och presenteras för slutanvändaren.

Kommersiella produkter brukar även kunna scanna efter malware. Malware som har byggts in i en ”falsk” fil blir allt vanligare. Ett möjligt scenario är följande: för att distribuera en enkel webbapplikation går du till Docker Hub och hittar en färdig image, du lägger till lite av din egen kod och driftsätter sedan applikationen. När din container sedan startar upp så kan du se din webbapplikation, men vad händer egentligen i bakgrunden? Vid sidan av din applikation kanske en bitcoin-miner har startat. De vanligaste sätten på vilket detta kan hända är antingen genom en uppdatering som introducerar skadlig kod från den som ursprungligen byggt imagen, eller slarv från utvecklare som inte tillräckligt noggrant undersökt Dockerfilen och dess beroenden.

Även om det naturligtvis är lätt att lägga skulden på den som byggt applikationen så använder de flesta arbetsmiljöer ett agilt arbetssätt som inte ger mycket utrymme för en noggrann utredning varje gång man driftsätter en ny applikation eller en uppdatering. För att lösa båda dessa problem, som indikeras i figur 2 ovan, bör man alltså implementera ett steg i sin CI/CD-pipeline där man skannar efter dessa sårbarheter och därmed ser till att de aldrig följer med applikationen ut i drift.

Under de senaste åren har organisationer fokuserat på att utveckla och använda API: er för att mer effektivt kunna integrera sina applikationer. Detta ger möjligheter till att analys och förslag på åtgärder kan tillhandahållas direkt till utvecklingsteamet så att utvecklingslivscykeln inte påverkas eller fördröjs av enskilda säkerhetsåtgärder. Genom att tillhandahålla information direkt till utvecklingsteamet kan kodens kvalitet förbättras dramatiskt när deras förståelse och förmåga att säkra sin kod ökar.

Hur man väljer rätt lösning

Installation av de flesta tjänster har idag till stor del automatiserats. Det betyder att de flesta som har teknisk kunskap kan installera en containerscanner i sin miljö. Utmaningen ligger dock i hur man konfigurerar och hanterar sina tjänster. Det är viktigt att tjänsten i fråga används korrekt och konfigureras på ett sätt så att slutanvändaren lätt kan arbeta med den. Ta exempelvis container scanning, om det görs korrekt så har du integrerat scannern och dess policys i din CI/CD-pipeline. Men vad händer om imagen har ett hot? Slutanvändaren måste tydligt kunna se vad problemet är och hur man löser hotet. Det är här implementering, konfiguration och hantering av tjänsten kommer in.

När du ska välja lösning så finns det ett antal produkter tillgängliga baserade både på Open Source och på kommersiell teknik. I den här artikeln har vi valt att jämföra två tillgängliga produkter, en från respektive område. Vi har valt att från Open Source-världen jämföra Harbor (https://goharbor.io/) med den kommersiella lösningen Cloud One Container Security från Trend Micro. Våra initiala förväntningar var att en kommersiell produkt skulle vara mycket stark i jämförelsen på grund av att den är kommersiell och det finns
ekonomiska incitament att löpande utveckla och förbättra produkten när det gäller att upptäcka CVE och skadlig kod. Å andra sidan, efter att själva ha arbetat med Open Source i många år så är vi också väl medvetna om styrkan i hur effektivt Open Source-communityn samarbetar för att driva innovation och utveckling.

Malware, crypto mining och ransomware är utmaningar som varje företag står inför och som fortfarande till viss del är nytt för många detektorer på marknaden. Harbor har t ex i skrivande stund ingen malware scanner. För att lösa problemet finns det ett Open Source-projekt som heter Dagda. Dagda körs som en egen tjänst och fungerar som ett ytterligare steg i scanningsprocessen. Den använder en välkänd virusscanner som heter ClamAV. Förutom att scanna kan Dagda övervaka Docker daemon och köra Docker containers för att upptäcka onormala aktiviteter. Med de här två komponenterna tillsammans så hanterar du både sårbarheter och antivirus / anti-malware. Men även om denna kombination täcker grunderna så saknar ClamAV möjligheten att upptäcka de senaste avancerade hoten samt är resurskrävande gällande beräkningskapacitet.

När vi jämför ovan Open Source-lösning med Trend Micro Cloud One Container Security, så ser vi att Container Security kan göra allt som Harbor och Dagda kan tillsammans, och lite till. Företag som kör sina applikationer i molnet behöver kunna fånga upp de senaste hoten och för att på ett enkelt sätt rapportera till sin CI/CD-pipeline för omedelbar respons. Eftersom alla rapporter sparas kan man också generera rapporter för audits samt hjälpa organisationen att följa branschreglementen.

En stor fördel som Trend Micro har över alla Open Source-projekt är CVE-databasen. Trend Micro har sin egen databas från Zero Day Initative som 2019 upptäckte o publicerade 50% av alla publicerade sårbarheter samt ett partnerskap med Snyk (https://snyk.io/) för att ytterligare förbättra CVE-databasen utöver de offentliga databaserna.

När du på samma sätt jämför ClamAV med Trend Micro Malware Scanner, kompletterar Trend Micro, med sina långa erfarenhet och expertis inom området, ständigt sin produkt för att hitta de senaste hoten innan någon annan.

Cloud One Container Security tillhandahåller allt detta och mer. Slutsatsen blir att Trend Micro i detta fall ger ett värde som ingen just nu tillgänglig lösning baserad på Open Source kan.

När fler och fler applikationer driftsätts i plattformar baserade på Kubernetes så är det viktigt att hålla dina miljöer fria från sårbarheter och skadlig programvara När de en gång blivit infekterade så betyder det att hela Kubernetes-klustret kan vara infekterat och det enda sättet att vara helt säker på att ta bort skadlig kod är att skanna hela klustret. Med tanke på hur känsliga dessa miljöer är så är det alltså av största vikt att ha fullt uppdaterade CVE-databaser och de senaste versionerna av malware skanners.

Med alla nya produkter och lösningar som har kommit ut på marknaden de senaste åren, som dessutom ständigt uppdateras samt alla nya hot som dyker upp så är det svårt för en IT-organisation att ständigt hålla sig uppdaterad med den senaste kunskapen. Utöver det så är det också ett mycket komplext arbete att optimera sin CI/CD-pipeline. ELITS har, utifrån praktisk erfarenhet, under de senaste åren byggt upp sitt erbjudande inom detta viktiga kompetensområde. Det gör att du kan känna dig trygg lita på att vi kan hjälpa dig att se till att din utvecklingsmiljö och Kubernetes-infrastruktur är säker.

Vill du veta mer om hur du kan säkra dina applikationer?

Kontakta oss för att boka en kostnadsfri konsultation.


Läs mer om våra säkerhetslösningar.


Vid pennan

Mark Shine
IT-konsult.


Mattias Åsell
IT-konsult.


Nyfiken och vill veta mer?

Kontakta oss och få svar från någon av våra experter. Vänligen lämna dina uppgifter, så återkommer vi till dig snarast möjligt.

Kontakta oss idag!