Podatność ma inny status w różnych wydaniach
Release jest brakującym ogniwem pomiędzy produktem, SBOM, podatnością, poprawką i dowodami dostarczenia aktualizacji.
Dlaczego SBOM z repo nie musi odpowiadać finalnemu firmware?
Build może statycznie linkować biblioteki, kopiować kod bez package managera, dołączać binarne biblioteki dostawcy albo używać zmodyfikowanego BSP, HAL i RTOS. Część informacji dostępnych w czasie budowania może nie być możliwa do wiarygodnego odtworzenia z samego pliku wynikowego.
- wiąż SBOM z konkretnym Product Release, nie tylko nazwą produktu
- zapisz SHA-256 finalnego artefaktu oraz build ID
- zachowaj metodę powstania SBOM i wersję narzędzia
- oznacz zakres jako claimed complete, partial albo unknown
- nie łącz automatycznie podobnie nazwanych komponentów
Minimalny rekord Shipped Artifact
| Pole | Po co je zachować |
|---|---|
| Filename i SHA-256 | Jednoznacznie wskazują analizowany artefakt bez przesyłania lub wykonywania firmware |
| Firmware version i build ID | Łączą techniczny build z wersją produktową |
| Build date, target, BSP i RTOS | Opisują jawne źródłowe fakty; brakującej wartości nie należy zgadywać |
| SBOM source method | Rozdziela build-generated, supplier, binary-analysis import i manual assertion |
| Tool name i version | Pozwalają odtworzyć metodę generowania lub analizy |
| Completeness i rationale | Pokazują deklarowany zakres oraz znane luki bez stwierdzenia verified complete |
Jak traktować binary blobs, vendor fork, BSP i RTOS?
Binarnego komponentu bez wiarygodnej tożsamości nie należy dopasowywać na podstawie samej nazwy pliku. Zapisz dostawcę, deklarowaną wersję, target/release, źródło informacji oraz nierozstrzygnięty status. Poproś dostawcę o SBOM, wersję komponentu, okres wsparcia, politykę aktualizacji i znane podatności dla dokładnego wydania.
Co zrobić, gdy dostawca backportował poprawkę bez zmiany wersji?
Version matching może nadal wskazywać CVE, mimo że dostawca twierdzi, że przeniósł poprawkę do własnej gałęzi. Takie twierdzenie jest źródłem do przeglądu, a nie automatycznym statusem NOT_AFFECTED lub FIXED.
- zamroź dokładny artifact, komponent i CVE w requestcie
- zbierz upstream version, vendor version, fork i patch/reference ID
- dołącz supplier advisory, diff, commit albo wynik testu, jeśli jest dostępny
- zapisz claim i datę ważności jako supplier evidence
- po human review utwórz wersjonowany assessment successor
- utrzymaj oddzielnie VEX rationale oraz przesłanki Article 14
Praktyczny workflow: firmware → SBOM → CVE → VEX
- Product i konkretny Release
- Shipped Artifact z SHA-256
- jeden lub więcej SBOM z jawnym provenance
- Component occurrence i obserwacja CVE/OSV
- supplier/backport evidence
- human triage: AFFECTED, NOT_AFFECTED, UNDER_INVESTIGATION albo FIXED
- opcjonalny VEX z dokładnym rationale
- oddzielny Article 14 Reportability Review, jeżeli występuje sygnał możliwej eksploatacji lub incydentu
SBOM dla firmware — FAQ
Czy binary scan zastępuje SBOM z procesu build?
Nie zawsze. Binary analysis może ujawnić komponenty pominięte przez analizę repozytorium, ale może też nie odtworzyć pełnej tożsamości i konfiguracji. Zachowaj obie metody jako odrębne źródła z własnym zakresem i provenance.
Czy zgodny numer wersji dowodzi, że CVE występuje w firmware?
Nie. Dopasowanie wersji jest obserwacją do triage. Vendor fork, konfiguracja, nieosiągalny kod albo backport mogą zmienić wynik, ale wymagają udokumentowanej oceny dla konkretnego artefaktu.
Czy supplier backport automatycznie oznacza FIXED?
Nie. Oświadczenie dostawcy powinno zostać zachowane jako supplier evidence i zweryfikowane w zakresie dostępnym producentowi. Końcowy status jest decyzją człowieka z rationale i odpowiednim evidence.
Czy trzeba przesyłać firmware do CRA Workspace?
Nie. Workflow Artifact Provenance zapisuje metadane i SHA-256 finalnego artefaktu. Nie jest skanerem firmware i nie wykonuje ani nie rozpakowuje binariów.
Oficjalne źródła
Podstawa materiału została sprawdzona 2 września 2026.