SBOM w CRA to dowód, nie plik wygenerowany raz

W Cyber Resilience Act wykaz składników oprogramowania nie jest pamiątką z audytu. Annex I część II każe producentowi identyfikować i dokumentować podatności, w tym SBOM. Art. 13 wiąże tę dokumentację z oceną ryzyka przez cykl życia. Do 11 grudnia 2027 SBOM leży w pliku technicznym, którego może zażądać nadzór rynku.

Eksport CycloneDX albo SPDX z zeszłorocznego pipeline nie robi tej roboty, jeśli produkt na rynku Unii zdążył przejść dwie wersje mniejsze.

Czego CRA naprawdę chce od SBOM

Rozporządzenie nie wybiera formatu. Wybiera obowiązek. Wprowadzacie produkt z elementami cyfrowymi na rynek. Winni jesteście należytej staranności wobec komponentów osób trzecich. Musicie umieć powiedzieć, co jest w wersji, którą wysłaliście, i obsługiwać podatności przez okres wsparcia podany przy zakupie (miesiąc i rok).

To robi z SBOM rekord produktu, nie rekord repozytorium. Jednostką jest wersja PDE: firmware w pudełku, instalator w sklepie, biblioteka sprzedawana jako komponent. Zrzut monorepo, który miesza trzy SKU, nie jest dowodem. Sejf w chmurze, którego operacje nie otworzą w piątkową noc, też nie.

SBOM musi się też nadać, gdy 11 września 2026 ruszy art. 14. Aktywnie wykorzystywana podatność w zależności przechodniej jest problemem 24h tylko wtedy, gdy umiecie nazwać produkty, które ją zawierają.

Zgoda z wysłaną wersją, albo plik jest już zły

Typowa porażka to dryf. Sklep pokazuje 3.4.1. SBOM na dysku wspólnym powstał z main w marcu. Dwa sprinty dodały bibliotekę TLS i zdjęły SDK dostawcy. Skan nadal chodzi. Dowód nie.

Blokujcie SBOM do builda, który wyszedł z magazynu:

• ten sam ciąg wersji co w katalogu,
• ten sam commit / digest obrazu, który podpisaliście,
• składniki własne i obce, z dostawcą i wersją,
• data, żeby było widać, kiedy plik przestał zgadzać się z wyrobem.

Należyta staranność zostaje przy komponencie. Jeśli dostawca puszcza poprawkę, wiersz musi pokazać, że ją zobaczyliście, oceniliście wobec tego PDE i albo wzięliście aktualizację, albo przyjęliście udokumentowane ryzyko wobec Annex I. Zielona plakietka w skanerze SaaS nie jest tym wierszem.

SBOM zasila kolejkę, kolejka nie jest SBOM

CRA to nie skaner podatności. SBOM mówi kolejce, jakie składniki istnieją. Skaner mówi, które z nich mają znane słabości. Art. 14 zadaje trzecie pytanie: czy to jest aktywnie wykorzystywane, czy to poważny incydent, i czy w 24h ostrzeżecie CSIRT i ENISA.

Jeśli te trzy obiekty siedzą w trzech narzędziach pod trzema nazwami produktu, zegar 24h jest już stracony. Minimalne złączenie jest nudne i niepodlegające negocjacji:

1. Tożsamość PDE w katalogu.
2. Linie SBOM podpięte do tej tożsamości.
3. Findingi podpięte do tych linii.
4. Nazwany właściciel i stan 24h / 72h.

Bez złączenia dostajecie albo ciszę (nikt nie wie, że produkt jest objęty), albo szum (każde CVE z branży ląduje na jednej liście mailingowej).

Co ma leżeć w pliku technicznym

Do 11 grudnia 2027 plik to nie „załóż latest SBOM.pdf”. To tożsamość wyrobu, ocena ryzyka, dowody Annex I, SBOM wprowadzonej wersji, okres wsparcia, instrukcje, deklaracja UE i znak CE.

To ma skutki dla przechowywania:

• organ pyta o ten produkt, nie o cały majątek software’owy firmy,
• SBOM może być potrzebny lata po tym, jak pociąg wydań pojechał dalej,
• eksport nie może oznaczać skopiowania katalogu do chmury dostawcy.

Crado AI trzyma SBOM on-premise, obok katalogu i kolejki art. 14, właśnie dlatego. Wykaz składników jest częścią pliku, który pokażecie, zanim wyrób wyjdzie z magazynu.

Praktyka SBOM, która działa przed wrześniem 2026

1. Generujcie SBOM z pipeline dla każdej wersji, którą jeszcze wspieracie, nie tylko dla następnego release.
2. Nie wysyłajcie, jeśli wersja w katalogu i wersja w SBOM się nie zgadzają.
3. Na każdej linii obcej trzymajcie dostawcę i wersję, żeby staranność miała uchwyt.
4. Findingi spinajcie z tymi liniami. Zamykajcie albo przyjmujcie je wobec Annex I, nie wobec liczby ticketów.
5. Przećwiczcie jeden drill art. 14: wybierzcie komponent, wypiszcie PDE, nazwijcie właściciela, zmierzcie wczesne ostrzeżenie.

Jeśli punktu 5 nie dacie rady zrobić w popołudnie robocze, SBOM jest nadal plikiem. Jeszcze nie jest dowodem.