CRA WORKSPACE • PRODUCT SECURITY OPERATIONS

Od zgłoszenia bezpieczeństwa do decyzji per release

Zapisz customer report lub sygnał z GitLab, badacza, dostawcy czy monitoringu. Przypisz go do produktu, wdrożenia i release'u, przeprowadź human triage, a po decyzji Article 14 kontroluj własny deadline, odpowiedzialnego AR i evidence ręcznej wysyłki do SRP.

✓ Tenant isolation✓ Human decisions, nie automatyczny compliance score✓ Security Intake z immutable history
INTERAKTYWNY SCENARIUSZ • DANE SYNTETYCZNE

Jeden produkt. Dwa wdrożenia. Dwie niezależne decyzje.

Przejdź pięć kroków dla fikcyjnego Product X. Demo pokazuje model pracy — nie wykonuje skanowania, nie ocenia zgodności i nie zapisuje danych w Twoim Workspace.

DEMO • NIE SĄ TO DANE KLIENTÓW
Product XProduct → Customer Deployment → Release → SBOM → Vulnerability → Evidence
Klient ARelease 5.1Wdrożenie A · rewizja 1

Standardowy artefakt on-prem

Wersja wdrożona u tego klienta jest osobnym kontekstem. Jeden produkt nie oznacza jednego identycznego artefaktu.

Klient BRelease 5.3-customWdrożenie B · rewizja 3

Osobny artefakt z custom API

Wersja wdrożona u tego klienta jest osobnym kontekstem. Jeden produkt nie oznacza jednego identycznego artefaktu.

REMEDIATION & UPDATE ROLLOUT

Od human triage do dowodu wdrożenia poprawki

Workspace łączy ocenę AFFECTED z planem naprawy, konkretnym fixed release'em, ręcznie udokumentowanym rolloutem i evidence zamknięcia. Article 14 pozostaje odrębnym przeglądem przesłanek.

01CVE / findingsygnał źródłowy
02Human triageAFFECTED
03Remediation Caseowner i deadline
04Target Releaseplanowana poprawka
05Fixed Releasewydanie z poprawką
06Update Rolloutkanał i postęp
07Evidenceźródła i załączniki
08Closurehuman approval
09Article 14osobny review
Szczegóły modułów i granice operacyjne35 capabilities, GitLab, warianty klientów, SRP, Supplier Evidence i prywatne eksporty
SRP SUBMISSION CONTROL

Kontroluj rzeczywisty zegar Article 14 i dowody wysyłki

Po jawnej decyzji Article 14 typu „required” Workspace zamraża awareness timestamp i liczy własne terminy 24h oraz 72h. Wartość widoczną w interfejsie SRP zapisuje osobno, dzięki czemu rozbieżność nie ukrywa prawnego deadline'u.

Każdy etap łączy odpowiedzialnego Primary lub Secondary AR, stan case'u, faktyczny submission timestamp, SRP Notification ID, status manual dissemination oraz screenshot albo PDF potwierdzenia. Draft jest prywatny dla przypisanego autora, a po pierwszym submission case staje się wspólny dla Primary i Secondary AR danego producenta. Handover Timeline pokazuje, kto wysłał Early Warning, kto przejął 72h i kto wysłał Final Report.

Status „Gotowe” wymaga kompletnego packa, a Workspace zapisuje niezmienny snapshot formularza ENISA v1.4 i jego SHA-256. Macierz rozróżnia moment awareness i occurrence, obejmuje informacje o dostępnej poprawce oraz notatkę AR; pole CSIRT pozostaje po stronie CSIRT. Historyczne snapshoty zachowują wcześniejszy profil. Zatwierdzona decyzja PEC jest zapisywana osobno w pierwszym oknie 72h, a Final Report zamraża rekord regulacyjny. Wysłanie pozostaje ręczne w oficjalnym SRP ENISA. Późniejsze remediation i rollout nie nadpisują historycznego Final Report.

CRA SRP — konta, role, terminy i aktualne zasady ENISA →

  • Legal clock24h i 72h od jawnego awareness timestamp
  • Counter divergencealarm, gdy licznik zapisany z SRP różni się od terminu prawnego
  • AR collaborationprywatny draft, wspólne submitted case'y i handover między Primary oraz Secondary
  • Pending associationlicznik wykorzystania limitu 20 zgłoszeń przed weryfikacją
  • Case State MachineDraft → EW → 72h → Final Report → Locked
  • PEC + disseminationdecyzja, approval, evidence, flaga SRP i manualny status CDaC
  • Form snapshotdokładne pola i copy text zaakceptowane dla etapu, wersja packa oraz SHA-256
  • Evidence packtimestamp, SRP reference, screenshot/PDF, SHA-256 i immutable audit
