Jeden produkt, trzy różne wdrożenia
Product X jest wspólnym punktem odniesienia, ale każdy klient może otrzymać inny artefakt, zakres komponentów i linię poprawek.
Jeden produkt nie oznacza jednego identycznego artefaktu
Product X może mieć wspólną nazwę, roadmapę i bazę kodu, a mimo to u Customer A działać jako Release 4.2, u Customer B jako Release 4.5 z custom API, a u Customer C jako Fork 4.3-custom. Ocena prowadzona wyłącznie na poziomie nazwy produktu zgubi różnice w komponentach, ekspozycji, poprawkach i rzeczywistym stanie wdrożenia.
Customer Deployment lub Variant jest tu operacyjnym kontekstem technicznym i dowodowym. Nie przesądza automatycznie, że powstał odrębny produkt w rozumieniu prawa ani kto pełni rolę producenta — te kwestie zależą od rzeczywistego modelu udostępnienia, marki, kontroli i zmian.
Najpierw zamroź dokładny target
| Poziom | Co identyfikuje | Dlaczego jest potrzebny |
|---|---|---|
| Product | wspólną rodzinę produktu i właściciela | porządkuje odpowiedzialność, roadmapę i bazową dokumentację |
| Customer Deployment / Variant | konkretnego klienta, środowisko i zakres customizacji | oddziela rzeczywisty deployment od pozostałych klientów |
| Immutable revision | bazowy release, moduły, interfejsy, custom patches i component overrides | zachowuje historyczny stan zamiast nadpisywać konfigurację |
| Release / shipped artifact | dokładną wersję, build i checksumę dostarczonego artefaktu | wiąże SBOM, testy, rollout i evidence z tym, co faktycznie wdrożono |
Który SBOM dotyczy którego klienta?
SBOM powinien wskazywać dokładny release lub niezmienną rewizję customer deployment. SBOM bazowego Product X nie opisuje automatycznie dodatkowego API u Customer B ani komponentów zastąpionych w forku Customer C.
Jeżeli organizacja wykorzystuje wspólny bazowy SBOM oraz różnice klientowskie, oba zakresy muszą mieć jawne pochodzenie i regułę złożenia. Bez tego nie można wiarygodnie odtworzyć składu wdrożonego artefaktu w danym momencie.
- Product i Customer Deployment Revision
- base Product Release i customer-specific build ID
- checksum dostarczonego artefaktu
- snapshot SBOM z datą, formatem i generatorem
- jawne component overrides, moduły i custom patches
Która podatność dotyczy której wersji?
CVE, OSV lub finding skanera jest obserwacją źródłową. Human triage powinien ocenić dokładny component occurrence w konkretnym release'ie albo wariancie, biorąc pod uwagę konfigurację, reachability, używaną funkcję, zabezpieczenia oraz dostępne dowody.
Wyniku AFFECTED, NOT_AFFECTED, FIXED lub UNDER_INVESTIGATION nie należy bez przeglądu kopiować z bazowego produktu do forka ani pomiędzy klientami. Różna wersja biblioteki, wyłączona funkcja lub dodatkowy interfejs mogą zmienić wynik i uzasadnienie.
Backport i remediation muszą wskazywać deployment
Backport zastosowany w forku Customer C nie naprawia automatycznie Release 4.2 u Customer A. Zachowaj upstream advisory, identyfikator CVE, bazową i docelową gałąź, commit lub patch ID, testy oraz dokładny build, do którego przeniesiono poprawkę.
Remediation Case powinien wskazywać dotknięty target, fixed release, zakres rollout i closure evidence osobno dla każdego deploymentu. Samo wydanie poprawki nie dowodzi jeszcze, że została udostępniona lub wdrożona u wszystkich klientów.
Czy zmiana klientowska wymaga substantial modification review?
Nie każda konfiguracja, integracja, custom API lub backport jest automatycznie istotną modyfikacją. CRA definiuje substantial modification jako zmianę po wprowadzeniu produktu na rynek, która wpływa na zgodność z zasadniczymi wymaganiami z części I załącznika I albo prowadzi do zmiany przewidzianego zastosowania produktu.
Zmiana funkcjonalna może wymagać osobnego review, jeżeli spełnia te kryteria. Aktualizacja bezpieczeństwa, której jedynym celem jest zmniejszenie ryzyka i która nie zmienia przewidzianego zastosowania, co do zasady nie powinna być traktowana jako istotna modyfikacja. Wynik trzeba udokumentować dla konkretnej zmiany, roli podmiotu oraz sposobu dalszego udostępnienia produktu na rynku.
- co dokładnie zmieniło się względem zatwierdzonego release'u
- czy zmiana wpływa na zgodność z wymaganiami bezpieczeństwa produktu
- czy zmienia przewidziane zastosowanie lub racjonalnie przewidywalne użycie
- kto wykonał zmianę i pod czyją nazwą produkt jest dalej udostępniany
- czy review obejmuje zmienioną część czy cały produkt
Model operacyjny dla software house'u on-prem
Software house może utrzymywać wspólny Product X i osobne, wersjonowane Customer Deployments bez kopiowania całej kartoteki produktu. Producent, wykonawca i klient powinni uzgodnić ownership release'ów, generowanie SBOM, monitoring podatności, testy backportów, dystrybucję poprawek i dostęp do evidence.
Umowa i narzędzie pomagają rozdzielić zadania, ale same nie zmieniają roli prawnej wynikającej z rzeczywistego modelu rynkowego. CRA Workspace zachowuje operacyjny kontekst i historię decyzji; nie wydaje opinii prawnej, oceny zgodności ani potwierdzenia zgodności z CRA.
Custom software releases i CRA — FAQ
Czy jeden SBOM może dotyczyć wszystkich klientów?
Tylko jeżeli wdrożony skład jest rzeczywiście identyczny i zakres został potwierdzony. Gdy klient ma inny release, moduł, bibliotekę, custom API albo patch, potrzebny jest snapshot lub jawny zestaw różnic przypisany do jego niezmiennej rewizji deploymentu.
Jak ustalić, która podatność dotyczy konkretnego klienta?
Powiąż finding z dokładnym component occurrence w Customer Deployment Revision i Product Release, a następnie wykonaj human triage w kontekście konfiguracji, reachability, używanej funkcji i evidence. Samo dopasowanie nazwy oraz wersji pakietu nie jest końcową decyzją.
Jak udokumentować backport w customer fork?
Wskaż CVE lub advisory, upstream fix, bazową i docelową gałąź, commit albo patch ID, testy oraz checksumę customer-specific buildu. Następnie zapisz ocenę FIXED lub inną decyzję dla tego targetu, nie dla całej rodziny produktu.
Czy remediation dla jednego klienta obejmuje pozostałe wdrożenia?
Nie automatycznie. Remediation powinno wskazywać target, fixed release, rollout oraz closure evidence. To, że poprawkę przygotowano lub wdrożono u jednego klienta, nie potwierdza stanu pozostałych deploymentów.
Czy custom API zawsze oznacza substantial modification?
Nie. Potrzebny jest osobny review tego, czy zmiana po wprowadzeniu produktu na rynek wpływa na zgodność z zasadniczymi wymaganiami bezpieczeństwa albo zmienia przewidziane zastosowanie. Nazwa zmiany ani sam fakt customizacji nie rozstrzygają wyniku.
Czy software house zawsze jest producentem CRA?
Nie. Znaczenie ma między innymi to, kto wprowadza lub udostępnia produkt pod własną nazwą lub znakiem, kto kontroluje rozwój i czy podmiot dokonuje istotnej modyfikacji produktu już udostępnionego na rynku. Trzeba ocenić rzeczywisty model, a nie tylko zapis umowy.
Oficjalne źródła
Podstawa materiału została sprawdzona 5 września 2026.