Securizarea Codului Opensource (III)

În numerele anterioare 24 și 25, s-au publicat primele două părți ale acestui articol. Acest număr prezintă ultima parte a acestuia. După cum am menționat în părțile anterioare ( vezi Figura 1), codul opensource încorporat în software-ul comercial nu este de obicei supus la aceeași analiză statică riguroasă și revizuire ca și codul patentat nou dezvoltat.

În fluxul alternativ de lucru pe care îl propunem, după cum vom vedea în Figura 9, noi recomandăm includerea rezultatului instrumentului SCA atât pentru software-ul nou dezvoltat cât și pentru software-ul opensource adoptat în pachetul de revizuire formală software. Acest flux de lucru va supune codul opensource unei analize de cod și unui proces de revizuire detaliat împreună cu codul patentat nou dezvoltat. Orice eroare (bug) descoperită prin analiza statică este reparată și în codul opensource și în codul nou dezvoltat, înainte ca acesta să fie supus analizei dinamice și cu mult înainte să fie lansat pe piață. Bineînțeles, acceptarea termenilor licenței codului opensource adoptat este la fel de importantă și poate pretinde comunicarea reparațiilor sau modificării codului către responsabilii cu întreținerea, înainte ca software-ul să fie expediat. Acest proces s-ar putea să nu găsească toate erorile , dar cu siguranță va ajuta la descoperirea timpurie a anumitor erori, oferind astfel șansa de a le îndrepta mai devreme, după cum s-a demonstrat în secțiunea anterioară despre analiza vulnerabilității. Mai mult, considerați scenariul realizării unui upgrade al componentelor open source care au fost încorporate. Adoptarea fluxului de lucru propus va fi și mai utilă într-un astfel de scenariu:

• Pentru a te ajuta să decizi dacă un upgrade al unui component este fezabil, prin bilanțul erorilor care sunt îndreptate și erorilor nou introduse. Uneori, efortul suplimentar necesar îndreptării erorilor nou introduse în versiunea de software upgradat poate fi un factor decisiv pentru lansarea produsului.
• Pentru estimarea muncii potențiale de portare prin înțelegerea relației dintre componentele open source și componentele proprii.

Provocări în adoptarea fluxului de lucru propus

Chiar dacă analiza statică a codului opensource adoptat este folositoare în identificarea timpurie a anumitor erori (bugs) în software, există provocări tehnice și orientate pe proiect care ar putea să facă această propunere să nu fie viabilă în anumite situații, după cum vom discuta în continuare.

• Instrumentele SCA tind să producă un număr mare de alarme false (false positives). Revizuirea și eliminarea alarmelor false poate fi o sarcină descurajatoare pentru ambele echipe, de dezvoltare și de asigurare a calității, în special atunci când proiectele sunt supuse unor constrângeri serioase legate de resurse, timp și buget. Odată ce alarmele false sunt eliminate, este necesară comunicarea problemelor reale către echipele de dezvoltare, spre a fi corectate. Uneori, aceasta poate necesita ca îndreptările să fie comunicate echipei de mentenanță a software-ului opensource, înainte de livrarea produsului, în baza termenilor licenței pentru software-ul opensource.
• Evaluarea gravității pentru problemele semnalate de Klocwork sunt ilustrate în Figura 10. Klocwork suportă 10 nivele de gravitate, cu 1 (Critic) fiind cel mai ridicat și 10 (Info) fiind cel mai scăzut. În mod similar, alte instrumente SCA vor avea propria lor clasificare a problemelor. Datorită numărului mare de alarme false, tendința de a ignora problemele semnalate drept non-critice de către instrumentele SCA poate face ca probleme reale să fie ignorate. De aceea, revizuirea sârguincioasă a problemelor înainte de a le ignora, chiar dacă este o sarcină descurajatoare, poate de fapt să merite efortul.
• Efectuarea cu conștiinciozitate a SCA și revizuirea rezultatelor SCA pentru întregul cod, opensource sau nou dezvoltat, necesită devotament și resurse pregătite dedicate, care pot să nu fie disponibile în proiecte care duc deja lipsă de personal sau unde volumul de lucru este prea mare și sunt necesare ore suplimentare.