LEGACY PRODUCT DECISION

Zapisz strategię dla starego produktu bez automatycznej rekomendacji

Product Inventory łączy stan rynku UE, lifecycle, możliwości supportu, utrzymywalność firmware lub source, SBOM, update mechanism, krytyczne luki oraz dokładne aktywne releases i deployment revisions.

Strategię wybiera człowiek, a niezależny reviewer może oznaczyć ją wyłącznie jako ACCEPTED_FOR_RECORD. Workspace nie oblicza, czy modernizacja się opłaca, nie rekomenduje wycofania produktu i nie stwierdza zgodności z CRA.

CRA a produkty wprowadzone przed 11 września 2026 →

  • Exact scopeProduct, active releases i dokładne customer deployment revisions
  • Human strategyremediate, feature reduction review, maintenance, replace albo EU market exit review
  • Change controlfeature reduction wymaga powiązanego Change Assessment
  • EvidenceRequirement Board, Evidence Vault, owner i rationale
  • Immutable historykolejne wersje i obowiązkowe four-eyes bez usuwania wcześniejszego zapisu
GITLAB SBOM PIPELINE

Od repozytorium GitLab do SBOM przypisanego do release'u

Connector tworzy zamkniętą konfigurację pipeline'u dla wybranego profilu, a GitLab CI generuje CycloneDX lub SPDX i przesyła artefakt do Workspace. Import wiąże pochodzenie pipeline'u z dokładnym produktem, wariantem klienta i release'em bez udostępniania Workspace dostępu do kodu repozytorium.

GitLab SBOM dla CRA — od CI/CD do human triage →

  • Tag-only pipelinejawny moment wydania i dokładny commit SHA
  • CycloneDX / SPDXwersjonowany artefakt z generatorem i checksumą
  • Exact targetProduct, Customer Variant i Product Release
  • Push-based importbez GitLab PAT/OAuth i pobierania repozytorium przez Workspace
  • Human triagefinding pozostaje obserwacją, nie decyzją o wpływie lub zgodności
SECURITY INTAKE

Jedna kolejka dla zgłoszeń klientów i sygnałów technicznych

Rejestruj informacje pochodzące od klienta, z GitLab, od badacza, dostawcy, zespołu internal security lub monitoringu. Określ typ VULNERABILITY, INCIDENT albo SUSPECTED INCIDENT i zachowaj źródłowe evidence bez tworzenia automatycznej konkluzji.

Każdy rekord ma ownera, dokładny Product scope, opcjonalny Customer Deployment i Product Release oraz niezmienną historię etapów: RECEIVED → UNDER REVIEW → TRIAGED → ROUTED lub CLOSED.

  • Sourcecustomer, GitLab, researcher, supplier, internal security lub monitoring
  • Exact scopeprodukt, opcjonalna rewizja wdrożenia i odpowiadający jej release
  • Evidencedokładna wersja rekordu z istniejącego Evidence Vault
  • Human triagebez automatycznego severity, CVE, statusu AFFECTED lub kwalifikacji incydentu
  • Controlled routingdo istniejącego vulnerability assessment albo Article 14 Review
CUSTOMER DEPLOYMENTS & PRODUCT VARIANTS

Rozdziel warianty klienta bez kopiowania produktu

Product → Customer Deployment → immutable revision → Product Release → SBOM/components → human vulnerability assessment. Każda rewizja zachowuje dokładną konfigurację i źródła, a istniejące Product Inventory, Evidence Vault, RBAC i audit pozostają wspólnym źródłem prawdy.

CRA dla custom software — wersje, forki i wdrożenia klientów →

Rekord wdrożenia klienta i operacyjna ocena bezpieczeństwa. Dane konfiguracji wymagają przeglądu człowieka. Rekord nie jest opinią prawną, oceną zgodności, certyfikacją, gwarancją bezpieczeństwa ani deklaracją zgodności z CRA.

  • Customer Deploymentprywatny wariant wdrożenia wewnątrz tenantu producenta
  • Immutable revisionbase release, moduły, interfejsy, custom patches i component overrides
  • Exact compositionpowiązanie z dokładnym SBOM i komponentami wybranej rewizji
  • Human assessmentnie dziedziczy automatycznie statusu z bazowego release'u ani innego wdrożenia
  • Downstream scopeVEX, remediation, Product Risk, Evidence Packs i Article 14 source facts
