Este viitorul open source sub amenințare?

Software-ul cu sursă deschisă (OSS) este coloana vertebrală a arhitecturii aplicațiilor de astăzi. Prin accelerarea timpului de lansare pe piață și reducerea sarcinii pentru dezvoltatorii adesea suprasolicitați, open source și-a consolidat poziția revoluționară în peisajul DevOps. Deși transformă profund în dezvoltarea aplicațiilor moderne, copierea și lipirea open source continuă să reprezinte un risc major de securitate atât pentru organizații, cât și pentru indivizi. Combaterea acestui lucru necesită fie o listă neagră totală de cod sursă deschisă, fie implementarea proactivă a contramăsurilor, cum ar fi o soluție WAF de nouă generație.

Codul terților este vital pentru dezvoltarea aplicației

Bibliotecile sunt rezerve incredibil de utile de cod sursă pentru componentele aplicațiilor web sau mobile. Aceste biblioteci pot fi open-source – disponibile pentru toată lumea fără costuri – sau proprietare, ceea ce blochează codul din spatele plății. Deși open source își revendică o mulțime de glorie, codul proprietar joacă, de asemenea, un rol în funcționarea continuă a aplicațiilor de întreprindere.

Acest software terță parte, atunci când este utilizat în mod responsabil, împiedică dezvoltatorii să reinventeze constant roata. Acest lucru îmbunătățește drastic eficiența procesului de dezvoltare, ajutând în același timp la producerea unui produs final de înaltă calitate. În cele din urmă, utilizarea liberă și liberală a codului open source creează o buclă de feedback pozitiv, permițând dezvoltatorilor să-și lanseze produsul minim viabil mai rapid, ceea ce deschide calea pentru colectarea și implementarea rapidă a feedback-ului și evaluării utilizatorilor. Deși dezvoltatorii sunt profund conștienți de poziția critică a open source în cadrul procesului DevOps, directorii sunt adesea surprinși să afle că 80% din codul care acceptă aplicațiile moderne provine din codul preexistent.

Pericolul umbră al dependențelor tranzitive

Nu este o știre că codul open source vine cu riscuri. Punctele slabe recente, cum ar fi Log4j și HeartBleed, au plasat irevocabil riscul open source pe hartă. Ceea ce rămâne o zonă în creștere de înțelegere este frecvența absolută cu care este folosită sursa deschisă și caracterul ascuns cu care vulnerabilitățile se pot strecura într-un proiect activ. În ciuda riscului continuu prezentat de proiectele open source, au fost efectuate foarte puține cercetări asupra tipului specific de risc pe care îl prezintă open source. Cercetătorii de la Endor Labs și-au propus să schimbe acest lucru clarificând originea amenințărilor majore OSS.

În cadrul software-ului, dependențele tranzitive descriu o relație unică indirectă între două componente. De exemplu, să presupunem că echipa ta de dezvoltare adaugă pachetul B unui proiect în derulare. Pachetul B, la rândul său, descarcă automat pachetul C. În acest scenariu, în timp ce software-ul în curs de dezvoltare se bucură de o relație directă cu pachetul B, pachetul C rămâne pândit în fundal – integral, dar în mare măsură invizibil. Frustrarea oricărei încercări de practici de dezvoltare mai sigure este faptul că doar 5% din dependențele de software open source sunt selectate manual pentru implementare în cadrul procesului DevOps. În acest mod, majoritatea dependențelor sunt pur și simplu introduse automat în baza de cod. Aceasta descrie sursa unei vulnerabilități tranzitive. Un raport recent al Endor Labs a constatat că 95% dintre vulnerabilitățile open source provin din dependențe tranzitive .

Datele au fost compilate din raportul Core Infrastructure Census II, care enumeră cel mai popular software open-source gratuit. Aceste date au fost apoi îmbogățite cu alte surse care au permis cercetătorilor Endor să scaneze managerii de pachete populare și bibliotecile OSS. Cercetătorii au descoperit că – din 254 de pachete menționate în datele Recensământului II – majoritatea suferă de o medie de 14 dependențe tranzitive. Într-un vid, 14 poate să nu pară șocant de mare, dar majoritatea aplicațiilor se bazează pe zeci – dacă nu sute – de dependențe directe; omologii lor tranzitivi cresc exponențial.

Preocuparea majoră exprimată de cercetători se bazează pe subestimarea pe scară largă a problemei de către industrie. Directorii continuă să submineze cantitatea de cod sursă utilizat în procesul de dezvoltare – dependențele tranzitive nu sunt încă nici măcar pe radar. Profunzimea absolută a problemelor de securitate continuă să pândească sub suprafață, crescând raza de explozie a atacurilor de tip typosquatting și de execuție de cod la distanță. Dacă reutilizarea constantă a codului open source trebuie să se ridice la înălțimea potențialului său, securitatea trebuie să devină o prioritate mai mare în cadrul procesului DevOps.

Cum să vă protejați împotriva vulnerabilităților aflate la pândă

Procesul de menținere a unei stive tehnologice securizate nu a fost niciodată mai complex. Având în vedere că alertele de corecție devin rapid copleșitoare, este timpul ca securitatea întreprinderii să acorde prioritate protecției automate, fără patch-uri. Măsurile tradiționale care prioritizează securitatea perimetrului alături de analiza statică și dinamică se bazează pe actualizări manuale, ceea ce înseamnă că nu există protecție împotriva zilelor zero. Codul backdoor pe care atacatorii l-au folosit în cadrul infamului atac SolarWinds nu a fost detectat de nicio analiză statică, deoarece din punct de vedere tehnic nu au existat erori.

Identificarea și blocarea încercărilor de exploatare necesită o suită mică de software de interconectare. Pentru a ajuta mai întâi la definirea și protejarea perimetrului unei aplicații, poate fi implementat un paravan de aplicare web (WAF) de nouă generație. Aflat la granița dintre extern și intern, WAF monitorizează tot traficul care circulă către și de la o aplicație. Aspectul de nouă generație permite acestui WAF să adapteze și să implementeze automat noi politici. Desfășurarea automată a acestei evoluții constante eliberează timp și energie semnificative pentru echipa de securitate pe care un WAF de școală veche le-ar consuma altfel.

În timp ce WAF păstrează controlul asupra oricăror încercări externe de a executa cod, Runtime Application Self Protection (RASP) protejează împotriva deficiențelor interne și a injectărilor de cod. Acest nivel de protecție evaluează toate sarcinile utile (cum ar fi interogările SQL și comenzile sistemului de operare) în timp real. Acest proces nu necesită semnături sau o fază de învățare și are loc în întregime în contextul aplicației. Deoarece aceasta funcționează în cadrul aplicației, acoperă aproape toate contextele. Aceasta înseamnă că, chiar dacă un exploit permite încălcarea perimetrului, un atacator este împiedicat să se deplaseze lateral, deoarece orice comportament suspect al aplicației declanșează o oprire a RASP. Acest lucru pune capăt activității suspecte și alertează echipele de securitate. În acest fel, RASP este complementar unui WAF de nouă generație; în timp ce WAF ajută la menținerea traficului prost, riscul reprezentat de exploatările tranzitive la pândă este atenuat de RASP. Cu aceste componente care protejează o stivă tehnologică, povara pe care OSS o pune în prezent asupra securității este redusă semnificativ.