Product Capabilities & Technical Architecture | CRA Direct

1. Purpose

CRA Direct helps manufacturers of products with digital elements run the operational side of EU Cyber Resilience Act compliance: product registration, SBOM evidence collection, vulnerability triage, human review, Single Reporting Platform submissions, and audit evidence.

The product follows a straightforward principle: automation can prepare, prioritise, validate, remind, and submit, but legally meaningful decisions stay under human control and are preserved in an audit trail. Compliance evidence is treated as a regulated system of record — SBOMs, decisions, notifications, and audit events are linked, retained, and independently verifiable.

2. Primary Users And Authentication

CRA Direct uses Zitadel for single sign-on. User roles map directly to platform permissions:

• Security and compliance reviewers triage vulnerabilities, record VEX evidence, prepare SRP drafts, and request approval.
• Approvers review finalized evidence and payloads before submission to the SRP.
• Auditors inspect read-only evidence, audit logs, and submission history.
• Organization administrators manage service keys, products, SBOM evidence, and workspace settings.
• Platform super-admins onboard organizations and monitor tenant status across the platform.

This keeps responsibilities separate — the people who prepare evidence are different from those who approve it, which strengthens accountability for regulated reporting.

3. Workspace And Organization Management

Organization Workspace

Each organization gets its own workspace containing products, SBOMs, vulnerability findings, review cases, SRP workflows, notifications, and audit evidence. Legal hold status is visible on organization and workspace views so teams know when evidence must be preserved regardless of normal retention policies.

During onboarding, the platform can auto-provision Zitadel accounts for compliance and security contacts, assigning appropriate roles without manual identity provider configuration.

Organization Profile

The profile stores the business and regulatory data used in submissions: legal name, entity type, registration number, country, registered address, compliance and security contacts, vulnerability disclosure policy URL, main-establishment Member State for Article 14(7) routing, and SBOM retention policy. Incomplete routing information is flagged because missing main-establishment data can block SRP readiness.

Platform Administration

Super-admins can onboard organizations through a guided flow, review tenant product counts and registration status, edit organization profiles, and navigate from onboarding directly to first product registration.

4. Dashboard And Work Prioritisation

The Overview dashboard gives teams a single view of product coverage, SBOM volume, open vulnerabilities, pending reviews, upcoming deadlines, and readiness gaps. It highlights the next action — whether that is reviewing overdue cases, triaging critical vulnerabilities, completing onboarding, or uploading SBOM evidence.

Deadline awareness is built into every view, not stored in a separate calendar. CRA clocks for 24-hour early warnings, 72-hour notifications, final reports, intermediate reports, and dissemination-delay requests appear directly in queues, dashboard cards, and workflow pages. Teams see what is overdue, what needs action, and what is coming due without manual tracking.

5. Product Registry

Products are the foundation for all downstream evidence and reporting. Teams register product name, CRA category (standard, important, or critical), security contact, support period, versioning scheme, CE marking status, and vulnerability disclosure policy. Only registered active product versions can receive SBOM evidence; deprecated and end-of-life versions remain visible for audit history.

Product detail pages bring together metadata, versions, context documents, SBOM evidence sets, related SRP submissions, and audit history in one place.

6. Product Context Documents

Teams can upload supporting documents — security architecture, threat models, user manuals, release notes, test reports — to help reviewers and AI analysis understand the product. Documents can apply to all versions or a specific version. Archived documents remain in history but are removed from future analysis. Original files are retained in object storage and available through secure download links.

7. SBOM Evidence And Component Inventory

The SBOM Library accepts CycloneDX (1.4–1.7) and SPDX (2.2, 2.3, 3.0.1) uploads for registered product versions. The API validates files, computes content hashes, archives raw evidence to S3-compatible storage, and locks the evidence set so it can serve as auditable CRA evidence. Duplicate files, format mismatches, and version conflicts are caught during upload.

The library shows evidence status (locked, analyzed, draft, running, failed), baseline and delta scans, component counts, and review handoffs. Component inventory pages connect SBOM files to specific packages and vulnerabilities, with evidence hashes for audit traceability.

Stateless Scanning API

