Français: această pagină nu e încă tradusă. Textul de mai jos e în Română.
Costul de a repara un defect de securitate crește cu fiecare fază: banal într-o ședință de design, scump într-un sprint, dureros după lansare, potențial dezastruos în producție. Cu toate astea, în majoritatea proiectelor securitatea apare la final, ca un test de care „trebuie să treacă”. O mutăm la începutul și în tot parcursul proiectului — „shift-left” — cu puncte de control clare, ca un sistem nou să nu devină incidentul de anul viitor.
Cum lucrăm
Integrăm securitatea în ciclul de dezvoltare (secure SDLC), pe modele recunoscute — OWASP SAMM și ASVS, NIST SSDF:
- Cerințe — cerințe de securitate și de confidențialitate (inclusiv protecția datelor prin design), cazuri de abuz, obligații de conformitate; OWASP ASVS ca țintă măsurabilă, nu ca vagă „aplicație sigură”
- Design — revizuire de arhitectură și modelare de amenințări, ca poartă formală înainte de build
- Dezvoltare — standarde de cod sigur (OWASP Top 10), plus scanare integrată în pipeline: SAST, dependențe (SCA), secrete, IaC
- Testare — DAST, cazuri de test de securitate și testare de penetrare înainte de lansare
- Lansare și operare — întărire, scanare IaC, patch-uri, monitorizare
Ce primești
- Specificația cerințelor de securitate și un criteriu de acceptare pe proiect
- Modelul de amenințare și aprobarea de la revizuirea de design
- Ghiduri de cod sigur și configurarea porților de securitate în CI/CD
- Rezultatele testelor (SAST/DAST/SCA/pentest), cu remediere urmărită
- O evaluare de tip „go / no-go” de securitate pentru lansare