Analiza de cod static (SCA)este analiza programelor de computer care se efectuează fără a executa programele utilizând frecvent un instrument automatizat. SCA a devenit o parte integrală a ciclului de viață a dezvoltării de software și unul dintre primii pași pentru a detecta și elimina din timp erorile de programare din faza de dezvoltare software. Deși instrumentele SCA sunt folosite în mod obișnuit în dezvoltarea de software patentat pentru a asigura calitatea software-ului, aplicarea unor asemenea instrumente la întinderea vastă de cod opensource reprezintă o provocare intensă, deși interesantă, mai ales atunci când codul opensource se regăsește în software-ul comercial. Chiar dacă au existat eforturi recente în această direcție, în lucrarea de față abordăm această provocare într-o oarecare măsură, prin aplicarea analizei statice pe un proiect opensource cunoscut, de exemplu, nucleul Linux. De asemnea, discutăm rezultatele analizei noastre și pe baza acestora, vom propune un flux de lucru alternativ care poate fi adoptat când software-ul opensource este integrat într-un proces de dezvoltare de software comercial. În continuare, vom prezenta beneficiile și provocările întâmpinate atunci când adoptăm fluxul de lucru alternativ propus.
Deși SCA nu este o tehnologie nouă, recent i s-a acordat multă atenție și este rapid adoptată ca o activitate integrată în ciclul Dezvoltării de software pentru a îmbunătăți calitatea, fiabilitatea și siguranța software-ului. Cele mai multe instituții de dezvoltare software patentat au o echipă dedicată de profesioniști pentru validarea software-ului, a căror responsabilitate include de asemenea rularea anumitor instrumente de analiză statică pe software-ul aflat în dezvoltare, fie într-un mediu agil, fie într-un model waterfall tradițional. Instrumentele SCA sunt capabile să analizeze cod dezvoltat prin utilizarea mai multor limbaje de programare și framework-uri care includ, fără a se limita la Java, .Net și C/ C++. Indiferent dacă scopul este dezvoltarea de software pentru aplicații sau a unui soft integrat (firmware) critic pentru misiune, instrumentele de analiză statică s-au dovedit a fi unul dintre primii pași înspre identificarea și eliminarea erorilor din software și sunt indispensabile pentru succesul general al proiectului software.
Acestea fiind spuse, este clar că există în mod tipic fie interese comerciale și/ sau probleme de securitate implicate în brevetarea și aplicarea exhaustivă a unor instrumente scumpe de analiză statică în efortul de dezvoltare software cu posibilitate inexistentă sau foarte mică de eșec. Ceea ce rămâne apoi drept un spațiu vid expansiv și neexplorat este tărâmul nesfârșit al codului opensource care este de obicei considerat a fi bine reexaminat, întrucât software-ul opensource a fost utilizat și reutilizat în nenumărate aplicații de către numeroase instituții academice și comerciale din toată lumea. "Expansivă indică faptul că adaugă în permanență cod sursă nou și "neexplorat", indică absența unei organizații dedicate, obiective, care să analizeze static fiecare linie de cod opensource. Recent, companiile SCA au avut o inițiativă în această direcție. Dar chiar și așa, rata cu care versiunile mai noi ale software-ului opensource sunt lansate și actualizate reprezintă o barieră în calea unor asemenea eforturi. Deși un astfel de efort ar fi atribuit paranoiei de către mulți, este evident că declinul financiar și micșorarea bugetelor IT au făcut ca software opensource să intre în aplicațiile comerciale, de exemplu Linux, Apache, MySQL sau OpenSSL.
Fluxul de lucru convențional, în care rezultatul instrumentului SCA este inclus în pachetul de verificare software formal este după cum se arată în figura 1. În cele mai multe instituții de dezvoltare și testare software, chiar dacă produsul software luat în întregime este supus analizei dinamice, ca testarea fuzzing sau black box, iar codul software nou dezvoltat este supus analizei statice și unei verificări riguroase, codul opensource încorporat în software nu este supus unei analize statice sau unei verificări asemănătoare codului patentat nou dezvoltat, așa cum este ilustrat în figura 1. De obicei, un binar al software-ului opensource necesar este încorporat în pachetul software complet. Probabil că aceasta se bazează pe presupunerea că software-ul opensource este mai sigur și cu mai puține defecte decât software-ul closed source, deoarece sursa este disponibilă gratuit, mulți oameni vor căuta defecte de securitate și alte erori în software într-un fel care nu se va întâmpla în lumea comercială. În ciuda faptului că această presupunere a trecut testul timpului și probabil nu poate fi dovedită drept greșită, ar fi totuși un exercițiu interesant să aplicăm instrumentele analizei statice la codul opensource și să analizăm rezultatele. Chiar dacă au mai existat anterior eforturi de a analiza static codul opensource utilizând instrumente SCA comerciale sau opensource, în lucrarea de față, încercăm să verificăm dacă anumite probleme ale codului pot fi detectate încă de la început prin SCA. Mai mult, propunem un flux de lucru alternativ care poate fi adoptat când se încorporează cod opensource într-un proces de dezvoltare de software comercial. Vom discuta beneficiile, provocările și posibilele compromisuri ale adoptării fluxului de lucru alternativ propus. Un asemenea efort va prezenta interes și pentru comunitatea de ingineri software și pentru comunitatea opensource în general. De aceea, pentru a experimenta, vom alege Klocwork Insight drept instrument preferat, deoarece este unul dintre liderii industriei în SCA. Vom alege un proiect opensource cunoscut, Linux kernel (nucleul Linux), pentru analiza noastră de cod. Apoi, vom începe să rulăm Klocwork Insight pe codul nucleu Linux și vom discuta rezultatele analizei noastre. În general, Klocwork este un instrument reprezentativ pentru SCA, iar Linux este un proiect opensource reprezentativ pentru analiza noastră, care poate fi extinsă la alte instrumente SCA și alte proiecte opensource.
Restul lucrării este organizat după cum urmează: Secțiunea 2 oferă contextul alegerii codului Linux kernel pentru analiză și SCA utilizând Klocwork Insight. Secțiunea 3 discută rezultatele SCA. În secțiunea 4, vom discuta un flux de lucru alternativ care poate fi urmat când se încorporează software opensource într-un proces de dezvoltare de software comercial și vom discuta beneficiile și provocările întâlnite atunci când urmăm fluxul de lucru alternativ propus. În final, în secțiunea 5, vom trage concluziile, rezumând observațiile importante.
PRELIMINARII
A. Linux kernel (nucleu)
Linux kernel este un nucleu de sistem de operare utilizat de către familia Linux de sisteme de operare asemănătoare cu Unix. Este unul dintre exemplele cele mai evidente de software sursă liberă și deschisă și, deci, o alegere naturală pentru analiza noastră. Linux kernel este lansat sub licența GNU General Public versiunea 2 (GPLv2) și este dezvoltat de contribuitori din întreaga lume. Zilnic au loc discuții despre dezvoltare pe adresele de mail ale Linux kernel. Linux kernel a primit contribuții de la mii de programatori. Multe distribuții Linux au fost lansate pe baza nucleului Linux (8). Am ales pentru analiza noastră, versiunea Linux kernel 2.6.32.9, lansat în februarie 2010.
Unicul avantaj al analizei statice este abilitatea sa de a scana baze întregi de cod pentru a identifica erori logice sau de securitate. Este mult mai cuprinzătoare ca și rază de acțiune decât testarea sistemelor black-box. Totuși, anumite probleme sunt dependente de perioada de rulare și pot fi descoperite numai prin executarea codului, așa că analiza statică nu poate rămâne singură. O curbă reprezentativă efort - beneficiu pentru utilizarea unui instrument SCA este ilustrată în figura 2. Se observă faptul că pe măsură ce se aplică mai multe verificări, proporția de erori detectate crește odată cu creșterea cantității de efort necesar pentru a pune în aplicare aceste verificări. Compilatoarele tipice, precum gcc, încorporează analiza statică într-o oarecare măsură în forma avertismentelor sau a erorilor raportate pe perioada procesului de compilare. Acestea necesită, în general, un efort minim și de asemenea, raportează cel mai mic număr de erori (bugs). În timp ce, pe de altă parte, verificarea formală a software-ului, de exemplu, utilizarea controlului model (model checking), este o abordare mult mai complexă către automatizarea SCA, care necesită o cantitate mai mare de efort, dar este capabilă să detecteze un număr mai mare de erori (bugs) de o complexitate ridicată. Chiar dacă verificarea formală nu este adoptată în mod extensiv în industria de software, din cauza legii diminuării profitului, există câteva sisteme de operare care sunt verificate formal, cum e micronucleul Secure Embeded L4 al NICTA (6).
În analiza noastră, utilizăm instrumentul Klocwork Insight pentru a efectua SCA (analiza statică a codului). Klocwork Insight este un instrument SCA care este folosit pentru a identifica probleme de calitate și securitate pentru C, C++, Java și C#. Produsul include numeroase desktop plug-ins pentru dezvoltatori, un instrument de analiză arhitectură, metrici și raportare. Este suportat pe platformele bazate pe MS Windows și Linux OS (3). În general, cele mai multe verificări cu instrumente SCA includ în mod tipic declarații neutilizate, contradicții / incompatibilități de dactilografiere, utilizare înaintea definiției, cod inaccesibil, valori raportate ignorate, căi de execuție fără întoarcere, bucle infinite asemănătoare și cazuri fall through. Verificarea poate fi configurată și de asemenea poate fi personalizată pentru a selecta ce clase de erori sunt raportate. În plus, verificări la comandă pot fi create de către utilizator pentru a găsi condiții specifice într-o anume bază de cod. De obicei, fișierul de configurare a regulilor de utilizare a instrumentului SCA poate fi editat pentru a captura probleme specifice în codul sursă. De exemplu, fișierul de configurare reguli de utilizare Klocwork poate fi actualizat cu reguli de verificare pentru a semnala utilizarea unor API-uri interzise de pe lista de API-uri interzise (banned.h) a Microsoft Security Development Lifecycle (SDL). Această libertate de a edita fișierul de configurare asigură integrarea unor verificări mai eficiente sau mai specifice proiectului în rezultatele SCA. Pe măsură ce se depune mai mult efort pentru ajustarea instrumentului SCA la codebase și native compiler, rezultatele verificării sunt mai bune. În general, cele mai multe instrumente SCA sunt concepute să fie flexibile și să permită programatorilor sau celor care analizează calitatea să selecteze puncte adecvate pe curba efort-beneficiu pentru proiecte specifice. Pe măsură ce sunt porniți diverși verificatori, numărul erorilor care pot fi detectate crește dramatic; aceasta poate avea drept rezultat și alarme false. Alarmele false (false positives) pot fi reduse prin editarea regulilor de verificare din fișierele de configurare, activând verificatorii ceruți și dezactivându-i pe cei care nu sunt necesari proiectului. Instrumentele SCA pot fi făcute să înțeleagă mai bine semantica unei funcții sau metode date dacă sunt configurate să înțeleagă cuvintele cheie speciale care pot fi utilizate de către native compiler și prin adăugarea mai multor informații în baza de cunoștințe a instrumentului. Astfel, utilizatorii pot defini noi reguli și verificări asociate pentru a extinde verificarea instrumentului SCA sau pentru a aplica proprietăți specifice aplicației. În general, procesul de construcție automatizat care încorporează SCA poate fi divizat în două etape. Prima etapă implică generarea unui fișier de "specificații de construcție" (build specification), care este generat drept parte a procesului de compilare și stabilire de legătură. A doua etapă implică rularea instrumentului de analiză statică pe rezultatul link-ului (link output), adică fișierul build specification pentru a genera rapoarte de analiză statică. Klocwork prezintă rezultatele analizei statice via browser window, de exemplu Internet Explorer, Mozilla Firefox, a căror interfață utilizator poate fi personalizată într-o oarecare măsură.
de Cristian Pup
de Alin Luncan
de Corina Pip
