Novità del prodotto — ExploitClock

v0.4.12 More accurate matching for device firmware SBOMs 2026-10-24

fixed Components identified by the older CPE 2.2 form (OpenWrt writes every package this way) are now looked up on NVD; they were skipped before. The Linux kernel is now checked for known-exploited vulnerabilities by its version: in device firmware it is the product's own attack surface. On the official OpenWrt 23.05.1 image this finds the ten known-exploited kernel vulnerabilities that were missed before.
fixed Debian, Ubuntu and Alpine packages are now checked against the advisories for their own release and by their source package, as the distributions publish them. Debian packages no longer match fixes from other releases (two false known-exploited cases on a Debian 10 image are gone), and Alpine packages are now checked at all.
fixed When NVD rate-limits a scan, the scan now says so ("NVD rate-limited") instead of reporting a complete result. Components whose version is unknown ("UNKNOWN") no longer use up NVD lookups.
added A proof run over public device and embedded SBOMs (OpenWrt, Yocto, an NXP vendor image, Debian, Alpine and others), checked against independent sources, so every release can be measured against real firmware.

v0.4.11 Drafts follow ENISA glossary v1.6: the awareness field is on the platform 2026-10-21

changed ENISA published glossary v1.6 today. The vulnerability form now has a mandatory field for when you became aware, and both forms label it 'Date and time when you become aware'. Drafts mark it as a platform field on both tracks and pre-fill it from your case; the form-filler and the .txt fill sheet use the new labels.
changed Each notification step now lists only the fields that step asks for, as in the glossary: product and manufacturer details, the summary and the CVE and EUVD IDs are entered once, on the early warning. The occurrence time (v26a) is copied to the 72-hour notification instead of being required there, and the incident occurrence time (i38) is optional at 72 hours.
added The new row 7a, Additional Information about the manufacturer, is in every early-warning draft. 'Please provide further information' (v30) now appears only with a PEC request, as the platform shows it, and the PEC delay reason lists all three grounds.
changed The Secondary Assigned Representative hint and the onboarding deputy step give the invitation steps from ENISA's AR user manual v1.2: Settings › Invite Backup, anyone already on the platform can be invited, and the invitee accepts from Alerts within 7 days.
changed The public field reference, the CRA explainer, the deadline check, Help and the free drill no longer say the vulnerability form lacks an awareness field. The drill now checks that you entered the awareness date and time in its own field.

v0.4.10 A third exploited list: VulnCheck KEV 2026-10-19