Chiar dacă este recomandată SCA pentru codul opensource adoptat, cât și pentru codul nou dezvoltat, provocările menționate anterior necesită compromisuri datorate limitărilor de buget, timp și resurse, care pot părea necesare, dar sunt probabil riscante. Câteva moduri de abordare a compromisurilor sunt următoarele:

• Un mod ar fi să te concentrezi pe componentele de complexitate mai mare din codul opensource adoptat și să revizuiești rezultatele SCA pentru aceste componente de complexitate ridicată, ceea ce poate economisi timp și resurse prin îngustarea ariei de verificat. Aceasta se bazează pe analiza noastră, după cum am explicat în secțiunea anterioară, despre analiza complexității - componentele de complexitate mai mare tind să prezinte o incidență crescută de erori raportate. Cu toate acestea, aplicarea analizei statice unui cod complex are un efect secundar interesant, și anume, acela că va fi mai dificil să distingem alarmele false pozitive. Acest lucru este necesar deoarece omul trebuie să înțeleagă acum acest cod complex pentru a determina clasificarea avertismentului.
• Un alt mod ar fi să identifici componentele critice ale proiectului, de exemplu networking, și să îți concentrezi eforturile SCA pe aceste componente critice, după cum s-a demonstrat în secțiunea anterioară despre analiza vulnerabilității.
• În privința alarmelor false, investigarea naturii alarmelor false s-ar putea să merite efortul. Alarmele
  false se pot clasifica în alarme false veritabile și alarme false perceptive. Primele sunt exemplificări ale faptului că instrumentul a dat greș pur și simplu, sau că trebuie să fie acordat sau că verificatorul trebuie să fie oprit pentru această anumită bază de date. Cealaltă categorie de alarme false (perceptive) este mai mult o problemă ce ține de educația și/sau de prioritizarea dezvoltatorului. Adesea, în special în cazul vulnerabilităților de securitate sau a defectelor de fiabilitate mai subtile, instrumentul are dreptate, dar fie dezvoltatorul nu înțelege de ce este o problemă, fie nu este atât de interesat de acea problemă particulară. Este de datoria vânzătorului de instrument să se asigure că acesta explică în mod clar rapoartele erorilor, dar cealaltă parte a ecuației este un proces sensibil de creștere în interiorul organizației, pentru mai mulți dezvoltatori seniori și/sau educație și training.

Concluzii