W WORKSPACE

Jeden system dla pracy przed i po release

Istniejące Product Inventory, Evidence Vault, RBAC, audit i Article 14 pozostają wspólnym źródłem prawdy. Vulnerability Intelligence rozszerza ten sam Workspace — nie tworzy równoległego systemu. Dostępność automatyzacji i modułów zaawansowanych zależy od planu.

01

Product Inventory

Produkty, role, scope, klasyfikacja, support period i właściciele.

02

Product Releases

Niezmienne wydania, statusy, supersession i historia produktu.

03

Customer Deployments

Prywatne warianty wdrożeń klientów powiązane z istniejącym produktem i dokładnym Product Release.

04

Immutable configuration revisions

Niezmienna historia modułów, interfejsów, custom patches i component overrides bez nadpisywania poprzedniego stanu.

05

Deployment-scoped vulnerability context

Osobny human assessment dla dokładnej rewizji wdrożenia, bez automatycznego dziedziczenia decyzji z bazowego release'u.

06

SBOM snapshots

Import CycloneDX lub SPDX i powiązanie snapshotu z release'em albo dokładną rewizją wdrożenia.

07

Component Inventory

Znormalizowane komponenty, identyfikatory, relacje i różnice snapshotów.

08

Vulnerability sources

Import obserwacji z CycloneDX, Trivy, Snyk i Dependency-Track oraz opcjonalne OSV.

09

Security Intake

Zgłoszenia customer, GitLab, researcher, supplier, internal security lub monitoring przypisane do produktu, release'u i opcjonalnie rewizji wdrożenia.

10

Human triage

Wersjonowana kwalifikacja i routing bez automatycznego potwierdzania podatności, incydentu lub obowiązku raportowania.

11

VEX workflow

Wersjonowane stanowisko powiązane z assessmentem i wydaniem produktu.

12

Article 14 Review + SRP Pack

Odrębna ocena triggera oraz copy-ready pola 24h, 72h i Final Report bez automatycznego zgłoszenia.

13

Requirement Board

Wymagania, ownerzy, terminy, blokady i jawne decyzje użytkownika.

14

Evidence Vault

Prywatne źródła, dokumenty, checksum, lineage, retencja i pobrania.

15

Regulatory Monitor

Zweryfikowane aktualizacje źródeł bez automatycznych wniosków o wpływie na produkt.

16

Authorised Representative

Mandaty, coverage, dokumenty i authority requests w istniejącej architekturze Workspace.

17

Roles & permissions

Tenantowy RBAC, resource scope, share grants i niezależne zatwierdzenia.

18

Audit trail

Historia zmian, wersji, decyzji i prób dostępu bez nadpisywania zdarzeń.

19

Private exports

Kontrolowane paczki danych i evidence z ponowną autoryzacją pobrania.

20

Supplier Evidence Requests

Wersjonowane żądania danych i dokumentów dla konkretnego dostawcy, produktu, release'u lub komponentu.

21

Supplier Portal

Ograniczony dostęp do jednego requestu bez konta w Workspace i bez wglądu w pozostałe dane organizacji.

22

SBOM / VEX / support-period requests

Gotowe requesty do dostawców: SBOM, VEX, wersja komponentu, support period i polityki bezpieczeństwa.

23

Supplier evidence freshness

Konserwatywna ocena aktualności dla dokładnej wersji evidence i wskazanego targetu.

24

Component ↔ supplier ↔ product linkage

Jawne relacje z istniejącym Product Inventory, Product Releases i component occurrences.

25

Shipped Artifact provenance

SHA-256, build ID, firmware version, target, BSP i RTOS dla dokładnego Product Release — bez uploadu lub wykonywania firmware.

26

Artifact ↔ SBOM linkage

Wiele źródeł SBOM z jawną metodą, narzędziem i claimed completeness dla konkretnego artefaktu.

27

Supplier backport evidence

Wersjonowane źródła o vendor fork i backportach CVE, które nie zmieniają automatycznie human triage.

28

Remediation Cases

Remediation plan, owner, deadline i jawne powiązanie z dokładną wersją vulnerability assessment.