CRA Direct also exposes stateless endpoints that let external tools and CI pipelines evaluate SBOMs without persisting data:

• POST /scan-sbom — accepts a CycloneDX or SPDX SBOM and returns vulnerability findings without creating evidence records.
• POST /scan-purls — accepts up to 500 PURLs and returns matched vulnerability findings.
• POST /triage-stateless — accepts product context and vulnerability findings, returns an AI-assisted triage report.

These are designed for pre-ingest evaluation, CI gating, and external scanner integration without coupling to the platform's evidence lifecycle.

8. Vulnerability Intelligence And Monitoring

Rather than relying on a single third-party scanner, CRA Direct sources vulnerability data directly from authoritative feeds and performs its own component-to-vulnerability matching. This avoids tying the compliance evidence pipeline to any one vendor's data model or update cadence.

Supported intelligence sources:

• OSV — primary vulnerability database via bulk sync and live API lookup
• CISA Known Exploited Vulnerabilities — full catalog with diff-based sync
• FIRST EPSS — exploit prediction scoring
• ENISA EUVD — CVE-to-EUVD mapping

The system runs full baseline scans on locked SBOM sets and impact deltas when new intelligence changes the risk profile of known components. Each intelligence change creates an append-only impact event for audit traceability.

9. AI-Assisted CRA Analysis

Analysis jobs process locked SBOM evidence, vulnerability intelligence, and product context. Results include a bundle-level decision (report candidate, monitor, VEX review, or manual triage), per-vulnerability verdicts with rationale, active exploitation evidence, missing evidence prompts, and recommended next actions.

AI output is draft support only. No-report and not-affected outcomes require human evidence and a final reviewer decision. AI-generated content is validated against the underlying evidence before it reaches a reviewer, and the system falls back to deterministic processing when the model call fails.

10. Vulnerability Triage And VEX Evidence

Reviewers can record VEX evidence with product-specific justifications — not affected, affected, fixed, or under investigation — along with impact statements, action statements, and CSAF-style justifications. The review flow can generate candidate VEX artifacts for approval, and final VEX decisions are locked into the audit history.

11. Human Review Workbench

The Review Workbench organises cases by type: SRP stage submissions, VEX triage, intermediate reports, dissemination-delay requests, and external actions. Behind it is an explicit state machine that moves cases through controlled stages — open, in review, draft generated, submitted for approval, changes requested, rejected, approved, submitted, closed, or archived — depending on case type.

This ensures reviewer and approver responsibilities stay separate, every transition is recorded as audit evidence, and AI output remains a draft until a human completes the relevant workflow step.

12. SRP Submission Workflows

CRA Direct manages Article 14 reporting for both actively exploited vulnerabilities and severe incidents. Vulnerability workflows can start from scanner/AI/VEX analysis or from direct manual intake.

Vulnerability Workflow

• 24-hour early warning under Article 14(2)(a)
• 72-hour notification under Article 14(2)(b)
• Final report under Article 14(2)(c), submitted after a corrective or mitigating measure is available (within 14 days)
• Supplier and maintainer notification tracking for third-party components
• Manual intake for known exploited vulnerabilities

A stuck-mitigation monitor detects when a fix has been available for 14 days without a submitted final report and escalates the workflow so the obligation does not silently expire.

Severe Incident Workflow

• 24-hour early warning under Article 14(4)(a)
• 72-hour notification under Article 14(4)(b)
• Final incident report under Article 14(4)(c), within one month

Two severity criteria sets are supported: SECURITY_IMPACT (active exploitation, loss of confidentiality/integrity/availability) and MALICIOUS_CODE (suspected intentional malicious code, supply-chain compromise indicators).

Workflow pages show stage status across 24h/72h/final submissions, reporting Member State, SRP tracking IDs, user and supplier notification status, and manual attention flags for failed stages.

13. Manual Intake

When a manufacturer already knows a vulnerability is actively exploited and has product-specific evidence, the manual intake flow creates a CRA Article 14(2) workflow without waiting for SBOM analysis upstream. Users capture affected product and version, vulnerability identifiers, awareness time, severity, active exploitation evidence, VEX affectedness verdicts, and market scope.

