Timp de un deceniu, conversația despre DevOps s-a învârtit în jurul vitezei: cât de repede ajunge un commit în producție și cât de rar se strică ceva. În 2026, întrebarea care decide contracte s-a mutat în altă parte: cât de repede poți dovedi ce ai livrat, din ce componente este făcut și cine a aprobat schimbarea. Pipeline-ul nu mai este doar un mecanism de livrare, ci principalul instrument de probă al unei firme de software.
Schimbarea nu vine dintr-o modă tehnologică, ci dintr-un calendar legislativ. Pe 11 septembrie 2026 intră în aplicare primele obligații concrete ale Regulamentului european privind reziliența cibernetică (Cyber Resilience Act): raportarea vulnerabilităților exploatate activ și a incidentelor severe, în termen de 24 de ore de la constatare. Restul obligațiilor devin aplicabile în decembrie 2027, însă arhitectura care le face posibile se construiește acum, în pipeline.
De la shift left la shift legal
Shift left a însemnat mutarea testelor și a scanărilor cât mai aproape de dezvoltator. Ce vedem în 2026 este pasul următor: mutarea dovezii în același loc. Fiecare build produce, pe lângă artefactul livrabil, un pachet de metadate semnate — SBOM, atestare de proveniență, rezultate de scanare, jurnal de aprobări. Dacă acel pachet lipsește, artefactul nu ajunge în registry, exact cum acum zece ani un build cu teste roșii nu ajungea în producție.
Diferența practică este cine consumă rezultatul. Testele sunt pentru echipă. Atestările sunt pentru clientul enterprise, pentru auditor, pentru autoritatea de reglementare și, tot mai des, pentru departamentul de achiziții care trimite un chestionar de securitate de 120 de întrebări înainte de semnarea contractului. Echipele care au automatizat răspunsul la acel chestionar câștigă săptămâni întregi de ciclu de vânzare.
Estimările din piață pentru 2026 arată direcția: aproximativ două treimi dintre organizațiile care livrează software în UE generează deja SBOM la fiecare build, față de sub o treime în 2024, iar aproape jumătate au cel puțin o poartă automată de politică. Ce lipsește aproape peste tot este pasul următor: păstrarea și interogarea acelor dovezi la șase luni după livrare.
Patru presiuni care rescriu pipeline-ul
1. CRA mută termenul de reacție la 24 de ore
Un termen de raportare de 24 de ore nu este o problemă juridică, ci una de inginerie. Ca să știi în 24 de ore că o vulnerabilitate exploatată activ te afectează, ai nevoie de trei lucruri pe care puține echipe le au încă legate între ele:
- inventar exact al componentelor din fiecare versiune aflată la clienți, nu doar din ultimul build;
- corelare automată între fluxurile de vulnerabilități și acel inventar, cu răspuns în minute;
- un proces de livrare a patch-ului care nu depinde de disponibilitatea unei singure persoane.
Firmele care tratează SBOM-ul ca pe un fișier generat și uitat descoperă exact aici că au dovada, dar nu au căutarea.
2. NIS2 se propagă pe lanțul de furnizori
Directiva NIS2, transpusă în România prin OUG 155/2024, cu DNSC în rol de autoritate, vizează direct entitățile esențiale și importante. Efectul real pentru IMM-uri vine însă indirect, prin contract: clauzele privind securitatea lanțului de aprovizionare se propagă în jos. Un furnizor de software pentru o companie de utilități sau pentru un spital ajunge să răspundă, în 2026, la cerințe de autentificare multifactor, jurnalizare, gestiune a vulnerabilităților și timp garantat de remediere, chiar dacă legea nu îl vizează nominal.
3. Proveniența devine artefact de build, nu document
Semnarea cu chei ținute manual dispare. Standardul de facto în 2026 este semnarea fără chei, cu identitate efemeră emisă de sistemul CI, plus atestări care descriu ce sursă, ce comandă și ce runner au produs artefactul. Nivelul cerut de clienții mari se apropie de SLSA nivel 3, ceea ce în practică înseamnă:
- identitate de workload emisă de platforma CI, fără secrete de rotit;
- atestări atașate imaginii, nu unui wiki intern;
- verificare la admisia în cluster, nu doar la push în registry;
- politici scrise ca fișiere versionate, revizuite prin pull request.
4. Costul dovezii devine linie de buget
Toată această infrastructură are un preț. În proiectele pe care le vedem, lanțul complet de dovezi crește timpul mediu de build cu 15–25% și multiplică volumul de artefacte stocate, pentru că atestările se păstrează pe toată durata de suport a produsului. Echipele mature bugetează explicit acest cost și îl compensează prin cache agresiv, build-uri incrementale și scanări grele rulate doar pe ramurile care ajung la client.
Cum arată un pipeline auditabil în mod implicit
Nu este vorba de un produs cumpărat, ci de câteva decizii de proiectare repetate consecvent:
- o singură definiție de build, reutilizată de toate echipele, în locul a douăzeci de fișiere copiate;
- generarea SBOM și a atestării ca pas obligatoriu, nu opțional;
- un depozit de dovezi interogabil: care versiune, la ce client, cu ce componente, din ce commit;
- porți de politică declarative, cu excepții care au termen de expirare și proprietar nominal;
- medii efemere de testare, distruse automat, ca să nu devină ele însele suprafață de atac;
- un buton de urgență, complet jurnalizat, pentru situațiile în care regula chiar trebuie ocolită.
Ultimul punct separă un sistem folosit de unul ocolit. Orice mecanism de conformitate fără o cale explicită de excepție ajunge, în șase luni, să fie ocolit informal — iar excepțiile informale nu apar în niciun raport.
Metrici: DORA nu mai este suficient
- timpul de la publicarea unui CVE relevant până la identificarea versiunilor afectate (țintă rezonabilă în 2026: sub 4 ore, automat);
- procentul artefactelor din producție cu atestare validă (țintă: 100%, măsurat, nu presupus);
- timpul mediu de remediere pentru vulnerabilități critice în componente terțe;
- numărul de excepții de politică active și vechimea lor medie.
Aceste patru cifre spun despre o organizație mai mult decât frecvența deployment-urilor și sunt, în plus, exact ce cere un chestionar de achiziții.
Ce înseamnă pentru firmele din România
Piața locală de servicii IT are un avantaj structural aici: echipele sunt mici, iar sistemele sunt suficient de recente încât standardizarea să nu ceară ani. Un furnizor cu 15–40 de ingineri poate ajunge la un lanț complet de dovezi în două-trei luni, în timp ce pentru o corporație cu sute de pipeline-uri moștenite același rezultat este un program de doi ani.
Avantajul se traduce comercial. În 2026, întrebările despre SBOM, semnare și timp de remediere apar deja în caiete de sarcini publice și în due diligence-ul clienților germani, olandezi și nordici — exact segmentul care plătește cel mai bine pentru nearshore în România. Un furnizor care răspunde cu dovezi generate automat, nu cu un document actualizat manual, intră într-o altă categorie de preț.
Riscul este simetric. Firmele care livrează software integrat în produse fizice — automatizări industriale, retail, dispozitive conectate — vor descoperi în 2027 că intră în domeniul CRA prin produsul clientului, fără să fi discutat vreodată despre asta. Discuția contractuală despre cine generează SBOM-ul și cine raportează în 24 de ore este mult mai ieftină acum decât în ultima lună înainte de termen.
Un plan realist pe 90 de zile
- Zilele 1–30: inventar. Ce livrați, în ce versiuni, la ce clienți, cu ce dependențe. Fără acest pas, restul este teatru.
- Zilele 31–60: automatizare. SBOM și semnare la fiecare build, stocate într-un loc interogabil, cu o singură definiție de pipeline reutilizată.
- Zilele 61–90: politică și exercițiu. Blocați promovarea artefactelor neconforme și simulați un incident: un CVE critic apare vineri la ora 17:00 — cât durează până știți cine este afectat?
Concluzie
DevOps în 2026 nu mai este despre a livra mai des. Frecvența livrărilor este o problemă rezolvată pentru majoritatea echipelor competente. Problema nouă este încrederea verificabilă: capacitatea de a răspunde, în ore, la întrebări despre ceva livrat acum șase luni. Firmele care își construiesc acum acest reflex nu vor bifa doar o conformitate, ci vor avea un argument de vânzare pe care concurența îl va copia cu doi ani întârziere.
