DevKit Dossier

Security

Last updated: 2026-10-19

This page describes how we protect the records you keep in DevKit Dossier; Annex II of our Data Processing Addendum lists the measures we commit to. Section 12 lists what we do not have yet. Questions and reports: security@devkit.dev.

  1. Where the Service runs. DevKit Dossier runs on DigitalOcean in Frankfurt, Germany: the application server, its database and our nightly backups are all in DigitalOcean's FRA1 datacenter. DigitalOcean also backs up the database every day and keeps those backups for seven days. The database is not reachable from the internet: a connection attempt from outside gets no answer.
  2. Encryption. devkit.dev is served only over TLS 1.2 or 1.3: plain HTTP requests are redirected to HTTPS, older TLS versions are refused, and browsers are told to use only HTTPS for this site for a year (HSTS). The Service talks to its database and to its providers (email delivery, backup storage, vulnerability data) only over TLS, and it checks the database server's certificate and name. At rest, DigitalOcean encrypts our database (LUKS) and our backup storage (Spaces); our backup files are also encrypted with our own key before they leave the server. Our pages cannot be shown inside another site's frame, and a link to another site does not pass on the address of the page you were on.
  3. Signing in and keys. You sign in with a link sent to your work email. There are no passwords; a link works once, expires after 15 minutes, and we keep only a hash of it. API keys are shown once, when you create them, and we keep only a hash of each key. Any member of the account can revoke a key, and a revoked key stops working at once. Each user can sign out on every device at once. Removing a member from the account ends that member's sessions immediately and is recorded in the audit log. The session cookie is sent only over HTTPS, cannot be read by page scripts and lasts at most 30 days; actions in the account refuse requests sent from other sites, and sign-in requests are rate-limited.
  4. Your account's boundary. Each account sees only its own records: every page and API request is answered from the signed-in user's or the API key's own organisation, and automated tests ask for another organisation's records and must get "not found".
  5. Backups. Every night the database is copied, encrypted with age on our server as it is read, and stored in DigitalOcean Spaces in Frankfurt; no unencrypted copy is written to disk. Each copy is encrypted to the public half of a key pair: opening it needs the private half, which only DevKit holds, away from our servers; the provisioning step refuses to write the server's settings if a private key of that kind appears among them. We restore a backup into an empty database to check that it opens and is complete; the first drill ran on 9 October 2026, and we repeat it monthly.
  6. Audit log. Your account keeps an audit log of who did what and when, without IP addresses. Every member can read it in the settings and download it as CSV, and an evidence pack carries the entries about its product and period. Audit entries can only be added: the application's database role may not change or delete them, and a database trigger refuses any change; they are deleted only with the whole account. That role has only the rights the application needs: it cannot create, alter or drop tables.
  7. Our own supply chain. We run DevKit Dossier on itself. For every version we release, CI builds the image again from the same commit, makes its SBOM with Syft (CycloneDX) and uploads it into DevKit Dossier, where it is matched against new vulnerability data every day, like a customer's. Every release fetches the current base images (Python, Caddy) from their registries, so the publishers' security fixes reach the server with each release; every Monday the running release is rebuilt the same way, so those fixes also arrive in weeks without a code change. Our Python dependencies are checked against public vulnerability data every day, and the check counts as passed only if it also catches a known-vulnerable test package. Security updates of the server's operating system, Docker included, install automatically every day.
  8. What leaves our systems. We never send your component list, package names or versions to third-party APIs: vulnerability databases are downloaded to our servers and matched there. Three providers process personal data in your records on our behalf, as Annex III of our DPA lists: DigitalOcean (hosting, Frankfurt), Postmark (email delivery, United States) and Sentry (error reports). Alert emails carry counts, product names and versions only, never package names or advisory IDs, and none of our emails track opens or clicks. Error reports leave out request contents, local variables, user identities and IP addresses, and go to Sentry's EU data region: in production the application refuses to start with a Sentry address outside it.
  9. Retention and deletion. When a subscription ends, the account stays readable for 30 days so you can export everything, and a daily job deletes its data within 90 days of the end. You can delete a product or a version yourself, with everything recorded for it, while your subscription runs and for 30 days after it ends; the deletion is recorded in your audit log. We delete other individual records, such as a single uploaded SBOM, within 14 days of your request. Access logs, which hold IP addresses, are deleted within 30 days, and error reports within 90 days.
  10. Monitoring and incidents. Every morning an automated check runs our acceptance tests, about two thousand, against the live site. An external service monitors our public pages and alerts us when they stop answering, and errors in the Service are reported to us automatically. If a personal data breach affects your records, we tell your account's users by email without undue delay and no later than 48 hours after we become aware of it.
  11. Reporting a vulnerability. To report a vulnerability in DevKit Dossier, write to security@devkit.dev: every message opens a ticket in our support inbox and notifies us. Our security contact is also published at /.well-known/security.txt. We do not pay bounties; please give us reasonable time to fix a problem before you publish it.
  12. What we do not have yet. We have not had an external penetration test yet, we hold no ISO 27001 or SOC 2 audit report, and there is no web application firewall in front of the Service. Sign-in has no second factor: the email link is the only one. There is no public status page.