29

Fixed Release Tracking

Wskazanie target release oraz konkretnego Product Release zawierającego poprawkę.

30

Update Rollout & Evidence

Ręczne śledzenie wdrożenia poprawki, rollout progress i evidence zamknięcia bez telemetryki urządzeń.

31

SRP Submission Pack

Mapowanie pól ENISA z oznaczeniem REQUIRED / OPTIONAL / CONDITIONAL / AUTO i ręcznym transferem do SRP.

32

SRP Role Readiness

Primary i Secondary Assigned Representatives, osobisty EU Login, 2FA, CSIRT oraz gotowość datasetu producenta.

33

Audience-scoped Evidence Packs

Engineering, Product Security, Compliance, Management i Authority Pack z dokładnie wybranych rekordów Workspace.

34

Legacy Product Decisions

Wersjonowana strategia REMEDIATE, FEATURE REDUCTION, MAINTENANCE, REPLACE lub EU MARKET EXIT REVIEW z exact scope i four-eyes.

35

SRP Submission Control

Article 14 Case State Machine, własny legal deadline, mirror uprawnień AR, P0 PEC, dissemination, submission evidence i blokada po Final Report.

EVIDENCE PACKS

Udostępnij właściwy zakres właściwej osobie

Wybierasz konkretne rekordy i zakres. Workspace tworzy prywatny, niezmienny manifest ze źródłami, wersjami i checksumami — bez ujawniania całego Workspace i bez automatycznej oceny zgodności.

ENGINEERING

Engineering Pack

Release, SBOM, komponenty, CVE, affected assessments i remediation dla dokładnego wydania.

PRODUCT SECURITY

Product Security Pack

Podatności, VEX, firmware provenance, ryzyka i status remediation bez wewnętrznych notatek.

COMPLIANCE

Compliance Pack

Wymagania CRA, evidence, supplier records, support period, VEX, Article 14 decisions i bezpieczny audit trail.

MANAGEMENT

Management Pack

Produkty wymagające uwagi, krytyczne podatności, zaległe remediation, otwarte Article 14 reviews i supplier gaps — bez arbitralnego score.

AUTHORITY

Authority Pack

Dokładnie wybrany zakres jednej authority request, prywatny immutable export i obowiązkowe four-eyes przed pobraniem.

REMEDIATION & UPDATE ROLLOUT

Połącz podatność z poprawką i dowodem jej wdrożenia

Workspace pozwala udokumentować proces remediation i dystrybucji aktualizacji oraz zachować evidence działań podejmowanych w cyklu vulnerability handling. Rollout progress pozostaje ręcznie zapisanym twierdzeniem źródłowym, dopóki dołączone evidence nie stanowi inaczej.

Jak udokumentować remediation i update rollout w CRA →

  • Remediation Caseassessment, owner, deadline i wersjonowany plan
  • Fixed Releasetarget oraz konkretne wydanie zawierające poprawkę
  • Update Rolloutkanał, populacja docelowa i ręcznie zapisany postęp
  • Closure EvidenceEvidence Vault, historia i niezależna decyzja człowieka
  • Article 14odrębny review, bez automatycznego zgłoszenia
FIRMWARE ARTIFACT PROVENANCE

Połącz SBOM z tym, co faktycznie zostało wydane

Workspace zapisuje SHA-256 i metadane shipped artifact dla konkretnego Product Release, wiąże z nim jedno lub więcej źródeł SBOM oraz zachowuje supplier evidence o vendor fork i backporcie. Firmware nie jest przesyłany, uruchamiany ani skanowany przez Workspace.

SBOM dla firmware, binary blobs, BSP/RTOS i backporty CVE →

  • Artifactfilename, build ID i SHA-256 dla dokładnego release'u
  • SBOM provenancebuild, supplier lub binary-analysis import z jawnym zakresem
  • Patch evidencesupplier claim i dowód źródłowy, nie automatyczny FIXED
  • Human decisionwersjonowany assessment i istniejące four-eyes
SUPPLIER EVIDENCE WORKFLOW

Od dostawcy i komponentu do aktualnego evidence

Supplier Evidence nie jest równoległym inventory. Workspace wiąże dostawcę z istniejącym component occurrence, Product Release i produktem, wysyła ograniczony request, zapisuje odpowiedź w Evidence Vault i ocenia freshness dla dokładnego targetu.

