Neglijarea dezvoltatorilor open source pune internetul în pericol

Software-ul se află în centrul tuturor afacerilor moderne și este crucial în fiecare aspect al operațiunilor. Aproape fiecare afacere va folosi software cu sursă deschisă, cu bună știință sau altfel, deoarece chiar și software-ul proprietar depinde de bibliotecile cu sursă deschisă. OpenUK Raportul „State of Open” din 2022 a constatat că 89% dintre companii se bazau pe software open source, dar nu toate sunt clare cu privire la detaliile software-ului pe care se bazează.

Companiile cer din ce în ce mai multe informații despre software-ul lor critic pentru operațiuni. Companiile responsabile se interesează în detaliu pentru lanțul lor de aprovizionare cu software și creează o listă de materiale software (SBOM) pentru fiecare aplicație. Acest nivel de informații este esențial, astfel încât atunci când sunt identificate defecte de securitate în software-ul lor, aceștia pot fi imediat siguri ce software și versiunile sunt utilizate și ce sisteme sunt afectate. Cunoașterea este putere în aceste situații!

Baza pe voluntari

La sfârșitul anului 2021, o vulnerabilitate de securitate a sunat Log4shell. a fost identificat într-un cadru de logare Java utilizat pe scară largă, Log4j. Deoarece aceasta este o bibliotecă cu sursă deschisă folosită pe scară largă, vulnerabilitatea a fost bine mediatizată și se așteptau remedieri. Însă menţinătorii proiectului au fost voluntari. Aveau locuri de muncă de zi și nu erau de așteptare pentru remedieri urgente de securitate, chiar dacă un număr mare de sisteme au fost afectate. S-a estimat că numai această vulnerabilitate a afectat 93% din mediile cloud ale întreprinderilor.

La acea vreme, exista o presă negativă despre open source, dar adevărul este că, dacă aceasta era o componentă cu sursă închisă, vulnerabilitatea nu ar fi fost niciodată cunoscută public, lăsând organizațiile deschise atacului. Natura open source a bibliotecii a însemnat că poate fi inspectată, problemele găsite și sfaturi oferite de alții. Deci, da, întreținerii nu au fost de așteptare pentru probleme de securitate în proiectul lor de voluntariat. Marea întrebare, atunci, este: Cum am ajuns într-o situație în care companiile majore depind de software care era responsabilitatea cuiva care face altceva pentru a-și plăti facturile?

Neglijarea dependențelor de software este o afacere riscantă, indiferent de licența software-ului, dar atunci când este open source și foarte utilizat pe scară largă, devine deosebit de periculoasă. Rămâi cu povestea unei vulnerabilități; problema exista în baza de cod de ani de zile, dar nu a fost depistată. Instrumentul care a fost atât de utilizat pe scară largă nu a fost, de fapt, atât de susținut – și ceea ce a urmat este istorie.

Această poveste se repetă de nenumărate ori, în atât de multe companii care au dependențe critice, dar care nu iau măsuri pentru a sprijini nici menținătorii, nici proiectele în sine. Având un SBOM pentru software-ul utilizat de o afacere înseamnă că au informațiile la îndemână. Pentru organizațiile care furnizează software altora, așteptarea de a furniza SBOM alături de cod este din ce în ce mai normală.

Cunoașteți dependențele pentru a evalua riscul

Aducerea cunoștințelor despre dependențe facilitează evaluarea riscului asociat fiecăreia. Aceste proiecte cu sursă deschisă sunt cele mai simple de evaluat: se răspunde la probleme și au existat lansări recent? Posibilitatea de a vedea întreținerii și activitatea proiectului pentru fiecare proiect oferă o bună perspectivă asupra stării de sănătate a proiectului.

Afacerile își pot juca rolul pentru a reduce riscurile susținând proiectele de care depind. Unele proiecte acceptă sponsorizarea direct prin schema GitHub Sponsors, altele ar putea aprecia în schimb oferte de găzduire sau un audit de securitate. Fiecare proiect open source apreciază contribuțiile. Dacă afacerea dvs. ar fi creat singură această bibliotecă, atunci inginerii din cadrul companiei ar trebui să remedieze ei înșiși fiecare eroare.

Open Source seamănă mai mult cu o schemă de proprietate partajată. Nu toți trebuie să construim același lucru în mod repetat, ci mai degrabă putem contribui, ceea ce înseamnă mai puțin efort și duce la o calitate mai bună ca rezultat. Unul dintre cele mai de impact pe care le pot face companiile este să folosească puțin din resursele lor de inginerie și contribuie la remedierea erorilor sau la caracteristicile proiectelor care sunt atât de esențiale pentru afacere.

Menținerea propriilor ingineri implicați într-un proiect are multe beneficii. Ei ajung să-l cunoască și pot urmări noile funcții sau când este disponibilă o nouă versiune. În mod crucial, afacerea are o perspectivă asupra stării de sănătate și a stării proiectului dependent și face parte din ceea ce îl menține sănătos, reducând riscul pentru afacere a unei probleme cu o dependență. O serie de organizații, inclusiv Aiven, au un OSPO (open source program office), cu personal dedicat contribuției sau chiar menținerii proiectelor utilizate de organizație. Aceste departamente contribuie adesea la prezența generală a companiei în ecosistemul open source și permit altor angajați să se implice cu open source.

O altă abordare este de a sprijini organizațiile care există pentru a sprijini open source. The OpenSSF (Open Source Security Foundation) lucrează pentru a îmbunătăți securitatea proiectelor open source și este finanțat de organizațiile care depind de acele proiecte. De asemenea, publică resurse excelente de învățare, astfel încât companiile să se poată educa despre riscurile software-ului pe care îl folosesc. O altă organizație similară este Tidelift, care colaborează cu întreținerii pentru a se asigura că sunt îndeplinite anumite cerințe de bază, din nou finanțate de organizații. Tidelift oferă, de asemenea, instrumente și educație pentru a ajuta companiile să-și gestioneze lanțul de aprovizionare cu software și să adopte cele mai bune practici în acest domeniu.

Asigurarea unui viitor software mai sigur

Companiile depind de software, iar acesta include software-ul open source, care este utilizat pe scară largă și de obicei mai sigur decât alternativele proprietare.

Aceasta este o mișcare inteligentă, dar o mișcare și mai inteligentă este să aveți cunoștințe clare despre lanțul de aprovizionare cu software și dependențele acestuia. Atunci când apare o problemă, în funcție de proiecte sănătoase și a avea la dispoziție detaliile software-ului dvs. ajută fiecare organizație. Dacă fiecare organizație a făcut acest lucru, atunci riscul de a avea evenimente precum vulnerabilitatea Log4Shell este redus.