De ce pipeline-urile CI/CD au devenit ținta preferată a atacatorilor
Breșa SolarWinds nu a început cu un e-mail de phishing sau un bucket S3 configurat greșit. A început în interiorul unui pipeline de build. Atacatorii au injectat cod malițios direct în procesul de construire a software-ului — și acesta a ajuns la peste 18.000 de clienți fără ca vreun sistem de alertă să reacționeze. Era 2020. Până în 2026, atacurile asupra lanțului de aprovizionare care vizează infrastructura CI/CD s-au întreit ca frecvență, conform raportului CISA din 2026 privind amenințările la adresa lanțului de aprovizionare software.
Adevărul incomod: majoritatea echipelor de inginerie au investit masiv în securitatea aplicațiilor — scanări SAST, teste DAST, audituri de dependențe — dar au lăsat pipeline-ul care rulează toate aceste verificări aproape complet neprotejat. Dacă un atacator compromite sistemul CI/CD, nu trebuie să ocolească controalele. Le dezactivează pur și simplu, sau, mai rău, le face să pară că trec.
Acest ghid acoperă ce înseamnă cu adevărat securitatea CI/CD în practică, care riscuri OWASP contează cel mai mult, ce instrumente aparțin pipeline-ului și cum se implementează bunele practici fără a reduce viteza de deployment.
Ce este securitatea CI/CD?
Securitatea CI/CD protejează întregul pipeline — de la commit-ul de cod, prin build, test, stocare de artefacte și deployment — împotriva manipulărilor, accesului neautorizat, scurgerii de secrete și injectării de pachete malițioase. Se află la intersecția securității aplicațiilor, securității infrastructurii și integrității lanțului de aprovizionare.
Pipeline-ul este, în esență, un mediu de execuție privilegiat. Runner-ul CI are credențiale pentru furnizorul de cloud, registry-ul de containere, clusterul Kubernetes de producție și managerul de secrete. Compromițând runner-ul, blast radius-ul corespunde unui SRE senior cu drepturi de administrator în toate mediile — nu e exagerare, ci calea de atac documentată pentru clasa de vulnerabilități de tip token-hijacking în GitHub Actions.
Top 10 Riscuri de Securitate CI/CD OWASP
OWASP menține un cadru de riscuri CI/CD separat de clasicul Top 10 pentru aplicații web. Iată riscurile care provoacă cel mai mult daune reale:
CICD-SEC-1: Mecanisme insuficiente de control al fluxului
Codul ajunge în producție fără gate-uri de review. Impuneți reguli de protecție a branch-urilor, revieweri obligatorii și verificări de status care nu pot fi ocolite de cel care face commit-ul.
CICD-SEC-2: Management inadecvat al identității și accesului
Conturi de servicii partajate, chei API cu viață lungă ca variabile de mediu, tokeni CI cu scope la nivel de organizație. Fiecare job de pipeline ar trebui să folosească credențiale cu durată scurtă și scope restrâns — ideal OIDC federation cu furnizorul cloud.
CICD-SEC-3 până la CICD-SEC-10
Abuzul lanțului de dependențe, execuția pipeline-ului otrăvit (PPE), PBAC insuficient, igiena slabă a credențialelor, configurații de sistem nesecurizate, logare inadecvată, integritate slabă a artefactelor și servicii terțe necontrolate completează lista. Secret Detection ar trebui să scaneze fiecare commit și fiecare log de build. Artefactele trebuie semnate cu Sigstore/cosign. Logurile pipeline-ului trebuie stocate în mod inviolabil într-un SIEM.
Bune practici pentru securitatea pipeline-ului CI/CD
Shift Left — dar nu te opri acolo
Rularea SAST la fiecare pull request este obligatorie. Dar shift-left adresează doar codul sursă. Mai ai nevoie de scanări în faza de build (scanarea imaginilor de containere, SCA), în faza de artefacte (semnare și generare SBOM) și în faza de deployment (aplicare de politici). Gate-uri de securitate la fiecare punct de tranziție.
Generarea SBOM este acum standard
Generează un Software Bill of Materials în format CycloneDX sau SPDX pentru fiecare artefact de build. Platforma ta de Vulnerability Management ar trebui să consume aceste SBOM-uri și să le coreleze cu scorurile NVD și EPSS.
Artefacte imutabile și build-uri semnate
Folosește cosign pentru a semna imaginile de containere la build. Verifică semnăturile la deployment cu admission controllers. Container Image Scanning trebuie integrat în hook-urile de push ale registry-ului.
Policy as Code
Policy-as-Code definește cerințele de securitate ale pipeline-ului ca reguli citibile de mașini — blochează build-urile cu imagini care rulează ca root, respinge artefactele fără semnătură validă, împiedică deployment-urile în producție fără un tichet de modificare.
Top instrumente de securitate CI/CD în 2026
Semgrep pentru SAST, Gitleaks și TruffleHog pentru detectarea secretelor, Trivy pentru imaginile de containere și generarea SBOM, Sigstore pentru semnarea artefactelor. Platforme precum SECRAILS integrează aceste capabilități într-un flux DevSecOps unificat. Pentru IaC, Checkov și KICS detectează configurații greșite înainte de deployment, completate de o platformă CSPM pentru validarea mediului live.
Măsurarea maturității securității CI/CD
Framework-ul SLSA, OpenSSF Scorecard și taxonomia de riscuri OWASP CI/CD sunt repere potrivite. Rezultatele ar trebui integrate în programul de Compliance. Cel mai mare decalaj nu este de obicei lipsa instrumentelor — ci procesele fără reguli de blocare reale și gate-uri de securitate cu prea multe excepții. Începe cu câteva reguli de înaltă precizie și extinde de acolo.