Jakie supplier evidence zbierać w CRA →

Jak pozyskiwać SBOM od dostawców →

CRA a bezpieczeństwo łańcucha dostaw →

  • RequestSBOM, VEX, component version, support period lub polityka security
  • Portaljeden wygasający dostęp bez konta Workspace
  • ReviewACCEPTED_FOR_RECORD, nie approval ani conformity assessment
  • Freshnessbrak wersji lub targetu pozostaje UNDETERMINED
  • Handoffjawne przekazanie do istniejącego workflow SBOM / VEX
SOURCE ≠ DECISION

Źródło podatności nie podejmuje decyzji za użytkownika

Wynik OSV, CVE albo skanera jest obserwacją źródłową. Ocena wpływu na produkt, status VEX i dalsze działania wymagają human triage w kontekście konkretnego release'u.

Zobacz praktyczny przewodnik po CRA Vulnerability Intelligence →

  • Importnie uruchamia repozytorium ani własnego skanera
  • AFFECTEDnie tworzy automatycznie deadline'u Article 14
  • VEXnie jest opinią prawną ani conformity assessment
MIESIĘCZNY TRIAL • ROCZNIE Z GÓRY

Self-service albo automatyzacja dla zespołu

Starter obejmuje manualną pracę self-service. Team dodaje GitLab/SBOM automation, supplier workflow, zaawansowane role i eksporty. Wariant miesięczny ma 14-dniowy trial z metodą płatności i potem odnawia się co miesiąc. Wariant roczny, jeżeli dostępny w formularzu, jest płatny z góry bez trialu i odnawia się co 12 miesięcy do anulowania.

TEAM

Team

Do 25 produktów • 50 aktywnych wdrożeń • do 10 użytkowników

GitLab/SBOM automation, collaboration i zaawansowane workflow.
  • ✓ wszystko ze Starter
  • ✓ do 50 aktywnych Customer Deployments
  • ✓ GitLab integration i automatyczny import SBOM z CI/CD
  • ✓ Supplier Evidence Requests i accountless Supplier Portal
  • ✓ Product Cyber Risk Register per release
  • ✓ 5 audience-scoped Evidence Packs z prywatnym immutable manifestem
  • ✓ zaawansowane role i collaboration
  • ✓ priority support
SUBSKRYPCJA B2B1490 zł netto / mies.

VAT zostanie obliczony w checkout zgodnie z danymi nabywcy. Płatność obsługuje Stripe.

Cykl rozliczeniowy
  • Kwota i produkt są weryfikowane po stronie serwera.
  • Dostęp uruchamia potwierdzony webhook płatności.
  • Nie przechowujemy danych karty.
BUSINESS

Business

Wycena indywidualna

Dla portfolio przekraczających 50 aktywnych wdrożeń oraz organizacji wymagających indywidualnej infrastruktury lub integracji. Dostępność każdego elementu jest potwierdzana przed uruchomieniem:

  • ✓ indywidualne limity produktów, wdrożeń i użytkowników
  • ○ private / on-prem, jeśli uzgodnione
  • ○ SSO, API i custom integrations, jeśli uzgodnione
  • ○ partner / external access i rozszerzony RBAC
  • ○ indywidualne wdrożenie, wsparcie i SLA
Porozmawiaj z namiZakres, dostępność i warunki wymagają pisemnego potwierdzenia przed rozpoczęciem współpracy.

Produkt oznacza wspólną rodzinę zarządzaną jako jeden produkt bazowy. Release, fork lub customer-specific variant nie jest automatycznie kolejnym produktem. Customer Deployment to aktywnie zarządzana instancja lub wariant przypisany do klienta albo środowiska, z osobną konfiguracją, release'em, SBOM lub historią bezpieczeństwa. Liczby release'ów nie limitujemy dziś sztucznie; obowiązują rozsądne zasady korzystania i techniczne limity bezpieczeństwa.

GRANICE PRODUKTU

Operacyjny Workspace, nie automatyczna ocena zgodności

Workspace porządkuje dane, decyzje i evidence. Nie potwierdza prawdziwości wprowadzonych informacji, nie wyznacza wiążąco zakresu lub klasyfikacji i nie zastępuje oceny technicznej, prawnej ani conformity assessment.

  • Nie pokazujelegal compliance %
  • Nie deklarujeCRA compliant ani legally approved
  • Partner referraljest opcjonalny i poza standardowym fulfillmentem