Security & data handling

ExploitClock exists to help you prove you handled security obligations correctly, so we hold ourselves to the same standard. This page is written for your security reviewer. It is Annex 2 to our Data Processing Agreement. Last updated: 17 October 2026.

Privacy · Terms · DPA · Security · Imprint

Where your data lives

Application, database and cache run in Frankfurt, Germany (EU) on Render. SBOMs, component lists, matches, drafts and the evidence chain are stored in a managed PostgreSQL database in that region, encrypted at rest by the provider, with the provider's own snapshots. In addition we take a weekly logical dump with pg_dump, upload it over TLS to EU object storage with a SHA-256 checksum, and keep twelve weeks of them. The restore path is a script in the repository, not a plan on paper. Backups do not leave the EU.

What we store

Your account (Auth0 subject id, email, username), the products and versions you register, the SBOM documents you upload (verbatim, with SHA-256), the vulnerability matches we derive, your notification drafts, notification settings, and an append-only evidence log. If you switch them on, also: the vulnerability reports people send through your reporting page (with the name and email address a reporter chose to give), the advisories you publish, the email addresses on your advisory distribution list, and the Jira or GitHub token you connect. Those tokens are encrypted at rest with an authenticated cipher (Fernet) under a key derived from our application secret, are shown again only as their last four characters, and are never returned through the API or written to a log or an error message. Reporters' details are kept out of the evidence log and out of alerts, recipients' addresses out of the evidence log, alerts and logs, and both are deleted with your account. We do not store your source code or your binaries, and of your own customers' data only the addresses you put on your distribution list.

What leaves our systems

Three public vulnerability services receive technical identifiers from your SBOMs, and nothing else. Component identifiers (purl, or ecosystem plus name and version) are sent to OSV.dev (Google) to look up advisories, in batches per scan. CVE identifiers of the advisories found are sent to FIRST EPSS for exploitation probability. Components that carry a CPE identifier (CPE 2.3, or the older 2.2 form, which we convert) and no package URL that OSV can answer for (typically firmware, operating-system libraries, C libraries and the Linux kernel) are looked up one CPE at a time on the NIST NVD API by their CPE string, which names the vendor, product and version of that component. This NVD lookup runs on every scan by default; it is not optional and it does not depend on an API key. Each scan asks NVD about at most 40 distinct CPEs (NVD_MAX_CPE_QUERIES), with or without an API key; without a key (the default) we additionally restrict the lookup to the known-exploited subset, with a key we ask for every advisory, except for the Linux kernel, which is always restricted to known-exploited results. Operating-system and hardware CPEs other than the Linux kernel are not sent. The CISA KEV catalog and the ENISA EUVD exploited list are downloaded in full and matched locally, so CISA and ENISA receive nothing about your components. No product names, SBOM metadata or account data are included in any of those requests. OSV.dev, FIRST and NVD are operated in the United States: they receive no personal data, but treat your component list as confidential when you decide what to upload.

Three more flows happen only when you set them up. A ticket you create from a case goes to your own Jira Cloud site or GitHub repository, with the case title, product and version, advisory ids, exploitation evidence and deadlines; a case that came from a vulnerability report is named by its reference only, never by what the reporter wrote. An advisory you email goes, through our mail provider, to the addresses on your distribution list. And your public reporting and advisories pages show the disclosure policy and the advisories you published there, and nothing else.

Authentication and access

Login is delegated to Auth0 (OpenID Connect with PKCE); we never see passwords. Two-factor authentication (a one-time code from an authenticator app) is required on every account from the first login and cannot be turned off, because a login can confirm, dismiss and export entries in a manufacturer's legal reporting record. A lost authenticator is reset by us only after we have confirmed the request came from the account's email address. Sessions are signed, HTTP-only, SameSite cookies with a 2-hour idle and 8-hour absolute timeout. API keys are shown once and stored as bcrypt hashes, and they cannot reach account administration (export, deletion, member management, settings). That requires a real logged-in session. State-changing requests require a CSRF token. Every domain query is scoped to the account, not to the individual user. The account owner can give each colleague editor or read-only viewer access; read-only is enforced by the server on every state-changing request, not just hidden in the interface, and every role change is in the evidence trail. Single sign-on (SAML or OIDC through Auth0) is available on request; it is not self-serve. We set it up per customer, and can make it mandatory for the company's email domains.

Integrity

Every evidence event is hashed with SHA-256 over its canonical content and the previous event's hash. Any modification or deletion breaks verification, which you can run at any time and which is embedded in every export. The chain head is timestamped daily with an RFC 3161 timestamp authority, so the chain can be shown to have existed at that time without trusting us.