Software-ul opensource, Linux de exemplu, este disponibil pentru oricine dorește să îl obțină și să îl utilizeze în produsele sau proiectele sale, atâta timp cât aderă la termenii din licența software-ului opensource. În analiza noastră, am ales Klocwork drept instrument SCA și Linux Kernel drept bază de cod, doar ca și exemple sau instrumente sau proiecte reprezentative, pentru a evidenția problema securizării codului opensource încorporat în software comercial. În general, analiza noastră poate fi extinsă la alte instrumente SCA și alte proiecte opensource. Chiar dacă proiectele opensource definesc canale adecvate de raportare a defectelor de securitate și non-securitate, aceste erori (bugs) sunt raportate de către dezvoltatori individuali pe măsură ce le descoperă, într-o manieră ad-hoc. Orice efort obiectiv dedicat de a analiza static baza de cod opensource, de a documenta și raporta descoperirile, este absentă din comunitatea opensource, chiar dacă, recent companii SCA precum Klocwork sau Coverity (10) au luat inițiativă în această direcție. Dar chiar și așa, viteza cu care versiunile mai noi ale software-ului opensource sunt lansate sau actualizate reprezintă o barieră în calea unor asemenea eforturi. Eforturi precum programele (11) Agenției de Securitate Națională (NSA), Centrului pentru Software Asigurat (CAS), care prezintă un studiu al instrumentelor de analiză statică pentru C/C++ și Java în anul 2010 utilizând teste disponibile drept Juliet Test Suites (14), constituie un pas în direcția corectă, dar chiar și așa, nu există parametri absoluți pentru alegerea unui anumit instrument SCA. Comercianți SCA concurenți tind să găsească probleme destul de diferite într-o bază de cod comună, iar suprapunerea devine aproape neglijabilă prin includerea în comparație a numai trei instrumente diferite. Drept regulă, nu toate problemele identificate prin instrumentele de analiză statică sunt implicit erori (bugs). Un anumit procent din probleme cel mai probabil poate fi ignorat în siguranță după o revizuire adecvată. Totuși, din totalitatea problemelor găsite, o proporție substanțială garantează într-adevăr corectitudinea. Chiar dacă se impune o investigare detaliată suplimentară pentru a stabili exploatabilitatea acestor defecte în perioada de rulare, de exemplu prin fuzzing (4) sau prin Testarea Aleatorie Automatizată Direcționată (DART) (19), analiza noastră demonstrează fără nicio îndoială că aplicarea analizei statice pe codul opensource are avantajul de a descoperi anumite defecte critice din timp, spre deosebire de a aștepta comunitatea opensource să găsească și să raporteze aceste erori, dacă și când vin în contact cu aceste probleme. Identificarea timpurie a acestor erori (bugs) are avantajul de a le corecta mult mai rapid și eficient.

Comercianților de software care încorporează cod opensource bazat pe GPL în software-ul lor patentat, li se poate cere să facă întregul proiect opensource, inclusiv codul lor patentat. Aceasta este în contrast cu încorporarea licenței Apache sau a codului opensource bazat pe termenii MPL în software-ul patentat, care nu obligă comerciantul de software să facă întregul proiect opensource. Acest lucru poate duce la o situație în care o parte din software este opensource, iar restul este patentat. Orice defect (bug) exploatabil găsit în partea opensource a acestui software poate fi virulent și produsul software poate fi ușor exploatat fără nici un efort depus pentru inginerie inversă. În consecință, securizarea codului opensource care este încorporat software-ului comercial este la fel de critică ca și securizarea software-ului patentat în sine. De aceea, odată cu validarea atentă a software-ului patentat nou dezvoltat prin intermediul SCA, este de asemenea foarte recomandabil să se includă analiza statică a oricărui cod opensource necesar produsului, în procesul de validare software general și să se realizeze o revizuire formală a codului opensource necesar, înainte de adoptarea sa. Poate fi făcută o analogie cu abordarea build (construire). Atunci când folosește o bibliotecă opensource, dezvoltatorul ar descărca un binar și l-ar include direct în build, sau ar descărca sursa și ar integra-o în milestone-ul proiectului? Prin faptul că nu utilizează binarul în mod direct și prin descărcarea sursei și încorporarea acesteia în milestone-urile proiectului, proiectul este protejat de problemele ce pot să apară environment-ul de creare a build-ului. Dacă este așa, de ce să nu includem același cod opensource când realizăm analiza statică, împreună cu codul nou dezvoltat?  Se știe bine în industria de software: cu cât descoperim mai repede un bug, cu atât mai ieftin este să îl repari, evitând astfel procesele de judecată costisitoare sau daunele iremediabile aduse reputației companiei. În multe feluri, acest efort suplimentar este critic pentru îmbunătățirea calității generale, a fiabilității și siguranței  produsului software. În cele din urmă, organizațiile care își pot permite costul și care au nevoie, vor descoperi valoarea acestui efort.  

Mulțumiri

Autorul dorește să îi mulțumească lui Wayne Trantow și echipei Opensource PDT de la Intel pentru furnizarea unor perspective valoroase pe parcursul scrierii acestei lucrări.