How this service is run
What this service runs on, who else touches the data, and what the code does to keep one customer's records away from another's. Every statement here describes the deployment as it is configured today.
Keeping one customer's data away from another's
Each customer's records sit behind row-level security in the database itself. Every application table has it enabled and forced, and the rules read values that are set for the length of a single transaction and cannot outlive it.
The application never connects to the database as the role that owns the schema. It connects as a plain login role with no table ownership and no power to bypass those rules, so a query made under the wrong scope comes back empty rather than coming back with rows it should not touch.
Identity, sign-in claim, worker and rate-limit tables carry no access rules for the application at all. It reaches them only through a small set of named database functions.
The audit trail
Changes inside a workspace are written to a trail that is only ever added to. Each entry carries a hash of the one before it, so an edit to an earlier entry breaks the chain and shows up when the chain is checked.
Entries are signed where a signing key is configured. That establishes internal consistency and authenticates signed entries against a trusted key. It does not prove that the stored history is original and complete.
Where it runs
The application, the database and uploaded evidence files run on one Scaleway server in the Paris region, France. Evidence file bytes stay on that server's own disk — never in the database, and never handed to another service.
Both sites are served over HTTPS only. The certificates are issued automatically by Let's Encrypt through the reverse proxy that sits in front of the application.
Every page carries a content security policy generated fresh for that request. It admits no inline script and no dynamically evaluated code.
Sign-in, analytics and what leaves the server
Signing in uses a single-use link sent to your email address. There is no password to store, and none is stored.
Analytics is switched off in this deployment. Were it switched on, it would be a page-view counter on the public site only, never on the signed-in application, and it would set no cookie.
Customer data is not sold, and it is not passed to anybody for advertising.
On a schedule, the worker downloads the CISA Known Exploited Vulnerabilities catalog from www.cisa.gov and fixed OSV ecosystem archives from storage.googleapis.com/osv-vulnerabilities/. Component matching reads the imported OSV records in this application's database; it does not query the OSV API.
These public-source downloads send no customer data. The OSV importer covers npm, PyPI, Maven, Go, crates.io, RubyGems, NuGet and Packagist. Each source is scheduled after 24 hours, with one due source attempted per worker tick and retries after failures. Displays use successful synchronization records; the schedule does not guarantee that a source has been refreshed.
CISA KEV matches are shown as known-exploited alerts. OSV matches are shown separately as advisories and do not start an incident or reporting clock.
The alert and weekly-summary emails deliberately say less than the application does. Neither carries a vulnerability identifier, a component name or a product name — only that something is waiting, and a link to sign in and read it.
Keeping the code current
Production dependencies are checked against published advisories on every change. A high or critical finding blocks the release.
The code is scanned for known vulnerability patterns on every change, and once a week besides.
Dependency updates are proposed automatically. Minor and patch releases are grouped; a major version is taken on its own.
What is kept, and for how long
An assessment that is never purchased is deleted after thirty days.
Purchased assessments, workspaces, evidence, incident records, SBOM data, vulnerability reports and audit events are kept while the workspace is kept, including during read-only access. When a customer requests deletion, access ends immediately with a 14-day restoration period, and live content is deleted within 30 days. Encrypted backups expire on the backup schedule (up to 12 months).
Reporting a problem in this service
If you have found a security problem here, the disclosure policy sets out how to tell us, what we ask while you are looking, and what happens after you send it.
Customer vulnerability-report intake
An eligible workspace can publish a text-only vulnerability-report form at an unguessable URL and can disable or rotate that URL.
The generated security.txt snippet points to that customer-hosted reporting page; the customer places the snippet on its own domain.
Reports are retained as workspace records without file uploads, and reporter acknowledgements use generic wording that carries no workspace or report detail.
Conformity-document drafts
The declaration and technical-documentation surfaces arrange verified source requirements beside workspace records and manufacturer-supplied fields.
They remain marked as drafts, do not assert conformity, and record an audit entry before browser printing starts.
Scheduled source checks
The worker fetches the registered CRA XHTML and Formex sources and countries reference from publications.europa.eu, and the registered CSIRT directory from csirtsnetwork.eu. The source list is fixed by the repository registry.
One due source is checked per worker tick. After a successful check, the source is due again in seven days; failed checks retry after one hour. These requests send no customer data.
A different file hash creates a source-change record and an owner review action. Detection does not edit the application's legal data or determine what the source change means.
Providers this deployment uses
Everything below either handles customer data today or would if it were switched on. Where a provider is not enabled, nothing reaches it at all.
| Provider | What it does | Where it handles data | State |
|---|---|---|---|
| Scaleway | Runs the single server that holds the application, the database and uploaded evidence files. | France (Paris region) | Selected for production |
| Scaleway Transactional Email (TEM) | Sends sign-in links and notification email. It is given the recipient address and the text of the message. | France (Paris region) | Selected for production |
| Scaleway Object Storage | Holds the encrypted nightly copies of the database and the evidence files. | France (Paris region) | Selected for production |
| Plausible Analytics | Counts page views on the public site. It is never loaded on the signed-in application and it sets no cookie. | European Union | Not enabled in this deployment |
| Sentry | Is sent a report when the server hits an error it did not expect: the message and stack after token and address redaction, the request path and the method. | France (Paris region) | Not enabled in this deployment |
| Uptime heartbeat | Is pinged each time the background worker finishes a run. It is sent no customer data. | France (Paris region) | Not enabled in this deployment |
Let's Encrypt issues the certificates the sites are served with. It is sent the domain names and no customer data.
The bill of materials for this application
The packages this web application build was assembled from, with their versions, in CycloneDX JSON.
It describes this application and nothing else. It says nothing about any customer's product, and it is not a statement that any requirement has been met.