A fost o vreme când în echipele de programatori exista rolul de "build meister", persoana responsabilă cu transformarea codului sursă în cod mașină. Acel rol a dispărut în mare măsură odată cu popularizarea noțiunii de devops și automatizarea procesului de build.
În echipele ce folosesc metode și instrumente moderne de programare, fiecare programator e așteptat să contribuie la implementarea și menținerea pipeline-urilor de CI/CD. Aceasta nu înseamnă că fiecare programator trebuie să fie expert în Github Actions/Circle CI/Argo CD etc. sau să aibă cunoștințe de cum se administrează acele aplicații. Ce se așteptă e ca fiecare programator să devină responsabil și direct implicat în întregul "Software Development Lifecycle (SDLC)".
În mod similar, securitatea e văzută ca o «problemă» a echipei de testare sau a celei de IT/infrastructură. Echipa de dezvoltare livrează funcționalitatea, echipa de test identifică problemele inclusiv problemele de securitate care ulterior vor fi triate și testate ca orice alt defect.
Acest mod de abordare nu mai e posibil în ziua de azi, când aplicațiile sunt expuse unui mediu ostil (Internetul) din primul moment.
E mult prea târziu ca securitatea să fie abordată doar în faza de testare. O problemă găsită în această fază poate solicita rescrierea unui mare volum de cod. Aceasta duce la creșterea semnificativă a costurilor de dezvoltare și va întârzia proiectul.
De asemenea, soluțiile aplicate retroactiv sunt adesea ineficiente, incomplete sau limitează funcționalitatea aplicației.
O infrastructură securizată nu poate remedia vulnerabilitățile aplicației. Viceversa însă, o aplicație vulnerabilă devine un risc pentru întreaga infrastructură.
Securitatea e o problema a echipei securitate?
Nu toate companiile au echipe de securitate dedicate. Dar chiar și atunci când aceste echipe există, e imposibil pentru o singură echipă să înțeleagă în detaliu particularitățile tuturor aplicațiilor.
Soluția ce s-a impus în ultimii ani a fost schimbarea paradigmei în industria software. Similar cu modul în care testarea, compilarea și instalarea aplicațiilor s-au mutat înspre echipa de dezvoltare, aspectele legate de securitate s-au "mutat de asemenea la stânga" în procesul de dezvoltare.
Termenii folosiți variază, însă descriu aceeași idee: securitatea trebuie abordată devreme și trebuie să fie prezentă în fiecare etapă a ciclului de dezvoltare. Pe cale de consecință, programatorii ajung să preia o parte din responsabilitățile asociate în mod tradițional cu alte roluri.
Fiecare etapă din ciclul de dezvoltare e potrivită pentru o anume activitate ce vizează securitatea aplicației. Un singur aspect se justifică la nivelul fiecărei etape și activități: educarea întregii echipe, indiferent de rol, în probleme și tehnici de securitate.
Din punctul meu de vedere, aceasta e una din cele mai importante activități, dacă nu cea mai importantă. Rolul acestei activități e de a determina care sunt punctele vulnerabile ale aplicației precum și soluțiile ce pot fi folosite.
Una din întrebările folosite pentru a prioritiza problemele identificate este: care e cel mai rău lucru care se poate întâmpla dacă riscul X se materializează?
Exemple de aspecte ce sunt luate în considerare:
ce fel de date manipulăm și cum le protejăm?
cum gestionăm accesul în aplicație?
Există diverse metodologii de Threat Modelling precum STRIDE (Microsoft), DREAD, Vast. De asemenea există aplicații ce le implementează precum OWASP Threat Dragon, IriusRisk, Threagile etc.
Un proces de Threat Modelling formalizat (metodologie + aplicație) va aduce cele mai bune rezultate. Dar simpla considerare a aspectelor de securitate în procesul de design reprezintă un pas imens.
În faza de implementare există o serie de aspecte ce pot și trebuie să fie verificate. Obiectivul trebuie să fie rularea acestor teste automat în pipeline-urile de CI/CD. La fel de important e ca problemele identificate să fie automat convertite în acțiuni. Acțiunile rezultate pot fi crearea de tichete în JIRA, oprirea unui build, marcarea unui "pull request" ca eșuat etc.
| Test | Descriere |
|---|---|
| Static Application Security Testing | Verificare statică a codului pentru |
| (SAST) | identificarea unor "rele practici" ce |
| pot introduce vulnerabilități. Exemple: | |
| "buffer overflows", SQL Injection, | |
| deserializare nesigură de JSON/XML etc. | |
| Aplicații: Snyk, Fortify, AppScan | |
| Static, Semgrep, Sonar Qube. | |
| Dependency Vulnerabilities | Analizează modulele "open source" |
| folosite pentru a detecta | |
| vulnerabilități cunoscute pentru | |
| acestea. Exemple: log4j vulnerability | |
| Unele aplicații scanează și licența | |
| folosită pentru a evita/detecta | |
| utilizarea de licențe restrictive (GPL). | |
| Aplicații: Snyk, Node Security | |
| Project. | |
| Container Image Scanning | Analizează fișierele Docker. Exemple: |
| imagini de bază cu vulnerabilități | |
| cunoscute, lipsa specificării explicite | |
| a userului cu care containerul rulează | |
| etc. Aplicații: Snyk (also integrated | |
| Docker-Hub), Docker Bench, AWS ECR. | |
| Infrastructure as Code Testing | Analizează elementele de infrastructură |
| exprimate în cod, precum Kubernetes | |
| deployments/services yaml. Exemple: | |
| execuția cu cont de administrator, lipsa | |
| limitărilor de memorie, sistem de | |
| fișiere ce nu e read-only etc. | |
| Aplicații: Snyk. | |
| Dynamic Application Testing (DAST) | Scanează aplicațille ce au o interfață |
| web. Exemple: lipsa unor headere, | |
| XRSS, SQL Injection, path traversal | |
| sau probleme aparent benigne precum | |
| informații despre infrastructură expuse | |
| în răspuns etc. Aplicații: Zap, Blurp | |
| Suite, HCL App Scan. | |
| Interactive Application Testing (IAST) | O specializare a DAST în care un agent |
| rulează în spațiul de memorie al | |
| aplicației ceea ce permite identificarea | |
| codului ce e responsabil pentru o | |
| anumită problemă (ex: lipsa anumitor | |
| headere). |
O mențiune specială merită făcută detectării pierderii/furtului de secrete: parole, chei API, tokens etc. Detectarea timpurie a unui secret inclus accidental în codul sursă permite invalidarea rapidă a acestora, evitând astfel incidente de securitate costisitoare. Github oferă această opțiune dar sunt și alte aplicații ce permit același lucru, unele chiar înainte de a "comite" codul.
Nu trebuie nicidecum înțeles că "shift left security" mută cu totul responsabilitatea pe umerii echipei de dezvoltare. Echipele de IT și cele de operations continuă să joace un rol esențial în asigurarea securității aplicațiilor software.
Aceste echipe sunt responsabile printre altele de întreținerea, monitorizarea și exploatarea infrastructurii și a aplicațiilor. Exemple de aplicații utilizate de aceste echipe:
System Information and Event Management (SIEM): DataDog, Panther, SolarWinds;
Cloud Security Posture Monitoring (CSPM): Orca, DataDog, ZScaler, CrowdStrike Falcon;
Nu trebuie ignorată importanța separării rolurilor, aspect ce contribuie semnificativ la postura globală de securitate.
DevOps e un termen deja supraîncărcat, greșit utilizat sau de-a dreptul prost înțeles. ShiftLeft / DevSecOps nu trebuie să contribuie la această confuzie. În nici un caz nu înseamnă înlocuirea echipei de IT/operații sau a celei de securitate.
Ceea ce Shift Left urmărește este obținerea unei posturi de securitate îmbunătățită prin Detectarea problemelor de securitate în primele etape ale SLDC, acolo unde sunt cel mai ușor și eficient de rezolvat.
Deși pare contraintuitiv, integrând securitatea în SDLC putem evita irosirea de timp, resurse umane și financiare reparând problemele generate de un incident de securitate. Timpul și resursele economisite astfel pot fi folosite pentru a crea noi funcționalități.
de Ovidiu Mățan
de Ovidiu Mățan
