Säkra beroenden

  • 5 minuter

En stor del av koden som finns i moderna program består av de bibliotek och beroenden som du, utvecklaren, väljer. Det här är en vanlig metod som sparar tid och pengar. Nackdelen är dock att du nu är ansvarig för den här koden – även om andra skrev den – eftersom du använde den i ditt projekt. Om en forskare (eller ännu värre, en hackare) upptäcker en sårbarhet i något av dessa bibliotek från tredje part, kommer samma fel sannolikt också att finnas i din app.

Att komponenter med kända säkerhetsrisker används är ett stort problem i vår bransch. Det är så problematiskt att det har gjort OWASP topp 10 lista över värsta webbprogram sårbarheter, hålla på # 9 i flera år.

Hitta kända säkerhetsrisker

Problemet är att veta när ett problem har identifierats. Att hålla våra bibliotek och beroenden uppdaterade (nr 4 i vår lista!) hjälper förstås, men det är också en bra idé att hålla reda på identifierade säkerhetsrisker som kan påverka ditt program.

Viktigt!

När ett system har en känd säkerhetsrisk är det mycket mer sannolikt att det också finns sårbarheter tillgängliga, kod som människor kan använda för att attackera dessa system. Om en exploatering offentliggörs är det viktigt att alla berörda system uppdateras omedelbart.

Mitre är en ideell organisation som sammanställer listan Common Vulnerabilities and Exposures. Den här listan är en offentligt sökbar uppsättning av kända cybersäkerhetsproblem i appar, bibliotek och ramverk. Om du hittar ett bibliotek eller en komponent i CVE-databasen har det kända säkerhetsrisker.

Säkerhetscommunityn skickar in problem när ett säkerhetsfel hittas i en produkt eller komponent. Varje publicerat problem tilldelas ett ID och visar det datum då det upptäcktes, en beskrivning av säkerhetsrisken och referenser till publicerade lösningar eller leverantörens anvisningar för problemet.

Så här kontrollerar du om du har kända säkerhetsrisker i dina tredje partskomponenter

Du kan ha ett dagligt larm i din telefon om att kontrollera den här listan, men som tur är finns det många verktyg som i stället kan hjälp oss att se om våra beroenden är sårbara. Du kan köra verktygen mot din kodbas eller (vilket är ännu bättre) lägga till dem i din CI/CD-rörledning för att automatiskt söka efter problem som en del av utvecklingsprocessen.

Du kan också använda vissa verktyg som skapats specifikt för statisk kodanalys för detta.

Mer information om riskerna med användningen av sårbara komponenter finns på OWASP-sidan specifikt för det här ämnet.

Sammanfattning

När du använder bibliotek eller andra komponenter från tredje part som en del av ditt program tar du också på dig eventuella risker som de kan ha. Det bästa sättet att minska denna risk är att se till att du endast använder komponenter utan några kända säkerhetsrisker.