added VulnCheck Known Exploited Vulnerabilities (VulnCheck KEV) is now a third exploitation source next to CISA KEV and ENISA EUVD. It lists considerably more known-exploited CVEs than CISA, often earlier. A component whose vulnerability is on VulnCheck KEV opens an assessment case exactly like a CISA KEV hit, with VulnCheck KEV named as the source on the case, in the alert, in the evidence trail and in the SRP draft. When CISA lists the vulnerability too, CISA KEV stays the primary source and VulnCheck KEV is recorded as corroborating.
added The case page shows the date VulnCheck added the vulnerability and the public reports of exploitation it links to. Exploitation data includes VulnCheck KEV, provided by VulnCheck (https://vulncheck.com/kev).
changed The free CRA Clock Check keeps checking CISA KEV and ENISA EUVD only; VulnCheck KEV is part of the paid plans and the trial.

v0.4.9 Score your drills, and a free 24-hour drill for anyone 2026-10-17

added Every drill is scored out of 100 from what is already on its record: how long awareness took to confirm, whether the 24-hour early warning and the 72-hour notification were submitted on time and with every required platform field filled, whether the final-report flow was started, whether the case names the coordinating CSIRT of your main establishment, whether informing impacted users (Art. 14(8)) and the upstream maintainer step (Art. 13(6)) were taken, and whether the evidence chain over the drill verifies. The weights are one published table; only steps your team controls are scored. The score is written to the evidence trail once, when the drill is closed.
added An after-action report for each drill (Print / save as PDF): the score, every criterion as pass, partial or fail with the evidence event and time it came from, what to fix next starting with the biggest loss, the timeline, and the trend against your previous drills. The case list, the case page and the compliance report show each drill's score. Drill scores never enter the compliance figures.
added A free public 24-hour drill at /tools/drill, in all five languages: pick one of three scenarios (a BIND resolver in a router, OpenSSL in an industrial gateway, a web framework in a management interface), then decide awareness, pick the coordinating CSIRT, fill in the early warning and the 72-hour notification in the platform's own fields (glossary v1.5), decide on users and the upstream maintainer, and name the final-report deadline, against a clock running 120 times faster than real time. Scored out of 100 in the browser with a printable result. No account, and nothing you type leaves the page.

v0.4.8 Tell the upstream maintainer, and get an ID 2026-10-17

added An "Upstream maintainer" panel on every vulnerability case, for CRA Article 13(6): a manufacturer that identifies a vulnerability in a component, open source included, reports it to whoever maintains the component. For a case opened from your SBOM it shows the component, its package URL and where to report: the security contact, issue tracker, repository or website the SBOM gives for that component (CycloneDX externalReferences, SPDX homepage and download location), the repository's security policy and private reporting page on GitHub, and the project links in the advisory. When none of these is known, it says so. Nothing is fetched to build the panel; the links come from data already held.
added Record the step in one place: "Record upstream notification" (channel, date, an optional reference such as a GHSA id or a link, and a note), or "Not needed (already public)" with a reason, for a vulnerability that already has a CVE and is listed as known exploited. Both are written to the evidence trail and appear on the case's timeline and in the technical-file export.
added Short guidance for a vulnerability you found yourself: report it privately through the maintainer's security policy or security.txt, and for an identifier ask the maintainer whether it is a CVE Numbering Authority, otherwise request a CVE from a CNA of last resort such as MITRE (cve.org) or contact ENISA, which runs the EUVD.

v0.4.7 The vulnerability-handling section of your technical file, and support-period alerts 2026-10-17

added Each product page has a "Technical file: vulnerability handling" export: the part of the technical documentation (CRA Annex VII point 2(b) and (c), Annex I Part II) that ExploitClock can vouch for, assembled from the evidence log for a period you choose (the last 12 months by default). It covers the support period and the versions with every SBOM (format, sha256, upload date, component count); how vulnerabilities are handled (the monitoring sources and how often they run, which kinds of alert channel are set up, the vulnerability inbox and its policy, the security.txt contact, the advisories page and the size of the distribution list); the figures for the period (matches found and how they were triaged, including VEX, cases opened and closed, each Article 14 notification drafted, submitted, on time or late, user advisories, upstream reports, the median time from awareness to early warning); a table of the cases; and the result of verifying the evidence chain with the latest RFC 3161 timestamp.
added Print it or save it as PDF from the browser, or download it as Markdown or JSON (also from the API). It never contains reporters' personal data, case notes or alert addresses, and each export is recorded in the evidence trail. Part of every paid plan and the trial.
added Support-period alerts: 90, 30 and 7 days before the support period you declared for a product ends, and on the day it ends, through your alert channels, once each and recorded in the evidence trail. The product page and the dashboard show how many days are left.

v0.4.6 Read-only viewers, and single sign-on for your company 2026-10-17

added Read-only access for colleagues who need to see, not act: when you invite someone you now choose editor (can change everything, as every member could until now) or viewer. A viewer sees the dashboard, products, matches, cases, filings, evidence, the vulnerability inbox, tickets and advisories, and cannot change any of it. The owner can switch a member between editor and viewer at any time in Settings. Everyone already on an account stays an editor.
added Invitations, role changes and the role a person joined with are recorded in the evidence trail, and the role of each person shows in Settings and in your account export. A viewer sees a "Viewer" badge in the header, and buttons that would change something are disabled with "Read-only access".
added Single sign-on for your company on the Unlimited plan: your team logs in through your own identity provider (SAML, Microsoft Entra ID or OIDC) with "Sign in with your company SSO" on the login page. We set it up with your IT team, and can make it mandatory for your email domains, so a password or Google login with a company address is refused. Settings shows whether it is on, the connection, the domains and whether it is enforced; write to us to set it up.
security Read-only is enforced by the server on every state-changing request, whatever the page shows, and an automated test walks every endpoint of the API to check it. A viewer cannot create API keys; a key acts with the role of the person who created it. A viewer does not see the webhook signing secret. Single sign-on is decided from Auth0's signed login token only, and turning enforcement on ends the open sessions it covers once.

v0.4.4 No SBOM yet? The GitHub Action makes one 2026-10-17

added The ExploitClock GitHub Action now generates a CycloneDX SBOM with Syft when you don't give it one: from your checked-out code, an unpacked firmware root filesystem, or a container image. One step in your release workflow is all it takes.
fixed The GitHub Action now creates versions correctly when the version name contains quotation marks.

v0.4.3 Tell your users: a public advisories page, a feed and customer emails 2026-10-17

added A public advisories page for your account, as Article 14(8) expects you to inform impacted users about an actively exploited vulnerability and what they can do about it. Switch it on in Settings; it has a random address of its own (not the vulnerability inbox's), lists your published advisories newest first, and gives each advisory its own page with the affected product and versions, severity, CVE and EUVD ids, exploitation status, what users should do, fixed versions and the dates it was published and updated. Search engines may index it unless you switch that off. It loads no analytics.
added Publish from the case: the editor is pre-filled from public data about the vulnerability and from your fix record, never from the case notes, the evidence or a vulnerability report, and you choose the languages (English, German, French, Spanish, Italian) and write each one yourself; nothing is machine-translated. Publishing records that users were informed (channel "public advisory page") and satisfies the Art. 14(8) step. Updates keep a revision history and never move the date users were first informed; you can withdraw an advisory, which then shows a withdrawal notice instead of a missing page. Every step is in the evidence trail.
added Machine-readable for every advisory: a CSAF 2.0 document built from the published fields only, an Atom feed of the page, and a CSAF provider-metadata.json with a directory listing (index.txt, changes.csv). With the page on, the security.txt generated in Settings carries a CSAF line pointing at it.
added A customer distribution list in Settings: paste up to 2,000 addresses (validated and de-duplicated), for every product or one. "Email users" on publish sends each address its own short message with a link to the advisory and an unsubscribe link that works without logging in, in the background, with the sent and failed counts in the evidence trail. An address that unsubscribed is never added or emailed again. A daily limit of 4,000 emails per account applies. Emails are part of the paid plans; the page, feed and CSAF files are also in the trial.
security Publishing and emailing are session-only: an API key cannot put words on your public page or email your customers. The public pages are rate limited, show only what you published, and escape everything. Recipients' addresses never enter the evidence trail, alerts or logs; the list, the publications and the sends are in your account export and are deleted with your account.

v0.4.2 Import VEX and see what changed between versions 2026-10-17

added Import the VEX statements you already hold, from your own analysis or from a supplier, on a product version or for the whole product: CycloneDX VEX and OpenVEX, as JSON. Each statement is matched to the version's findings by vulnerability id or alias and by component (package URL, BOM reference, or name and version). A not affected statement with a justification, a fixed or a false positive statement is applied exactly like a manual triage, shows as "VEX: <file>" on the finding, and appears in your VEX export. Statements that match nothing are listed back to you, never dropped.
added Imported statements carry forward: when a later version ships the identical component version, the statement covers its new findings too, before a case would open. A component whose version changed is not covered. A finding you triaged yourself is never overwritten by a carried-forward statement.
changed A VEX statement never closes or dismisses a case and never stops an Article 14 clock. If a case is already open for the vulnerability, the statement is recorded on the case's evidence trail for information and the decision stays with you. Every import is recorded in the evidence trail with its counts.
added Each product version now shows what changed since the previous version (or any version you choose): components added, removed or upgraded, and vulnerability findings newly introduced, resolved or still present, with known-exploited ones (CISA KEV, ENISA EUVD) highlighted. Also through the API.

v0.4.1 Tickets in Jira and GitHub from any case 2026-10-17

added Connect Jira Cloud or GitHub Issues in Settings › Integrations, then open a ticket for the fix work from any case with one click, or link a ticket you already have. The ticket carries the case title, product and version, advisory ids, the exploitation evidence, the Article 14 deadlines in UTC and a link back to the case. A case opened from your vulnerability inbox is named by its VR- reference only: nothing the reporter wrote, and no name or email address, goes into the ticket.
added ExploitClock checks each linked ticket's status every 15 minutes and records every change in the evidence trail. When the fix ticket is done, the case asks you to record the date the fix became available, which starts the 14-day final-report clock. A closed ticket never changes the case or its deadlines on its own.
added Included in every paid plan and in the trial. Creating, linking and unlinking tickets also work through the API.
security Jira API tokens and GitHub access tokens are stored encrypted, shown again only as their last four characters, and never sent to an API key, a log line or an error message. Only Jira Cloud addresses (atlassian.net) and api.github.com are contacted, through the same outbound checks as every other address you give us. A fine-grained GitHub token limited to one repository and Issues is enough.

v0.4.0 A vulnerability inbox for every account 2026-10-17

added A public page where security researchers and customers can report a suspected vulnerability to you, as the Cyber Resilience Act expects (Annex I Part II, points 5 and 6). Switch it on in Settings; it is included in every plan, including an account without a subscription. The page shows your disclosure policy, which you can edit, and has a random address you can replace at any time.
added Every report gets a reference and a 48-hour acknowledgment target. You are alerted on your alert channels when one arrives, and once more if it is still unacknowledged after 48 hours. The new Inbox page lists them, with overdue ones marked.
added From a report you can acknowledge it (the reporter gets a short confirmation email if they left an address), close it with a reason, or convert it into a case on one of your products. A converted case opens in assessment and no clock starts: you still confirm awareness on the case. Every step is recorded in the evidence trail.
added With the inbox switched on, the security.txt generated in Settings lists its address as a second Contact line.
security The reporting page is rate limited, has a hidden trap field for bots and a signed form that must be sent between 3 seconds and 2 hours after it was opened. It accepts no attachments, loads no analytics, and never stores the reporter's IP address. Reporters' names, email addresses and report text stay on the report: they are not copied into the evidence trail or into alerts, and they are included in your account export and removed when you delete the account.

v0.3.10 Drafts follow the ENISA glossary v1.5 2026-10-16

added Vulnerability drafts have the new field 'Date and time when the Actively Exploited Vulnerability occurred'. The platform requires it on the 72-hour notification, so the draft shows it as missing until you fill it in. We leave it empty rather than guess.
added Every draft has the platform's new 'AR Note', a free-text note for anything no other field covers.
changed The SRP field reference and the form-filler follow glossary v1.5 of 15 October 2026. The vulnerability form still has no field for when you became aware, so keep stating it in the summary.

v0.3.9 Our data protection representative in the EU and the UK 2026-10-09

added ExploitClock LLC has appointed DataRep as its data protection representative in the EU, the EEA and the UK (Article 27 GDPR and UK GDPR). The privacy notice and the imprint now say how to reach them: by email, by web form, or by post in 31 countries.

v0.3.8 Talk it through in 30 minutes 2026-10-06

added You can book a 30-minute walkthrough (in English) from the help page: we run one of your SBOMs through ExploitClock while you watch and answer your Article 14 questions. The trial emails carry the same link.
fixed Every link in an ExploitClock email is now clickable, not only the main button.
changed The privacy notice now describes walkthrough bookings: what the booking page receives, who handles it and how long we keep it.

v0.3.7 Our mark on everything we send you 2026-10-06

changed Every email ExploitClock sends (deadline alerts, the daily summary, invitations and trial emails) now opens with the ExploitClock logo, so you can tell at a glance that an alert is really from us. Drill emails keep their amber TABLETOP DRILL marking.
changed A printed or PDF-saved compliance report or case report now carries the ExploitClock mark and the report title at the top of the first page.
fixed The home-screen icon on iPhone and iPad no longer shows dark corners.

v0.3.6 Hardening for the security review your buyers will run 2026-10-06

security Scripts now run under a fresh per-page nonce in the Content Security Policy instead of 'unsafe-inline', and no page uses inline event handlers. An injected script would not run even if escaping ever failed.
security Logging out now ends your session on the server, on every device: a copy of the session cookie stops working the moment you log out instead of two hours later. Removing a colleague from an account ends their sessions at once. A link on another website can no longer log you out.
fixed Our script and stylesheet are linked under a fingerprint of their content. They are cached for a year, so a returning visitor could keep an outdated copy after an update; each change now arrives under a new address.
fixed Every page answers HEAD requests. Link scanners such as Microsoft Defender Safe Links and Proofpoint URL Defense check a link with HEAD before letting someone open it, and our pages used to answer 405 Method Not Allowed, which can make a link look broken.

v0.3.5 A trial no longer ends in silence 2026-10-06

added Trial emails. A welcome with the three steps that make the clock watch something; on day three, a reminder if none of your products has an SBOM yet; three days before the end, the date and what pauses; and a note when the trial has ended. Each goes out once, from the same address as the daily summary, so it can never interfere with deadline alerts. Paid accounts and invited colleagues get none of them.
changed The page header and the phone menu name your login by its email address instead of an internal username.

v0.3.4 An unsubscribe can no longer silence a deadline alert 2026-10-01

fixed Our mail provider adds an Unsubscribe option to every email, and using it blocks that sender address for you. When everything came from one address, unsubscribing from the daily summary would also have stopped 24-hour deadline alerts, and we would not have known. The daily summary and invitations now come from a separate address, so they can be unsubscribed from without touching alerts.
added Every hour we ask the mail provider whether any of your alert addresses is blocked (an unsubscribe, a hard bounce or a spam report). If one is, the Alerts line on the dashboard turns red, Settings says which address and why, the evidence chain records it, and we warn you on your other channels. A blocked address is reported as a failed delivery rather than a delivered one, and the owner of the address can re-enable it from Settings.
changed Every email says how to stop the daily summary (Settings) and asks you not to use your mail app's Unsubscribe button. Two-factor authentication is now stated on /security, /help and the pricing page, and Help no longer repeats the pre-30-September claim about what a Secondary Assigned Representative can see.

v0.3.3 What a new customer meets in their first twenty minutes 2026-10-01

fixed Scans finish on networks that block WebSockets. A scan's result used to reach the page only over a WebSocket, so behind a corporate proxy that refuses them, "Try the sample" and SBOM uploads opened their cases but the page said the scan did not finish. The page now asks over plain HTTPS when the socket fails, and the dashboard says "live updates blocked by your network · refreshing every minute" instead of "reconnecting…" forever.
fixed The daily heartbeat counts what the dashboard counts. A trial whose only product was the sample read "Watching: 0 product(s), 10 components" and "157 new matches"; the sample's components, matches and cases are now left out of the figures, its deadlines are listed with a [sample] or [drill] tag, and times and states read "Fri 02 Oct 2026, 16:04 UTC (on track)" instead of raw timestamps.
fixed An invited deputy lands on sign-up with the invited address filled in, instead of on a log-in form for an account they do not have (someone who already has a login gets the log-in form). The invitation email names the person who sent it by email address rather than an internal username, and the join page names the company.
security PyJWT upgraded to 2.15.1 (2.14.0 fixed thirteen advisories; none was reachable, because ExploitClock accepts only RS256 tokens from Auth0). The SBOM we publish at /static/exploitclock.cdx.json had fallen behind our pinned versions; it is regenerated, and a test now fails if it drifts again. Found by uploading it to ExploitClock.
changed If your browser is set to UTC, times appear once instead of twice.

v0.3.2 Deputies can take over after all, says ENISA 2026-09-30

fixed A new API key, and the link in a new invitation, now stay on screen until you copy them. Both were shown and then hidden again a moment later by the list refreshing underneath, so the key was lost before it could be copied. The value now sits in a field that selects itself on tap, with a Copy button, and the page scrolls to it.
fixed The onboarding step for adding a deputy said a Secondary Assigned Representative sees only the notifications they submitted themselves. ENISA's FAQ of 30 September 2026 (Q9) says the opposite: every AR associated with a manufacturer can see and update all of that manufacturer's notifications, whoever submitted them, so a deputy can continue a case. The one exception is drafts, which stay in the individual AR's account; the step now says so and advises submitting the early warning rather than parking it as a draft.
changed The regulatory changelog records the 30 September FAQ update: shared visibility for ARs, the new questions on correcting a manufacturer name and on a rejected AR association (Q32, Q33), the unchanged 72-hour counter with ENISA's promise to compute it from the awareness time in a future release, and the published helpdesk address.

v0.3.1 Corrections against the ENISA documents, same day 2026-09-11

fixed The platform's 72-hour counter shows a due time 48 hours after your early-warning submission, not 72 (ENISA FAQ Q26). We had the direction of the gap wrong: file promptly and the portal flags you as overdue before the legal deadline, not after. Case page, deadline check, drafts and every public page now say so.
fixed The severe-incident form does have an awareness field, labelled 'Date and time when the incident was detected (UTC time)'. It is now marked as on the platform for incidents and pre-filled; only the vulnerability form lacks it (glossary: 'available in the next release').
changed Draft field set re-aligned row by row with ENISA's glossary v1.3 of 10 September 2026: added 'Details about the security update / corrective measure available' (required on the vulnerability final report), 'Please provide further information' (800 characters), the copied-forward status (C) on second and third filings, attack vector no longer asked on the early warning, incident occurrence time required on the 72-hour notification, and the platform's own character limits.
fixed Generated summaries state when you became aware, in words, and every generated sentence ends with a full stop.

v0.3.0 Launch day: the platform as it actually shipped 2026-09-11

changed ENISA's Single Reporting Platform opened today without an awareness field on its vulnerability form, and with a 72-hour counter that does not run from awareness. Awareness is now marked as not on the platform in vulnerability drafts, on the public field reference, in the export your Assigned Representative works from, and in the form-filler. We keep the authoritative awareness record; the case page shows both clocks.
added Free deadline check: enter when you became aware and when you filed the early warning, see your legal Article 14 deadlines next to the counter the platform will show you, and the gap between them. Runs in your browser, nothing sent.
added Free CRA Clock Check: drop a CycloneDX or SPDX file, see whether anything you ship is on CISA's known-exploited list today. No account, nothing stored, the same engine the paid product runs.
added ENISA guidance watch: we fetch the platform's pages every six hours and compare their text, so a change reaches us as an alert rather than as your complaint. Last checked and last changed are shown on the regulatory changelog.
added Registering on the ENISA platform is now a first-day onboarding step. You can file up to 20 notifications before your Assigned Representative is validated, so registering today holds nothing up.

v0.2.0 Closing a case honestly 2026-09-11

fixed Closing a case now stops its alerts. Previously an unfiled notification kept alerting after the case was closed, with no way to say what had happened to it.
added When you close a case with a notification still unfiled, we ask what happened, per notification. Filed elsewhere records where and when. Not filed stops the alerts but stays on your compliance report as a gap, because an authority should find your own dated account of it rather than a clean sheet. If the product turned out never to have been affected, awareness is retracted and the deadlines are voided instead.
fixed Dismissing a case whose clock was already running recorded its unfiled notifications as met on time, inventing filings that never happened and lifting the on-time rate. They are now voided.
fixed The VEX exports no longer assert a justification the manufacturer never gave. Where no machine-readable justification was recorded, the document carries your own words instead of a guessed one.
added Cases awaiting assessment can be dismissed together from the Cases list, with one shared justification recorded against each. A case whose clock has started is never closed in bulk.
fixed A deadline that was not filed no longer renders with the green badge meant for one that was. The compliance report gained a not-filed count, and a missed filing now drags the on-time rate down.

v0.1.0 Launch readiness 2026-09-09

added Weekly encrypted database backup to EU object storage, with the restore steps written down for the operator.
added Client IP resolution that understands Cloudflare, plus /api/client-ip so you can check what we see before you allow-list anything.
fixed Re-uploading an SBOM for a version no longer breaks its open cases. Existing matches are re-pointed at the new components instead of being orphaned.
fixed Drafts now pre-fill the CVE id from the case text when a case was declared by hand and has no advisory attached.
security Dependencies updated across the board, including uvicorn, sentry-sdk and python-multipart, and the CI secret scan tightened.

v0.0.7 Security hardening pass 2026-09-09

security Full code review of tenant isolation: every product, case, draft and evidence row is scoped to the account that owns it.
security Account administration (data export, deletion, API keys, members, settings, test alerts) requires a browser session. API keys cannot reach it.
security Every URL you give us (webhooks, Slack, Dependency-Track) is validated before we fetch it: HTTPS only, public hosts only, no redirects, size capped.
security Session lifetimes, CSRF handling and the billing flow reviewed and tightened.

v0.0.6 Advisories, drills and the compliance report 2026-09-09

added CSAF 2.0 advisory export and a plain-language customer advisory per case, plus a record of when and how you informed impacted users (Art. 14(8)).
added Drill mode: a rehearsal case that runs the whole process, sends real alerts and is excluded from your compliance statistics.
added Next action on every case, so nobody has to remember which of the three filings is due.
added Case owner: assign a case to a named person on the account.
added Printable compliance report for the whole account and for a single case, with JSON endpoints behind it.
added Free security.txt and disclosure policy generator at /tools/security-txt (Annex I Part II(5)), and a readiness item for it.
added Self-serve account export and deletion under GDPR, in Settings.
changed Alert emails are formatted HTML and Slack alerts use Block Kit, so the deadline is readable on a phone at 3am.
changed Drafts note that the SRP shows its own 72 hour counter from your 24 hour submission, while the legal deadline runs from awareness.

v0.0.5 Design system, billing and legal pages 2026-09-09

changed New visual design: glass surfaces, a calmer canvas and typography that stays readable on a phone.
changed Pricing page redesigned with a monthly and annual toggle that shows the saving per plan.
changed Billing panel shows your plan, the trial and a direct route to the Stripe portal.
fixed Stripe webhook handling corrected for stripe-python 15, so subscription changes apply immediately.
fixed Heartbeat digest no longer skips itself at midnight UTC.
added Privacy, terms, DPA and imprint pages with the governing law and the full list of recipients.

v0.0.4 Deployment hardening 2026-09-08

changed exploitclock.com set as the launch domain everywhere defaults are read.
fixed Schema creation is serialised across web workers with a database advisory lock, so a restart with several workers cannot race.
added Columns added to the models are applied on startup, so an upgrade does not need a manual migration step.
changed /auth renders as a page for browsers instead of returning JSON.

v0.0.3 Accounts, anchoring and integrations 2026-09-08

added Accounts with invited deputies: several logins share one account with the same access, and the evidence trail records who acted.
added The evidence chain head is sent to an RFC 3161 timestamping authority once a day, so a third party attests that the chain existed at that moment.
added ENISA EUVD exploited list as a second exploitation source, and NVD CPE matching for firmware and operating system components.
added GitHub Action for uploading an SBOM from CI, and import straight from Dependency-Track.
added Calendar (.ics) export per case as a fallback channel, and a detection latency metric from KEV publication to case.
added Sample product with a real SBOM and known-exploited components, so a trial has something to look at on day one.

v0.0.2 The CRA Article 14 product 2026-09-08

added Products, versions and SBOM ingestion for CycloneDX and SPDX JSON, with component identity taken from purl or CPE.
added Matching against CISA KEV, OSV and EPSS on a fifteen minute cycle, with EPSS treated as a prompt to look rather than evidence of exploitation.
added Cases: a known-exploited hit opens an assessment; confirming awareness starts the 24 hour, 72 hour and final report clocks.
added Drafts in the ENISA Single Reporting Platform field set, with the platform's own names, character limits and required or optional status per stage.
added Hash-chained, append-only evidence log with verification and an export bundle for a CSIRT or market surveillance authority.
added Escalating deadline alerts by email, Slack or Teams, webhook and the live dashboard, all off the request path.

v0.0.1 Foundations 2026-09-08

added Application skeleton: FastAPI, PostgreSQL, optional Redis, Auth0 login, Stripe subscriptions, WebSockets, health checks and EU hosting.
changed Ported from an earlier codebase of ours; the smart contract audit pipeline was deliberately left behind and every credential, product and price is new.