De la SBOM la poarta de vulnerabilitati: Syft si Grype in CI la MSP

Furnizorii de servicii gestionate care ruleaza pipeline-uri CI pentru clienti pot combina doua instrumente open source de la Anchore, Syft si Grype, intr-o singura poarta pentru lantul de aprovizionare software: Syft catalogheaza fiecare pachet dintr-un build intr-o lista de materiale software (SBOM), iar Grype compara acel inventar cu vulnerabilitati cunoscute inainte de a lasa build-ul sa treaca. Acest ghid explica ce face fiecare instrument, cum se completeaza reciproc si unde combinatia singura nu este suficienta.

Generati mai intai inventarul, cu Syft

Syft, intretinut de Anchore sub licenta Apache-2.0, genereaza un SBOM in format SPDX sau CycloneDX din imagini de containere, sisteme de fisiere si pachete. Anchore a lansat syft v1.52.0 pe 17 septembrie, corectand doua erori de cataloger care produceau inventare inexacte: catalogerul bazei de date RPM raporta o versiune de biblioteca invechita dintr-o imagine Rocky Linux 10 cu un singur strat, iar catalogerul de arhive Java returna o versiune necunoscuta pentru uber-jar-uri. Lansarea aduce si intretinere a dependentelor: 52 de modificari care remediaza sase vulnerabilitati cunoscute, inclusiv o actualizare a bibliotecii grpc-go care a inchis mai multe avize publicate. Corectiile de cataloger conteaza mai ales pentru echipele care se bazeaza pe imagini RPM sau uber-jar-uri Java, unde o versiune invechita sau necunoscuta in SBOM ar ascunde ceea ce un scaner din aval verifica de fapt.

Grype transforma inventarul intr-o poarta

Grype, intretinut tot de Anchore, scaneaza imagini de containere, sisteme de fisiere si SBOM-uri pentru vulnerabilitati cunoscute. La 23 septembrie 2026, depozitul sau de pe GitHub arata aproximativ 12.900 de stele si un commit din urma cu doua zile, semn de intretinere activa. Integrat intr-un pipeline CI imediat dupa generarea SBOM-ului, Grype permite esuarea automata a unui build atunci cand apare o CVE cunoscuta, in loc sa se bazeze pe cineva care isi aminteste sa verifice mai tarziu. Fluxul standard genereaza SBOM-ul in timpul build-ului, de obicei cu Syft, apoi ruleaza Grype pe acel SBOM si, optional, direct pe imaginea construita, verificand fiecare componenta listata fata de datele despre vulnerabilitati cunoscute. Un prag de severitate decide daca job-ul esueaza: orice depaseste pragul blocheaza merge-ul, cu exceptia unei exceptii inregistrate, cu responsabil si termen.

Faceti exceptiile vizibile, nu tacute

O poarta fail-closed este utila doar daca exceptiile sunt vizibile si au un responsabil. Fara un proces scris, echipele fie dezactiveaza poarta prima data cand blocheaza ceva urgent, fie acumuleaza derogari tacute care anuleaza sensul scanarii. O exceptie trebuie sa indice un responsabil, un motiv si o data de expirare dupa care constatarea este reevaluata, nu sa ramana valabila la nesfarsit.

Ce nu face poarta

Grype arata ce este cunoscut ca vulnerabil in ceea ce urmeaza sa fie lansat; nu aplica patch-uri, nu impune principiul privilegiului minim si nu inlocuieste monitorizarea in timpul executiei dupa ce o sarcina de lucru este implementata. De asemenea, depinde de prospetimea bazei sale de date de vulnerabilitati, asa ca fixarea scanerului pe un flux invechit anuleaza scopul. La standardizarea acestei abordari pe pipeline-urile mai multor clienti, miscarea practica este testarea pragurilor de severitate mai intai intr-un pipeline care nu este de productie, pentru ca un prag prea agresiv va invata echipele doar sa ocoleasca poarta. Arhivarea fiecarui SBOM alaturi de artefactul de build asociat transforma acelasi inventar si intr-un pachet de dovezi pentru clienti sau asiguratori, fara cost suplimentar de scanare. Furnizorii care au nevoie de sprijin extern pentru teste de penetrare, evaluarea vulnerabilitatilor, raspuns la incidente sau conformitate NIS2/DORA/GDPR pot apela la serviciile de securitate cibernetica Altovar.

Ce este de facut

• Adaugati Syft ca pas de build care emite un SBOM SPDX sau CycloneDX pentru fiecare imagine sau artefact si faceti build-ul sa esueze daca generarea produce o eroare.
• Rulati Grype pe acel SBOM, si optional pe imaginea construita, imediat dupa, cu un prag de severitate testat mai intai intr-un pipeline care nu este de productie.
• Scrieti procesul de exceptie inainte ca poarta sa intre in productie: cine il poate acorda, ce trebuie sa inregistreze si cand expira.
• Arhivati fiecare SBOM alaturi de artefactul de build asociat, astfel incat sa poata servi ulterior ca pachet de dovezi pentru clienti sau asiguratori.
• Mentineti actualizata baza de date de vulnerabilitati a Grype; un flux invechit lasa sa treaca build-uri pe care poarta ar fi trebuit sa le blocheze.
• Combinati poarta cu aplicarea de patch-uri si monitorizarea in timpul executiei, deoarece niciunul dintre cele doua instrumente nu acopera ce se intampla dupa implementare.

Surse: Grype pe GitHub, lansarile anchore/syft.