Ce înseamnă să te auditezi singur · Lecția 1 din 11 · 5 minute
SAST, DAST și SCA: ce face fiecare
Înainte să lansezi o aplicație, poți să o scanezi singur, exact cum ar face-o cineva din afară. Există trei tipuri de scanare automată, iar fiecare se uită în altă parte: SAST citește codul, DAST atacă aplicația pornită, SCA verifică bibliotecile pe care le-ai adăugat. Nu sunt trei variante ale aceluiași lucru, ci trei unghiuri diferite, iar o singură scanare nu le acoperă pe toate trei.
De ce trei tipuri și nu unul singur
O vulnerabilitate poate sta în trei locuri complet diferite. Poate fi în codul pe care l-ai scris sau l-a generat modelul, de exemplu o interogare de bază de date construită prin lipirea unui text venit de la utilizator. Poate fi în felul în care aplicația se comportă când rulează, de exemplu un panou de administrare care răspunde oricui, fără să ceară login. Sau poate fi într-o bibliotecă pe care ai instalat-o cu o singură comandă și în care cineva a găsit între timp o gaură cunoscută. Fiecare tip de scanare acoperă unul dintre aceste locuri, iar dacă folosești doar unul, celelalte două rămân neverificate.
SAST: citește codul, fără să îl ruleze
SAST vine de la Static Application Security Testing, adică testare statică. Unealta se uită la codul sursă așa cum e scris, fără să pornească aplicația, și caută tipare periculoase: o interogare de SQL construită prin concatenare, o valoare afișată în pagină fără curățare, o cheie scrisă direct în cod. Marele avantaj e că prinde problema devreme, chiar în timp ce scrii, înainte ca aplicația să ajungă undeva. Uneltele tipice sunt Semgrep, care e gratuit și cu reguli pe care le poți scrie singur, SonarQube și Checkmarx. Limita lui e că vede doar codul, nu și ce se întâmplă când toate piesele lucrează împreună la runtime.
DAST: atacă aplicația pornită, din exterior
DAST vine de la Dynamic Application Security Testing. Aici unealta nu se uită deloc la cod. Pornește aplicația, o tratează ca pe o cutie neagră și trimite spre ea cereri, exact ca un vizitator sau ca un atacator. Așa prinde lucruri pe care SAST nu are cum să le vadă: o configurare greșită de server, o pagină care ar trebui protejată dar nu e, o sesiune gestionată prost, anteturi de securitate lipsă. Unealta gratuită de referință e OWASP ZAP, iar standardul din industrie e Burp Suite. Există și variante comerciale, precum Acunetix pentru web, sau Nessus, care scanează mai degrabă infrastructura și rețeaua decât aplicația.
SCA: verifică bibliotecile pe care le-ai adus
SCA vine de la Software Composition Analysis. O aplicație modernă e făcută în cea mai mare parte din cod pe care nu l-ai scris tu, ci l-ai adus prin `npm install` sau echivalent. SCA se uită la această listă de dependențe și verifică fiecare pachet față de bazele de date publice de vulnerabilități cunoscute, plus licențele lor. Dacă o bibliotecă pe care o folosești are o gaură descoperită și publicată, SCA îți spune. Uneltele tipice sunt `npm audit`, care e deja în Node, plus Snyk, Trivy și Dependabot. Acest tip de scanare corespunde direct categoriei A03:2025 din OWASP Top 10, lanțul de aprovizionare software.

Nu se înlocuiesc, se completează
De reținut
SAST citește codul sursă fără să îl ruleze și prinde tipare periculoase devreme (Semgrep, SonarQube, Checkmarx).
DAST pornește aplicația și o atacă din exterior, ca o cutie neagră, prinzând probleme de configurare, autentificare și deploy (OWASP ZAP, Burp).
SCA verifică dependențele față de vulnerabilitățile cunoscute și corespunde OWASP A03:2025 (npm audit, Snyk, Trivy, Dependabot).
Cele trei nu se înlocuiesc; un audit complet le rulează pe toate, pentru că fiecare vede altceva.