Skip to content

The 24-hour reporting duty is in force. Check whether it applies to you

Security

This product holds a precise list of which vulnerable components its customers ship. That is a target, and it shapes how it is built.

Reviewed .

Where data lives

Database, file storage and compute all run in Frankfurt. Stated precisely: the infrastructure is in the EU and our providers are US companies, so this is EU hosting rather than EU legal control. If your procurement needs the latter, say so and we will tell you honestly whether we can meet it.

How people sign in

No passwords. A sign-in link by email, Google, or your own identity provider over OpenID Connect — Entra ID, Okta, Google Workspace, Ping and JumpCloud all speak it. Connecting one means proving you own the email domain by publishing a DNS record, and a connection can only sign in addresses on the domain it proved, so a provider configured to authenticate anybody still cannot get a stranger into your workspace. Public mail domains cannot be claimed at all. SAML is not supported, which we would rather say than ship a setting that does nothing.

Who can see what

Four roles, checked in one place rather than remembered at each screen. The one worth knowing about is the auditor: read-only, can generate and download evidence packs, and can change nothing. A reviewer who can prove what happened without being able to alter it is the whole point of the role.

Two-factor, checked per session

Available to every account and enforceable across a workspace. It is checked per session rather than per user, and re-checked on every request into the application: once enrolled, every new session is asked for a code, even on an account that has passed the check before, so a sign-in link intercepted from an inbox does not get past it.

Sessions, and what happens when someone leaves

Sessions live in the database rather than in a token, chosen so that removing somebody actually revokes their access rather than waiting for a token to expire. Removal deletes the membership and, if that was their last workspace, their sessions, in the same transaction.

Tenant isolation

Every tenant table carries a workspace identifier, and it is enforced in a single database client rather than remembered at each call site. A query that names another workspace is refused outright rather than quietly rewritten. Automated tests attempt cross-tenant reads and writes on every build.

The audit log

Every action is recorded and hash-chained to the one before it, so an altered or removed entry is detectable. The chain is per workspace, so one customer’s activity cannot be used to infer another’s, and each entry is written in the same transaction as the change it describes — an audit log that can disagree with the data it records is worse than none, because it is trusted.

The database refuses updates and deletes on that table with a trigger rather than a permission, because the application connects as the table owner and an owner bypasses permissions. Closing a workspace cannot cascade the chain away either. Stated precisely: this makes tampering detectable, not impossible. Anyone who could rewrite the whole table could recompute the chain, which is why the evidence pack carries a verification code anyone can check without seeing the contents.

What is public, and the links you hand out

A Trust Center page shows only what someone in the workspace chose to publish. Nothing is public until a product’s page is published, the VEX document only if it is switched on separately, and the simplified declaration only once a member confirms the one you issued. Alerts, cases and risk assessments are never shown, and component names appear only in a VEX document you chose to publish.

SBOM share links and supplier upload links carry a random secret. Only its SHA-256 hash is stored, so a copy of the database holds no working link. The secret travels in the part of the address after the #, which browsers do not send to a server, and the page exchanges it by POST. Every link expires and can be revoked. Each use of a share link is recorded for you against a salted hash of the visitor’s address, never the address itself. Requests are rate-limited, and the responses are sent with no caching, no referrer and no indexing. Those two pages are never reported to our analytics, and every other page has the part after the # removed before it is.

The AI assistant connection is read-only: it signs in with one of your API keys, each tool needs a read scope on that key, and none of them can file, change or send anything. Recipients’ email addresses and visitors’ address hashes are kept out of the append-only audit chain, which records the domain or a count instead, so neither lands in a table that refuses to delete it.

Retention

Case data and audit events are retained for seven years, because they are the evidence a market-surveillance authority may ask for. Everything else is purged within 30 days of a workspace closing. Anonymous SBOMs submitted to the free check are never stored at all.

What we do not claim

There is no SOC 2 report, no ISO 27001 certificate, no third-party penetration test and no bug bounty. If your procurement requires any of those, we do not meet it today and would rather you find that out here than three weeks into an evaluation.

Two specifics, because a general disclaimer hides more than it admits. Everything is encrypted at rest by the database provider. Some things get a second layer on top of that and one does not: single sign-on client secrets, Jira API tokens and Dependency-Track API keys are encrypted by the application, API keys and public link secrets are stored as hashes and cannot be read back at all even by us, and the two-factor seed has neither. Hashing and encryption are different properties and are named separately here rather than averaged into one word. And the deadlines and scope verdicts this product computes are read from the article text and have not been through a lawyer.

Reporting a vulnerability in this product

Declara is itself a product with digital elements, so the obligation we help you meet applies to us exactly as it applies to you. Report a vulnerability to kiril.u@gmail.com, which is also published at /.well-known/security.txt. We will not pursue researchers acting in good faith.