Analiza vulnerabilităților și SBOM
CRA transformă nomenclatura dumneavoastră de materiale software într-o obligație vie: cunoașteți ce conține produsul dumneavoastră, monitorizați componentele respective pentru a depista noi vulnerabilități și remediați-le și raportați-le în termenele prevăzute la articolul 14. Această pagină parcurge bucla și instrumentul gratuit care o pune în aplicare.
Generați un SBOM
Generați o nomenclatură de materiale software care poate fi citită automat și care să acopere cel puțin dependențele de nivel superior. Aceasta este o cerință strictă, nu o bună practică.
Cum se generează ↓Monitorizați vulnerabilitățile
Verificați în mod continuu fiecare componentă în raport cu datele active privind vulnerabilitățile (NVD, EUVD). Rezumatele de notificări grupate nu respectă termenul de 24 de ore.
De ce rezumatele sunt insuficiente ↓Evaluați, remediați și raportați
Documentați gradul de exploatabilitate, livrați o corecție și raportați ENISA și CSIRT-ului vulnerabilitățile exploatate în mod activ, în termen de 24 de ore / 72 de ore / 14 zile.
Instrumentul care realizează acest lucru ↓Analizatorul de vulnerabilități CRA
Încărcați SBOM-ul și lista dumneavoastră de vulnerabilități active. Analizatorul verifică fiecare componentă în raport cu Baza de date națională privind vulnerabilitățile (NVD) și cu Baza de date a UE privind vulnerabilitățile (EUVD), semnalează componentele aflate la sfârșitul duratei de viață și generează un raport de conformitate pe care îl puteți atașa la dosarul dumneavoastră tehnic.
Ghiduri practice
Generați un SBOM conform
O nomenclatură de materiale software este o cerință juridică strictă în temeiul anexei I partea II punctul (1). Acest ghid acoperă domeniul de aplicare și formatul obligatorii, modul de generare a acesteia și modul în care alimentează bucla de monitorizare.
1 · Temei juridic
Anexa I partea II („Cerințe privind gestionarea vulnerabilităților”) punctul (1) impune fabricanților „să identifice și să documenteze vulnerabilitățile și componentele … inclusiv prin întocmirea unei nomenclaturi de materiale software într-un format utilizat în mod curent și care poate fi citit automat, acoperind cel puțin dependențele de nivel superior ale produsului.”
Spre deosebire de unele dispoziții ale CRA care permit o anumită flexibilitate de interpretare, obligația de a genera un SBOM care poate fi citit automat și care să acopere cel puțin dependențele de nivel superior nu permite abordări alternative.
2 · Domeniu de aplicare și format obligatoriu
Acoperirea componentelor. SBOM-ul trebuie să documenteze toate dependențele de nivel superior, pragul juridic minim, mai degrabă decât ținta recomandată. Cartografiați dependențele tranzitive (indirecte) ori de câte ori este posibil; un SBOM superficial respectă litera legii, dar este adesea insuficient pentru o gestionare eficace a vulnerabilităților.
Format. CRA impune un „format utilizat în mod curent, care poate fi citit automat”. Formatele acceptate includ:
- SPDX (ISO/IEC 5962:2021): adoptat pe scară largă, axat pe licențiere, potrivit pentru documentația de conformitate.
- CycloneDX: axat pe securitate, potrivit pentru fluxurile de lucru de gestionare a vulnerabilităților.
- Alte formate structurate (JSON, XML) provenite din instrumente recunoscute sunt, în general, acceptabile în cadrul cerinței de bază.
Nu stocați SBOM-urile în format PDF. Formatul PDF poate fi contestat de autoritățile de supraveghere a pieței ca neputând fi citit automat. Stocați rezultatul nativ în format JSON, XML sau tag-value generat de lanțul dumneavoastră de instrumente.
Câmpuri de metadate obligatorii
| Câmp | Descriere |
|---|---|
| Denumirea componentei | Identificator unic pentru bibliotecă, pachet sau modul |
| Versiune | Șir exact al versiunii; intervalele de versiuni sunt insuficiente |
| Furnizor / origine | Denumirea editorului, a furnizorului sau a proiectului cu sursă deschisă |
| Relații de dependență | Directe față de tranzitive; graf de dependențe acolo unde este posibil |
| Hash criptografic | Verificare a integrității cu SHA-256 sau mai puternică pentru fiecare componentă |
| Identificatorul licenței | Expresie de licență SPDX (de ex. Apache-2.0, MIT) |
3 · Generarea SBOM-ului
Majoritatea platformelor moderne pot genera SBOM-uri în mod automat în momentul compilării, fără costuri suplimentare:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Generează SPDX JSON.
- GitLab: Rapoartele CycloneDX sunt generate nativ de sarcina CI/CD de scanare a dependențelor.
- Syft (Anchore): instrument CLI cu sursă deschisă care generează SPDX și CycloneDX pentru imagini de containere, sisteme de fișiere și manifeste de pachete.
- cdxgen: SBOM-uri CycloneDX pentru npm, Maven, pip, Go, Rust și altele.
Verificarea vulnerabilităților. Înainte de a finaliza un SBOM, verificați fiecare componentă în raport cu bazele de date privind vulnerabilitățile cunoscute. Atât scanerul GitHub, cât și Syft se integrează cu Grype pentru aceasta. Includerea unei componente cu o vulnerabilitate cunoscută, deja corectată, constituie o încălcare directă a anexei I și nu permite nicio flexibilitate de interpretare.
Dacă există o versiune corectată a unei componente, trebuie să o utilizați. În cadrul CRA nu există nicio categorie de „risc acceptat” pentru vulnerabilitățile soluționate. Acționați în privința fiecărei constatări înainte de introducerea produsului pe piață.
4 · Întreținere pe durata ciclului de viață și păstrare
Un SBOM este un artefact viu, actualizat în mod continuu pe parcursul ciclului de viață asistat al produsului pentru a reflecta componentele corectate, noile dependențe, componentele eliminate la sfârșitul duratei de viață și modificările din lanțul de aprovizionare. Toate versiunile documentației tehnice, inclusiv SBOM-urile, trebuie păstrate timp de cel puțin 10 ani de la prima introducere pe piață…
Secțiunile 4-9: ciclul de viață, sancțiunile, BSI TR-03183-2 și lista de verificare a pregătirii
Restul ghidului acoperă obligația de păstrare timp de 10 ani, confidențialitatea și divulgarea în cadrul lanțului de aprovizionare, integrarea cu raportarea vulnerabilităților prevăzută la articolul 14, frecvența monitorizării, normele BSI mai stricte ale Germaniei, amenzile (de până la 15 milioane € sau 2,5 % din cifra de afaceri) și o listă de verificare a pregătirii gata de utilizare.
Instrumente și analize conexe
Matricea de conformitate
Fiecare obligație din ciclul de viață cu trimiterea la articolul corespunzător; monitorizați-vă progresul și descărcați lista de verificare completă.
Situația actuală
Stadiul actual al CRA: acte de punere în aplicare, standarde armonizate și drumul către decembrie 2027.
Calculator de costuri
O estimare orientativă a costului probabil al asigurării și menținerii conformității.