I løbet af de sidste par år virksomheder har været stigende deres brug af open source-kode til at hjælpe dem med at opbygge mere effektive programmer hurtigere.
Open source-komponenter skære ned applikationsudvikling tid ved at give kraftfulde funktioner, som udviklerne ikke behøver at skrive på deres egne, fremskynde udbredelsen af nye udgivelser. Danner rygraden i dagens software, open source komponenter omfatter nu mellem 60-80% af moderne applikationer.
Open Source biblioteker og værktøjer – en Ansvar for sikkerhed
Udviklingsteams kan nemt drage fordel af de forskellige open source-biblioteker og værktøjer, der er opdateret og leveret af open source-fællesskabet, tage dem fra populære ressourcer som GitHub.
Sammen med de klare fordele for udviklere, anvendelse open source-komponenter er ikke uden risiko. Holde software produkter sikkert kan være en udfordring og kræver de rigtige værktøjer til at løse de trusler. I tilfælde af open source-komponenter, i modsætning til proprietær kode, der er skrevet i internt af et selskab, den primære risiko for produkter ved hjælp af open source-software er kendt sårbarheder. Disse er sårbarheder, der er blevet offentliggjort på nettet og er tilgængelige for alle, for at se og eventuelt bruge til at udnytte ofre. Spørgsmålet om brug af komponenter med kendte sårbarheder er sikkert allerede på din radar, at have holdt en plet på OWASP berygtede Top 10 siden 2013.
Som tredjeparts software, open source-komponenter kan bruges i tusinder af produkter, og en sårbarhed findes i en enkelt komponent kan have indflydelse på en lang række anvendelser. Fordi open source-komponenter vedligeholdes af open source-samfundet, vi er afhængige af dem for at advare os til nye sårbarheder, når disse sikkerhedseksperter finder dem.
I forsøget på at holde andre sikkert, disse forskere vil sende deres resultater, som open source-komponenter er sårbare, og hvordan man udfører de udnytter til sikkerhedsbulletiner og databaser ligesom US. regeringsstøttede National Vulnerability Database (NVD). Selv om dette kan være nyttigt for årvågne sikkerhed hold, der kan bruge disse oplysninger til at hurtigt at lappe deres ansøgninger, hackere også ser her gratis efterretninger om, hvad til at målrette og hvordan.
Udfordringen her er i opholder et skridt foran angriberne. Desværre, det store flertal af udviklingsteams er simpelthen uvidende om, hvor meget deres produkter er afhængige af open source-komponenter, og ikke holde en ordentlig opgørelse over, hvilke af dem, de har i deres produkter. Dette kan være et vigtigt problem, da de kan målrettes gennem en sårbar komponent, som de ikke engang vidste, at de brugte.
Dette er, hvad der skete i Equifax sagen i september sidste år, da selskabet blev brudt gennem en sårbar version af Apache Struts 2 (CVE-2017-5638), fører til tyveri af 145.9 million personligt identificerbare oplysninger optegnelser, herunder social sikring og kreditkortnumre. Ifølge rapporter, angrebet fandt sted to måneder efter, at sårbarheden blev afsløret, pinligt virksomheden for ikke at tage de nødvendige skridt til at holde deres data sikre.
Automatisering er kritisk til sikring Open Source komponenter
Til dels på grund den hurtige udvikling, og stor afhængighed af open source-komponenter til at holde tidsplanen, manuel sporing af open source-komponenter er simpelthen ikke en mulighed for organisationer, der ønsker at forblive sikker.
Skalerbarhed er nøglen, og kun automatiserede løsninger giver et svar til, hvordan man kan blive på toppen af hver open source komponent, der kommer ind i udviklingsmiljøet. Kun Software Sammensætning Analyse (SCA) værktøjer er i stand til at identificere open source-komponenter og advare sikkerhed hold til risici.
For korrekt at implementere en open source sikkerhedsproces, især i en DevOps model, sikkerhed og udviklingsteams har brug for at arbejde sammen om at fange problemer tidligt, vedtage et skift tilbage tilgang. Når de integrerer en SCA værktøj i deres CI / CD-server, værktøjerne kan identificere sårbare komponenter, inden de gør det i opbygningen, forhindre dyrere operationer senere, når udviklerne skulle rive og erstatte den sårbare komponent før en udgivelse.
Samtidig, er det vigtigt at skifte højre med beskeder, når nye sårbarheder opdages, giver sikkerhed hold advarslen, de har brug for hurtigt at lappe deres produkter, før hackere forsøger at gøre deres brud.
Ved at gennemføre en kontinuerlig, automatiseret SCA værktøj, organisationer kan håndhæve politikker på tværs af deres udvikling og produkter, betydeligt mindske risiciene for kendte sårbarheder i deres open source-forbrug komponent.
Om forfatteren: Zev Brodsky
Om dagen, Zev er Community Manager hos open source-sikkerhed forvaltning leder WhiteSource. Om natten, han er en taco entusiast, så som så brikker spiller, og samler af sjældne frimærker.
