Platform
The operational system behind CRA readiness.
Vellaci is organised around one graph: Organisation → Product → Version → Release → SBOM → Component → Vulnerability → Assessment → Remediation → Incident → CRA Notification → Evidence. Every screen is a view over that graph, and every record connects back to a product that is on the EU market.
Overview
Is anything urgent? Which products are exposed? Are CRA deadlines running? What needs attention and what evidence is missing — every card clicks through to the underlying data.
Products & versions
A first-class registry with lifecycle states, classification reasoning, owners, support periods and immutable version history.
Components
A deduplicated catalogue across all SBOMs with product usage, dependency relationships, licences and exposure counts.
Vulnerabilities
Triage with mandatory reasons, remediation ownership, VEX states and a CRA review that asks the Article 14 question explicitly.
Incidents
Separate records for exploitation, compromised devices, update-infrastructure compromise and more — with confirmed awareness timestamps.
CRA Reporting
The command center: deadline clocks, staged forms, prefilled facts, submission-ready summaries, submission records and evidence packages.
Evidence
Private, checksummed files and links tied to products, requirements, vulnerabilities, incidents and cases, with review dates and legal hold.
Readiness, tasks, reports
A weighted requirement framework, remediation tasks, and executive-ready PDF/CSV/ZIP reports containing source data and dates.
Team & audit log
Seven server-enforced roles, invitations, configurable external-advisor access, and an append-only, hash-chained audit trail.
Settings & integrations
Reporting contacts, MFA and SSO enforcement, regulatory thresholds, coordinated disclosure policy, GitHub/GitLab/Jira/Linear/Slack/Teams/PagerDuty, API tokens, webhooks, billing and data export.
2-minute walkthrough
From a product to a recorded submission, in six steps.
A reading-time walkthrough of the path a security engineer takes on the first day: no video, no sales call, and every screen named so you can find it in the free Evaluation workspace. The illustration below uses invented values.
| Product | SBOM | Open | Exploited |
|---|---|---|---|
| EdgeGate Router | Yes | 14 | 1 |
| DeviceHub Desktop | Yes | 6 | 0 |
| SensorLink Firmware | Missing | — | — |
- Step 10:00
Add a product and its version
Name, lifecycle state, owner and a preliminary classification with the reasoning recorded. Versions carry the support period and the repositories they are built from.
Products → New product → Versions
- Step 20:20
Bring in the SBOM
Upload a CycloneDX or SPDX file, push one from CI through the API or CLI, or let the GitHub App import releases and dependency-graph SBOMs. The original file is preserved with its checksum.
Product → SBOM → Upload / API / GitHub
- Step 30:45
Watch exposure appear
Components are deduplicated by package URL and matched against OSV and GitHub advisories, then enriched with CISA KEV and EPSS. The queue is ranked by exploitation evidence, not alphabetically.
Vulnerabilities → sorted by priority
- Step 41:05
Triage with a reason and a CRA review
A named reviewer sets the state, records why, assigns remediation and answers the Article 14 question explicitly: not reviewed, potentially reportable, confirmed or not reportable.
Vulnerability → Triage → CRA review
- Step 51:30
Open the reporting case
Confirming reportability opens a case with the awareness time, product, owner and server-computed 24-hour, 72-hour and final-report deadlines in your timezone. Forms are staged and prefilled.
CRA Reporting → Case → Early warning
- Step 61:50
Record the submission and the evidence
The manufacturer submits through the ENISA platform; Vellaci records time, submitter, reference and receipt as a frozen revision and files the evidence package in the vault with the audit trail.
Case → Submission → Evidence package
Illustrative walkthrough. Screens and values are examples; the free Evaluation workspace runs the same steps with your own product.
Architecture principles
Built like a system of record, not a dashboard.
Human decisions, recorded
Reportability, classification, awareness time and risk acceptance are made by named people with rationale. Vellaci computes, suggests and reminds — it never decides in your name.
Server-side truth
Deadlines, statuses and alerts are computed and persisted by background jobs with the rule version that produced them; the browser only renders.
Append-only history
Audit events are hash-chained per organisation; CRA submissions are frozen snapshots with amendment history; evidence carries checksums and review dates.
Tenant isolation in the database
Row-level security on every tenant table, permissions evaluated in Postgres and re-checked server-side before every mutation, cross-tenant tests in CI.
Metadata in, never source code
Integrations import releases, dependency graphs and issue links. Vellaci never needs repository read access to your code.
Portable by design
Full organisation export (JSON per table, audit CSV, evidence index, integrity manifest) at any time; a lapsed subscription keeps everything readable and exportable.
FAQ
Platform questions, answered.
- Who uses Vellaci day to day?
- Security engineers triage findings and run incidents; product owners maintain the registry, versions and support periods; compliance leads run the readiness framework, evidence and documentation; the assigned representative runs CRA reporting cases; executives read the overview and reports; auditors and advisers get time-limited, read-only access.
- How does data get in?
- SBOM upload in the UI, the public REST API and CLI from CI/CD, the GitHub App (releases and dependency-graph SBOMs), GitLab, CSV product import, and manual entry. Nothing requires access to source code — Vellaci consumes metadata.
- Can it replace our scanner or ticketing tool?
- It is not designed to. Keep Dependabot, Snyk, Trivy, Jira or Linear; Vellaci is the system of record that connects their outputs to products on the market, regulatory decisions, deadlines and evidence, and pushes tasks back into your tracker.
- Is there an API?
- Yes — a documented REST API with scoped tokens, cursor pagination and signed outgoing webhooks, plus a CLI. The OpenAPI document is published for code generation and AI agents.
- How long does implementation take?
- A first product with an SBOM, vulnerability exposure and a configured reporting runbook typically takes a day. Vellaci's implementation packages configure scope, products, integrations, workflows and evidence structure with your team in two to six weeks depending on portfolio size.
Read next
- Guide
CRA readiness checklist for software and connected-product manufacturers
A practical CRA checklist across governance, SBOM, vulnerability handling, disclosure, incidents, reporting, support period and documentation, with evidence to keep and current transition milestones.
- Guide
CRA Article 14 reporting obligations: a practical guide for manufacturers
What must be reported under Article 14 of the Cyber Resilience Act, by whom, to whom and when — the 24-hour early warning, 72-hour notification and final report — and how to operationalise it now that the obligation is in force (since 11 September 2026).
- Guide
SBOM guide for the CRA: formats, minimum content and operations
CycloneDX versus SPDX, what a CRA-oriented SBOM must contain, which tools generate one per ecosystem, how to keep it current per release, how to share it, and how it feeds vulnerability handling and VEX.
- Docs
Your first 15 minutes
From sign-up to the first vulnerable component.
- Docs
API overview
Tokens, scopes, pagination, rate limits, errors.
- Docs
Integrations
GitHub, GitLab, Jira, Linear, Slack, Teams, PagerDuty.
See it with your own product.
Add a product, upload its SBOM and watch exposure, triage and reporting workflows connect — or have an operator walk you through it.