Transport, headers and third-party code

TLS 1.2 and above everywhere, HSTS with preload, a strict Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, frame and cross-origin isolation headers, and no caching of any page that reveals account state.

The only JavaScript the application serves is our own /static/js/app.js. There is no analytics, no tag manager, no advertising pixel and no session-recording script anywhere on the site. That includes the two pages we host on your behalf: your vulnerability reporting page and your advisories page load no analytics either, and the reporting page never stores a reporter's IP address. The Inter and JetBrains Mono web fonts are self-hosted from /static/fonts, so no page load reaches a font CDN. One exception a reviewer will find and should know about:

• Payment happens on Stripe's hosted Checkout and billing portal. We redirect you there rather than embedding Stripe's script in our pages, and the Content-Security-Policy permits Stripe's domains for that flow.

Outbound requests

Any URL you supply, such as a webhook or a policy URL, is validated before we fetch it: HTTPS only, public hosts only, no redirects followed, DNS-resolved addresses checked against private ranges, response size capped. The Jira and GitHub integrations contact only Jira Cloud addresses (atlassian.net) and api.github.com, through the same checks. Client IP addresses come from the trusted proxy layer, not from a raw X-Forwarded-For header.

Payments

Handled by Stripe. We store the Stripe customer and subscription identifiers only. Card data never touches our servers.

Our own SBOM

We eat our own cooking: ExploitClock's CycloneDX SBOM is published at /static/exploitclock.cdx.json and monitored in ExploitClock itself.

Sub-processors

This is the complete list, and it is the Annex to the DPA. We give 30 days' notice before adding one, and you may object. Note that alert email is sent through our provider; you cannot supply your own SMTP server.

Lookup recipients (no personal data)

To find advisories and exploitation signals we query public vulnerability services. These receive technical identifiers only. They receive no account data, no product names and no SBOM documents. Your component list is nevertheless commercially confidential, so we send identifiers only, never the SBOM itself, and store the results ourselves. All three lookups run on every scan by default.

Removed from this list on 11 September 2026: Google LLC (Google Fonts). The interface's web fonts are self-hosted from our own domain, so no visitor data reaches Google on page load. Removing a recipient does not require the 30 day notice that adding one does.

Your own alert endpoints (an email address, a Slack incoming webhook or an HTTPS webhook you enter in Settings) receive alert content when you configure them, and a Jira Cloud site or GitHub repository you connect under Settings › Integrations receives the tickets you create from a case. Those endpoints and services are yours, not our sub-processors.

What we do not do

A short list of things we are not, so that you do not have to discover them in a questionnaire.

• No SOC 2 report and no ISO 27001 certificate. We hold neither today and we will not imply otherwise. What we offer instead: EU-only hosting and backups, a published and complete sub-processor list, an Art. 28 DPA with the Standard Contractual Clauses that applies to every plan, full data export in a documented format, an evidence log you can verify without us, and written answers to your security questionnaire on any plan.
• No independent penetration test report yet. Every build runs pip-audit against our pinned dependencies and fails on a known vulnerability, and we monitor our own SBOM inside ExploitClock. We intend to commission an external test and will publish the date and the summary here when we do. Ask us for the current status before you rely on it.
• Single region. Everything runs in one region, Frankfurt, Germany (EU). That is deliberate for data residency, and it means a regional outage takes the service down. Your deadlines do not pause, so configure at least two alert channels and export regularly.
• No compliance guarantee. ExploitClock does not make you compliant with the Cyber Resilience Act and does not file anything on your behalf. It watches feeds, starts clocks, drafts notifications and keeps evidence. The filing, the assessment and the responsibility stay with you.
• No 24/7 on-call rota. Support is Mon to Fri during EU business hours; see the Terms. The automated monitoring, alerting and clocks run continuously; the humans do not.

Availability

We aim for 99.9% monthly availability on paid plans. That is an operating target, not a warranty, and there is no service credit scheme. Current state and incident history are on the status page, which is the source of truth. Scheduled maintenance is announced there in advance.

Vulnerability disclosure

Found something? Email support@exploitclock.com with "security" in the subject, or use the contact in /.well-known/security.txt. We acknowledge within 2 business days, tell you what we plan to do, and credit you if you want the credit. Please do not run automated scans against the production service; ask us and we will arrange it.

Data processing agreement

Our Art. 28 GDPR data processing agreement is published in full at /dpa. It applies to every plan, forms part of the Terms, and includes the EU Standard Contractual Clauses (Module 2) and the sub-processor annex above. You do not need to request it. For a signed copy for procurement, email support@exploitclock.com.