Seria II: De la infrastructură la proiecte agentice în producție. Episodul 12 din 20.
În episodul anterior am evaluat dacă un agent de programare livrează o modificare acceptabilă. Dar aplicația conține mai mult decât codul scris de agent sau de echipă: biblioteci, imagini de containere și instrumente care transformă sursele într-un produs executabil. Pentru portalul B2B fictiv al seriei, decizia principală este să acceptăm o componentă numai după verificarea identității, versiunii și riscurilor sale, apoi să păstrăm dovezile lângă versiunea livrată.
Lanțul software începe înaintea instalării
O dependență este o componentă externă de care proiectul are nevoie. Unele sunt directe, alese de echipă; altele sunt tranzitive, aduse de acele componente. O bibliotecă pentru export poate instala alte biblioteci, iar imaginea unui container poate include pachete ale sistemului de operare. Instrumentele de construire contează și ele: chiar dacă nu ajung în aplicația finală, execută operații asupra codului și fișierelor proiectului.
Lanțul de aprovizionare software cuprinde sursele, furnizorii, serviciile și procesele prin care aceste elemente ajung în produs. Mutarea aplicației în cloud sau păstrarea ei on-prem, pe infrastructura proprie, nu elimină acest lanț. În ambele variante trebuie să știm ce descărcăm și ce folosim efectiv. Inventarul include componentele aplicației, imaginea de bază și instrumentele relevante ale procesului de construire.
O bibliotecă propusă de agent nu este încă aprobată
Folosim un scenariu ipotetic: echipa adaugă exportul solicitărilor într-un fișier CSV, un format tabelar cu valori separate prin delimitatori. Agentul de dezvoltare propune o bibliotecă pentru tratarea separatorilor și diacriticelor. Mai întâi verificăm dacă funcția poate fi realizată cu componentele deja acceptate. O dependență nouă are un cost de întreținere chiar dacă instalarea ei durează puțin.
Dacă biblioteca este necesară, verificăm numele exact în registrul de pachete, adică serviciul care distribuie componentele, și îl confruntăm cu documentația proiectului. Controlăm sursa oficială, autorii sau organizația responsabilă, licența, versiunile disponibile și istoricul actualizărilor. Popularitatea poate orienta investigația, dar nu înlocuiește aceste verificări. Existența unui pachet cu numele sugerat nu dovedește că este componenta intenționată.
Studiul „We Have a Package for You!”, prezentat la USENIX Security în august 2025, documentează recomandări de pachete inexistente în cod generat de modelele evaluate. Rezultatele nu estimează riscul fiecărui model actual. Ele justifică verificarea independentă înainte de instalare. În portal, agentul poate propune biblioteca; un responsabil desemnat acceptă componenta și motivul utilizării sale.
Fixăm versiunea și controlăm instalarea
Un lockfile este fișierul care înregistrează versiunile concrete rezolvate de managerul de pachete, instrumentul care instalează dependențele. Îl păstrăm în depozitul de cod și examinăm modificările sale împreună cu cererea de integrare. O schimbare mică a bibliotecii directe poate aduce multe schimbări tranzitive.
Pentru un proiect JavaScript care folosește npm, comanda npm ci instalează pe baza unui lockfile existent și refuză neconcordanța cu lista declarată de dependențe, fără să rescrie lockfile-ul. Documentăm și configurația instalării. Acest control nu demonstrează că pachetele sunt sigure și nu garantează singur un produs final identic.
Instalarea se execută într-un mediu izolat, cu acces limitat la date și secrete. Verificăm scripturile care pot rula la instalare și activăm numai ceea ce proiectul necesită. Pentru imagini de containere, păstrăm și un digest, o amprentă criptografică a conținutului, astfel încât eticheta unei versiuni să nu fie singura referință. Fixarea componentelor trebuie însoțită de un proces regulat de actualizare, altfel conservă și defectele cunoscute.
SBOM: inventarul versiunii pe care o livrăm
SBOM, din „Software Bill of Materials”, este lista structurată a componentelor software. CycloneDX este un format care poate reprezenta componente, versiuni și relațiile dintre dependențe. Pentru exemplul nostru, propunem generarea inventarului la construirea fiecărei versiuni livrabile și asocierea lui cu produsul rezultat.
Un artefact este rezultatul procesului de construire, de exemplu imaginea containerului portalului. Identificăm artefactul prin digest și păstrăm lângă el SBOM-ul, versiunea surselor și data generării. O listă extrasă numai din declarațiile proiectului poate să nu descrie toate componentele prezente în imagine. Verificăm ce acoperă instrumentul ales, inclusiv pachetele sistemului de operare, codul copiat manual și componentele încărcate ulterior.
SBOM-ul ajută echipa să afle ce versiuni sunt afectate când apare o alertă. Nu este o certificare de securitate și nu elimină vulnerabilitățile. Completitudinea lui depinde de sursele și metodele de generare. Pentru un IMM, un inventar verificabil al versiunilor efectiv livrate este mai util decât un fișier generat o singură dată și uitat.
Proveniența explică traseul până la artefact
Proveniența descrie din ce surse și prin ce proces a fost produs artefactul. Specificația SLSA 1.2, aprobată, oferă cerințe și formate pentru consolidarea integrității lanțului software. În exemplul portalului, păstrăm referința surselor, identitatea sistemului de construire și parametrii relevanți, în măsura în care platforma îi poate documenta și verifica.
O semnătură criptografică trebuie verificată față de identitatea de încredere și politica echipei. Verificăm și că dovada se referă la digestul artefactului primit, sursa așteptată și procesul permis. O semnătură validă de la o identitate neacceptată nu este suficientă. Nici proveniența verificată nu garantează corectitudinea codului sau absența vulnerabilităților. Dacă o componentă nu oferă aceste dovezi, documentăm limita și decizia de acceptare, fără a declara un nivel SLSA neîndeplinit.
Alertele au nevoie de un responsabil
Analiza automată compară componentele inventariate cu informațiile disponibile despre vulnerabilități. Un rezultat fără alerte înseamnă doar că instrumentul nu a raportat probleme în datele și momentul verificării. Nu dovedește că toate componentele sunt lipsite de defecte.
Pentru fiecare alertă, stabilim componenta afectată, versiunile livrate, condițiile de exploatare relevante și remedierea disponibilă. O bibliotecă folosită numai la construire poate rămâne importantă pentru securitatea procesului. Responsabilul decide actualizarea, înlocuirea sau o excepție temporară justificată, cu termen de revizuire. Rulăm din nou testele de export și verificările existente după schimbare. O alertă nu se închide doar fiindcă agentul afirmă că a remediat-o.
Lista minimă înaintea livrării
Pentru biblioteca CSV din scenariu, fișa de acceptare răspunde la cinci întrebări: este componenta intenționată, este versiunea controlată, sunt licența și întreținerea evaluate, apare în inventarul artefactului și există un responsabil pentru alerte? Legăm răspunsurile de dovezi și de modificarea aprobată.
Regulile se aplică atât componentelor propuse de agenții care dezvoltă portalul, cât și celor folosite de eventualii agenți integrați în aplicație. Aceștia au funcții diferite, însă bibliotecile și imaginile lor intră tot în inventar. Episodul următor va introduce CI/CD, fluxul automat de integrare și livrare, unde aceste verificări devin pași repetabili înaintea lansării.
Surse
Surse verificate la 13 octombrie 2026:
- OWASP CycloneDX, Software Bill of Materials, pentru componente și relațiile dintre dependențe.
- SLSA 1.2, Verifying artifacts și Build provenance, pentru verificarea provenienței și a artefactului.
- npm CLI 11, npm ci, pentru instalarea controlată pe baza lockfile-ului.
- Spracklen și colaboratorii, We Have a Package for You!, USENIX Security, august 2025, pentru fenomenul pachetelor inexistente în configurațiile studiate.
Vrei să verifici ce componente și riscuri intră în aplicațiile firmei? Discută cu i8 despre inventarul software și o livrare verificabilă.
