Jeśli tworzysz oprogramowanie na rynek europejski, ktoś zapewne już poprosił Cię o wykaz materiałowy oprogramowania. Cyber Resilience Act wymaga od producentów sporządzenia takiego wykazu i przechowywania go w dokumentacji technicznej, a klienci pytają o niego coraz częściej, na długo przed jakimkolwiek regulatorem. Kiedy Twój produkt osadza bibliotekę komponentów, to pytanie trafia do nas.
Od tego wydania odpowiada na nie każdy instalator sgcWebSockets. Instalator zapisuje w folderze instalacyjnym wykaz materiałowy w formacie CycloneDX jako sbom.cdx.json, wymieniając komponenty najwyższego poziomu, z których zbudowana jest biblioteka, wraz z ich wersjami i licencjami.
Generowany przez instalator, nie utrzymywany ręcznie
Ciekawa nie jest sama obecność pliku, lecz to, skąd on pochodzi. Wykaz materiałowy aktualizowany ręcznie po cichu się dezaktualizuje, a dokument zgodności podający wersję, której już nie dostarczasz, jest gorszy niż brak dokumentu.
Dlatego nie jest on utrzymywany ręcznie. Skrypt instalatora uruchamia generator podczas budowania, a ten generator odczytuje każdą wersję z pliku, który jest jej faktycznym źródłem: wersję produktu z history.txt, Indy z IdVers.inc, zlib z zlib.h, OpenSSL z modułów statycznego linkowania. Jeśli którejkolwiek z tych wartości nie da się odczytać, generator zatrzymuje się z błędem, a budowanie instalatora kończy się niepowodzeniem. Nigdy nie zgaduje i nigdy nie sięga po wartość, którą ktoś kiedyś wpisał ręcznie.
Praktyczny efekt jest taki, że SBOM nie może się rozjechać. Podnieś wersję zlib, a kolejny zbudowany instalator to odnotuje, bez potrzeby, by ktokolwiek o tym pamiętał.
Opisuje Twoją edycję, a nie ogólny produkt
To część, która najprawdopodobniej ma dla Ciebie znaczenie. Wykaz materiałowy nie jest taki sam dla każdej edycji, ponieważ edycje nie zawierają tego samego kodu firm trzecich.
Enterprise i All-Access kompilują dostosowaną wersję Indy dostarczaną razem z sgcWebSockets, a ten fork niesie ze sobą własną kopię zlib. Core, Standard i Professional budowane są w oparciu o Indy dołączone do Twojej instalacji Delphi lub C++ Builder, którego ani nie forkujemy, ani nie redystrybuujemy. Dla tych edycji nie możemy uczciwie podać żadnej wersji Indy, ponieważ wersją jest to, co dostarcza Twoje IDE.
Pojedynczy ogólny SBOM byłby zatem błędny dla większości instalacji. Zamiast tego instalator generuje dokument dla pakowanej edycji, więc plik, który otrzymujesz, opisuje to, co faktycznie masz.
| Edycja | Indy | zlib |
|---|---|---|
| Core, Standard, Professional | dostarczane przez Twoje IDE, nieredystrybuowane przez nas | trafia do produktu przez to samo Indy |
| Enterprise, All-Access | dostosowany fork Indy, wersja podana | dołączona kopia, wersja podana |
Co jest w środku
Dokument ma postać CycloneDX 1.6 JSON, czyli powszechnego formatu odczytywanego maszynowo, który narzędzia inwentaryzacyjne i skanujące już rozumieją. Obok komponentów zapisuje licencję każdego z nich, informację o tym, czy to my go redystrybuujemy, czy dostarcza go Twoje IDE, oraz miejsce, w którym znajduje się w drzewie źródeł.
Zawiera także oświadczenia VEX tam, gdzie są przydatne. Jeśli znane CVE dotyczy wersji komponentu, ale nie jest osiągalne z naszego kodu, dokument mówi o tym wprost, wraz z uzasadnieniem, zamiast zostawiać Ci to do rozstrzygnięcia. Takie wpisy pojawiają się i znikają automatycznie wraz ze zmianą wersji komponentów, ponieważ generator decyduje na podstawie odczytanej wersji, a nie notatki, którą ktoś kiedyś zostawił.
Gdzie go znaleźć
Zajrzyj do folderu, w którym zainstalowałeś produkt, obok history.txt i licencji.
C:\Program Files (x86)\sgcWebSockets\sbom.cdx.jsonPrzekaż go do narzędzia, którego używasz do inwentaryzacji, dołącz do kwestionariusza dostawcy albo włącz jego wpisy do wykazu materiałowego, który przygotowujesz dla własnego produktu. Jeśli Twój zespół ds. zgodności potrzebuje go w innym formacie lub chce wypełnionego formularza oceny dostawcy dla konkretnej kompilacji, napisz do nas przez formularz kontaktowy, podając produkt, edycję i używaną wersję.
Jedna rzecz, której świadomie nie zrobiliśmy
Nie publikujemy SBOM na tej stronie. Cyber Resilience Act wymaga od producentów sporządzenia go i przechowywania w dokumentacji technicznej, nie wymaga publikacji, a niewiele można zyskać, wręczając inwentarz komponentów każdemu, kto o niego poprosi. Dostarczanie go wewnątrz produktu oddaje go w ręce tych, którym się należy, czyli licencjobiorców oraz, na żądanie, organów nadzoru rynku.
Więcej o tym, jak podchodzimy do tego rozporządzenia, przeczytasz na naszej stronie Cyber Resilience Act.