The same flow exists for severe incidents. During incident review, AI draft assistance can prefill stage content from intake facts, but reviewers still validate and approve the final payload.

14. Intermediate Reports And Dissemination Delay

Intermediate reports let teams respond to CSIRT coordinator requests under Article 14(6) without modifying the core 24h/72h/final obligations. Users register a request from the workflow detail page, which opens a dedicated review case and submits the approved update to the SRP intermediate endpoint.

Dissemination-delay requests capture delay grounds, risk rationale, requested delay window, and disclosure plans. Delay data is included directly in the SRP payload.

15. Activity And Notifications

The Activity Feed gives teams a chronological view of workspace changes — scan completions, triage handoffs, review due dates, approval requests, and SRP outcomes — without entering each workflow.

The Notification Center delivers alerts via email, SMS, Slack, and Teams. Notifications are persisted in the database and processed by a dedicated worker, so failures are visible and retryable rather than silently lost. Deadline reminders follow an escalation cadence (24 hours, 4 hours, 1 hour, 15 minutes before, and at the deadline itself), with deduplication by idempotency key and capped counts to prevent runaway alerts.

16. Service Keys For Automation

Teams can create organisation-scoped API keys for CI pipelines, scanner integrations, and workflow automation. Keys support configurable expiration (30 days, 90 days, 1 year, or no expiration), last-used tracking, and immediate revocation. Three permission scopes are available:

• sbom:ingest — SBOM evidence upload
• stateless:analyze — stateless scanning and triage
• workflow:create — CRA workflow and intermediate report creation

17. Audit Trail And Evidence Integrity

Every significant action — AI analysis, human decision, workflow transition, notification, and SRP submission — is recorded. Audit entries are hash-chained, so exported evidence can be verified for tampering. Stored files are served through short-lived secure URLs rather than exposing bucket credentials. Organisation-scoped data is enforced by PostgreSQL Row-Level Security on all tenant tables.

18. Technical Choices At A Glance

CRA Direct is built as a compliance evidence platform rather than just a workflow interface. Key design decisions include:

• Backend-owned ingestion — the API handles SBOM validation, archival, and evidence locking; the browser is a thin upload surface.
• Immutable baselines — each SBOM set is locked to a product version; later intelligence updates create separate delta analyses.
• Scanner-agnostic — vulnerability data comes from OSV, KEV, EPSS, and EUVD rather than a single embedded scanner; external tools integrate via standard CycloneDX or SPDX SBOMs.
• Durable workers — vulnerability sync, scanning, reporting, and notifications run as background workers with retries and dead-letter handling.
• Tenant isolation — organisation data is separated by PostgreSQL Row-Level Security, organisation-bound service keys, and role-based audit visibility.
• AI with guardrails — draft content is validated against evidence before reaching reviewers; unsupported claims are caught automatically and invalid model output falls back to deterministic processing.
• SSO via Zitadel — with Auth.js integration, role mapping, and optional auto-provisioning during onboarding.

19. Current Product Boundaries

• Article 14 SRP reporting is the primary regulated workflow.
• End-user notification status is tracked, but CSAF 2.0 publication is not yet integrated.
• CVSS, EPSS, and severity are prioritisation signals, not standalone Article 14 triggers.
• Product versions must be registered before SBOM upload — ad hoc names are not accepted for locked evidence.
• Final vulnerability reporting starts when a corrective measure is available, not automatically after the 72-hour notification.
• AI output is always draft or decision support until a human records the final business decision.

20. Business Value

• Deadline control — Article 14 clocks are visible across 24h, 72h, final, intermediate, and delay workflows, with reminders that keep the right people informed.
• Lower triage burden — focuses attention on actively exploited and product-relevant vulnerabilities while keeping severity-only noise in monitor paths.
• Connected evidence — links products, versions, SBOMs, VEX decisions, SRP payloads, and audit events in one place.
• Clear accountability — separates reviewer and approver responsibilities and preserves every decision as audit evidence.
• Portfolio visibility — gives security and compliance leaders a single view of risk, readiness, and reporting status.
• Audit confidence — evidence can be exported and verified independently without reconstructing events from email or spreadsheets.