CRA due diligence dla komponentów stron trzecich
CRA wymaga od producenta due diligence odpowiedniego do rodzaju i poziomu ryzyka cyberbezpieczeństwa komponentu. Przykładowe działania z motywu 34 obejmują sprawdzenie właściwej oceny zgodności komponentu, historii aktualizacji bezpieczeństwa, publicznie zarejestrowanych podatności albo wykonanie dodatkowych testów.
Oświadczenie dostawcy może wspierać tę analizę, ale nie przenosi odpowiedzialności za końcowy produkt i nie potwierdza automatycznie jego zgodności.
Supplier ↔ component ↔ product linkage
Rejestr dostawców bez powiązania z konkretnymi komponentami nie pokazuje wpływu zmiany. Użyteczny model zaczyna się od istniejącego Product Inventory i Product Release, a następnie wskazuje dokładny component occurrence oraz dostawcę, który przekazał informację.
- Supplier — źródło komponentu i kontakty operacyjne
- Component occurrence — konkretna zależność i wersja ze snapshotu
- Product / Release — wydanie faktycznie korzystające z komponentu
- Evidence Request — dokładnie określona informacja potrzebna od dostawcy
- Evidence version — niezmienny plik lub odpowiedź z provenance
- Freshness — ocena zastosowania dla wskazanego targetu
Od dostawcy do vulnerability workflow
| Etap | Działanie | Granica |
|---|---|---|
| Register | zapisz dostawcę i security contact | profil nie kopiuje list produktów ani komponentów |
| Link | wskaż exact component occurrence w Product Release | free-text nie potwierdza tożsamości komponentu |
| Request | poproś o SBOM, VEX, wersję lub support period | zakres i odbiorca są wersjonowane |
| Przegląd | zachowaj odpowiedź w Evidence Vault | „Przyjęto do ewidencji” nie oznacza zatwierdzenia |
| Freshness | porównaj target i jawne daty | brakujące fakty pozostają UNDETERMINED |
| Handoff | przekaż zaakceptowane źródło do Vulnerability Intelligence | brak automatycznego triage lub Article 14 |
Support period komponentu jest wejściem, nie decyzją
Przy ustalaniu support period produktu producent może uwzględnić okresy wsparcia integrowanych komponentów stron trzecich zapewniających podstawowe funkcje. Informacja dostawcy powinna zachować źródło, zakres wersji i datę. Nie może automatycznie nadpisać decyzji o okresie wsparcia produktu.
Minimalny operating model dla supply chain security
- właściciel relacji z dostawcą i zastępstwo
- security contact oraz ścieżka eskalacji
- rejestr komponentów krytycznych dla funkcji produktu
- wersjonowane Supplier Evidence Requests
- accountless Supplier Portal z ograniczonym i wygasającym dostępem
- cykliczny review freshness po zmianie release'u albo komponentu
- połączenie z SBOM, CVE/OSV, VEX i Article 14 bez automatycznych konkluzji
CRA supply chain security — FAQ
Czy dostawca komponentu odpowiada za zgodność produktu końcowego?
Nie zastępuje odpowiedzialności producenta produktu końcowego. Producent powinien wykonać due diligence i ocenić komponent w kontekście swojego produktu, architektury, ryzyka i release'u.
Czy lista dostawców wystarcza do zarządzania ryzykiem łańcucha dostaw?
Nie. Potrzebne jest jawne powiązanie dostawcy z konkretną wersją komponentu oraz produktami i release'ami, które z niej korzystają. Inaczej nie da się rzetelnie ocenić wpływu zmiany lub podatności.
Czy VEX dostawcy może automatycznie zamknąć CVE?
Nie. VEX dostawcy jest źródłowym stanowiskiem. Producent powinien zachować jego provenance i przeprowadzić własny human triage w kontekście konkretnego wydania produktu.
Co oznacza supplier evidence freshness?
To wynik sprawdzenia, czy konkretna wersja dokumentu nadal odnosi się do dokładnego komponentu, wersji, produktu i release'u oraz czy nie minęła jawnie podana data ważności. Brak danych powinien dawać REVIEW_REQUIRED lub UNDETERMINED.
Czy ACCEPTED_FOR_RECORD oznacza akceptację dostawcy?
Nie. Oznacza wyłącznie, że wskazany materiał został przyjęty do rejestru po review dla określonego targetu. Nie potwierdza tożsamości dostawcy, autentyczności dokumentu, bezpieczeństwa komponentu ani CRA compliance.
Oficjalne źródła
Podstawa materiału została sprawdzona 1 września 2026.