Kiedy in-house software może być poza zakresem CRA?
Punktem wyjścia jest definicja udostępnienia na rynku: dostarczenie produktu z elementami cyfrowymi w celu dystrybucji lub używania na rynku UE w ramach działalności komercyjnej. Jeżeli oprogramowanie pozostaje wyłącznie narzędziem wewnętrznym jednej organizacji i nie jest dostarczane innym podmiotom, może nie dochodzić do udostępnienia produktu na rynku.
Nie należy jednak automatycznie traktować jako „in-house” rozwiązania przekazywanego odrębnej spółce z grupy, klientowi albo partnerowi. Znaczenie mogą mieć licencjonowanie, branding, odpłatna usługa, aplikacja instalowana przez użytkownika i niezbędne remote data processing. Każdy model wymaga osobnej oceny CRA scope.
Najpierw ustal model odpowiedzialności
- kto projektuje i kontroluje rozwój
- pod czyją nazwą lub znakiem produkt trafia na rynek
- kto decyduje o wydaniach i aktualizacjach
- kto prowadzi vulnerability intake i odpowiada użytkownikom
- czy usługa zdalna jest częścią funkcji produktu
Gdy każdy klient ma inną wersję
Jeden „produkt” nie zawsze oznacza jeden identyczny artefakt wdrożony u wszystkich klientów. Bank A może używać bazowego Release 5.1, Bank B — Release 5.3 z custom module, a Bank C — osobnego forka 5.2-custom. Każdy z tych targetów może mieć inny zestaw komponentów, podatności i poprawek.
Praktyczny łańcuch śledzenia to Customer Deployment → Release → SBOM → findings → remediation. Status podatności, backport, test poprawki i evidence zamknięcia powinny wskazywać dokładne wdrożenie klienta; nie należy przenosić ich automatycznie pomiędzy release'ami lub forkami.
Czy software house jest producentem CRA?
Wykonawca tworzący rozwiązanie na zamówienie nie zawsze jest producentem w rozumieniu CRA. Istotne jest, kto wprowadza albo udostępnia produkt pod własną nazwą lub znakiem i kto zleca jego zaprojektowanie lub rozwój. Umowa powinna jasno rozdzielać zadania, lecz nie zmienia automatycznie roli wynikającej z rzeczywistego modelu rynkowego.
Co warto włączyć do delivery
- threat modeling i risk assessment
- security requirements i kryteria akceptacji
- SAST, SCA, secret scanning oraz testy
- SBOM dla wydania
- proces poprawek i coordinated vulnerability disclosure
- pakiet dowodów do dokumentacji technicznej
GitLab nie musi być zastępowany
GitLab może pozostać źródłem kodu, pipeline'ów CI/CD, CycloneDX SBOM i security findings. CRA Workspace odbiera wybrane artefakty z pipeline'u i wiąże je z konkretnym produktem, customer deployment lub wariantem oraz release'em; źródłowe findings pozostają oddzielone od human triage, VEX, remediation i Article 14 Review.
Jeżeli korzystasz z GitLab Ultimate, nadal możesz używać jego dependency scanning, Vulnerability Report i security dashboards. CRA Workspace uzupełnia ten workflow o kontekst: który artefakt działa u którego klienta, której wersji dotyczy finding, gdzie zastosowano backport, jakie evidence zamyka remediation i jaka decyzja zapadła w osobnym Article 14 Review. Nie zastępuje repozytorium, pipeline'ów ani skanerów GitLaba.
Oficjalne źródła
Podstawa materiału została sprawdzona 5 września 2026.