Securitatea codului generat de AI în România

Ce verificăm de la commit până la server

Lanțul are patru puncte de control. În cod: SAST pe reguli Semgrep, cu atenție la validarea intrărilor, la interogări construite prin concatenare și la autorizarea lipsă pe rute. În dependențe: SBOM generat la fiecare build și comparat cu bazele de vulnerabilități. În imagini: scanare de straturi, utilizator non-root, semnătură cu cosign. În infrastructura ca cod: reguli checkov pentru stocare publică, porturi deschise și drepturi prea largi. Peste tot, scanare de secrete, inclusiv în istoricul repository-ului.

• SAST pe fiecare pull request, cu reguli adaptate proiectului
• gitleaks pe commit și pe istoric, cu rotirea cheilor găsite
• SBOM cu Syft, verificat cu Grype la fiecare build
• Imagini semnate cu cosign și verificate la deploy
• checkov pe Terraform, Ansible și manifeste Kubernetes

Ce greșește codul scris cu asistenți AI

Modelele produc cod care compilează și pare corect, dar repetă tipare nesigure din datele pe care au învățat: concatenare în interogări, validare absentă, criptografie aleasă prost, secrete puse direct în fișier, dependențe inventate care apoi sunt înregistrate de altcineva cu același nume. Problema reală e viteza: se scrie mai mult cod pe unitate de timp, deci mai multă suprafață. Aceleași modele ajută însă la apărare: triaj al rezultatelor SAST, explicarea unei constatări în contextul funcției, propunerea de corectură. Verificarea rămâne deterministă, iar decizia de merge la un om.

Gate-uri în CI/CD și viteza echipei

Un gate care blochează totul e dezactivat în două săptămâni. Îl calibrăm: eșec doar pe severitate mare și pe secrete, avertisment pe restul, plus o listă de excepții cu termen și proprietar. Rulăm scanările în paralel cu testele, ca timpul de build să nu crească simțitor, și păstrăm în cache bazele de vulnerabilități. Pe pull request comentăm doar ce e nou față de ramura de bază, ca dezvoltatorul să vadă ce a introdus el, nu datoria istorică a proiectului.

Unde rulează pipeline-ul și ce ținem noi

Configurăm pipeline-ul pe GitHub Actions, GitLab CI sau pe un runner propriu, pe VPS-ul tău din Frankfurt, dacă vrei ca sursele să nu iasă din infrastructura ta. Lucrarea se cere din panoul de client, la „Servicii DevOps”. Din orele lunare (una la cPanel de la Advanced, una până la opt la VPS, zece la dedicate și GPU) ținem regulile actualizate, revizuim excepțiile expirate și adăugăm verificări la proiectele noi. Un refactor mare al pipeline-ului depășește cota și se facturează separat, la oră.

Cum lucrăm

1. Cererea din panou

   Ceri securizarea pipeline-ului din „Servicii DevOps”, ne spui unde stă codul, cum faci deploy și ce praguri poți accepta la început.

2. Evaluarea repository-ului

   Rulăm o primă trecere: SAST, secrete în istoric, dependențe, imagini, IaC. Îți arătăm ce ar bloca un gate pus astăzi și ce se repară rapid.

3. Implementarea gate-urilor

   Adăugăm pașii în CI, calibrăm severitățile, rotim cheile expuse și semnăm imaginile. Trecem gradual de la avertisment la blocare.

4. Predare și întreținere

   Predăm configurația, lista de excepții cu termene și documentația. Revizuim regulile periodic, din orele incluse în abonament.

Cazuri de utilizare

Tehnologii

• Semgrep
• gitleaks
• Syft
• Grype
• Trivy
• checkov
• cosign
• Dependency-Track
• pre-commit

Întrebări frecvente

• Este sigur codul generat de AI?

  Nu implicit. Compilează și arată bine, dar repetă tipare nesigure: validare lipsă, interogări construite prin concatenare, secrete în fișiere, dependențe care nu există. Tratează-l ca pe cod scris de un coleg nou: util și rapid, dar trecut prin aceleași verificări automate și prin recenzie umană.

• Ce este vibe coding și ce riscuri are?

  Termenul folosit pentru scrierea de aplicații prin conversație cu un model, fără să citești atent ce iese. Riscul nu e sintaxa, ci ce nu se vede: autorizare absentă, date expuse, dependențe necunoscute. Un gate în CI îl transformă din pariu în proces repetabil.

• Ce este un SBOM?

  Lista completă a componentelor din care e făcut software-ul tău: biblioteci, versiuni, licențe. O generăm la fiecare build cu Syft și o verificăm cu Grype, ca la apariția unui CVE nou să știi în câteva minute dacă te afectează și în ce versiune livrată.

• SAST sau DAST: care când?

  SAST citește codul și prinde clase de erori înainte de deploy, pe fiecare pull request. DAST atacă aplicația pornită și prinde ce apare doar la rulare: configurare, sesiuni, integrări. Le folosim împreună, SAST în CI și DAST pe mediul de test înainte de lansare.

• Cum evit să ajungă chei API în repository?

  Cu scanare la commit prin pre-commit și gitleaks, plus o trecere pe tot istoricul, pentru că un secret vechi rămâne valabil. Cheile găsite se rotesc, nu doar se șterg din cod. Secretele stau în variabile de mediu, în SOPS sau într-un seif, nu în fișiere versionate.

• Cum verific dependențele proiectului?

  La fiecare build: SBOM, comparație cu bazele de vulnerabilități și prioritizare pe expunere reală. Adăugăm verificarea numelor, ca să nu instalezi un pachet inventat de un model și înregistrat de altcineva, și blocăm actualizările automate netestate în producție.