Security

You're asking us to watch your infrastructure, which means telling us where it lives. This page covers how the service is built, how we test it, and how to tell us when we've got something wrong.

1. How the service is built

Authentication

There are no passwords here and there never will be. Sign-in goes through Discord, GitHub or Google, so there's no password for us to leak and no way for us to become the weak link in your password reuse. Session tokens are stored as hashes, which means a stolen copy of our database still can't be used to forge a login.

The edge and the origin

Traffic reaches us through a CDN and web application firewall. The origin refuses anything that didn't come through it. That's enforced with a shared secret rather than an IP allowlist, because CDNs pull from addresses outside their published ranges and an allowlist fails silently when they do. TLS terminates at both hops.

Keeping things apart

Active checks don't run on the machine holding the database. They run on separate probe nodes that store nothing and hold no secret beyond their own credential, so a compromised probe reveals which addresses it was asked to check but not who asked. The help desk is a third machine with no public web address at all, reachable only over a private network between our own servers.

The boring parts

Every server runs the same hardened baseline, applied from version control rather than by hand: key-only SSH with root login off, automatic security patching, host firewalls that deny anything not explicitly allowed, kernel and network hardening, audit logging, and per-container capability limits so a compromised process reaches as little as possible. Secrets are encrypted at rest in our configuration repository and never committed in the clear.

Your data

A public creature never gives away its target. Public pages show a name, species, age and streak, never the URL or host behind it. What we store, where it lives and how long we keep it is in the Privacy Policy.

2. How we test it

• Automated tests run on every change. That includes the request-forgery protections around user-supplied URLs and webhooks, which are what stop someone using our probes to reach somewhere they shouldn't.
• Dependency updates go in continuously, and operating system security patches install themselves.
• Security review before release, with findings written down and tracked rather than fixed quietly.

AI-assisted development and review

Much of this codebase is written and reviewed with AI assistance, and we deliberately use more than one provider. Models have different blind spots, so a second opinion from a different vendor regularly catches something the first one waved through. It's genuinely good at the tedious end of security work: spotting an unchecked input, a permission wider than it needed to be, a branch of the state machine nobody wrote a test for.

It is also confidently wrong on a regular basis, and will invent problems that don't exist while missing ones that do. So nothing ships on its say-so. A human reads the diff, and findings get verified before they're treated as real. We mention it because you're entitled to know how the thing watching your servers gets built.

Penetration testing

We don't currently commission a third-party penetration test. We're small, and an annual external engagement isn't something we fund yet. It's on the list as the service grows, and this page will change when that happens.

If you're evaluating us for something that needs an independent assessment, talk to us first, so you can make that call with accurate information.

3. Security researchers

We welcome reports. What follows is the permission slip and the boundaries. Read it before you start and you have our side of it in return.

What you get from us

• Safe harbour. We won't pursue legal action, or ask anyone else to, over security research carried out in good faith and within this policy. If someone else comes after you for it, we'll say plainly that the work was authorised.
• An acknowledgement within 72 hours, written by a person.
• An assessment within 7 days: whether we reproduced it, how we rate it, and roughly when we expect a fix.
• Credit on this page when the fix ships, under whatever name or handle you like, or none at all.
• No gagging. Give us a reasonable window before publishing and we won't ask you to stay quiet indefinitely. Ninety days is a fair default. If something is going to take longer we'll tell you why rather than let the clock run out in silence.

There's no paid bug bounty. We'd rather say so up front than have you spend a weekend expecting one.

In scope

• kerchunk.io and its subdomains
• The API, heartbeat ingest, badge and status endpoints
• The familiar agent, which is open source

Out of scope

• Infrastructure our users asked us to monitor. Those addresses belong to other people. Finding one in our service is not permission to touch it, and doing so ends the conversation.
• Custom domains belonging to users, which point at us but aren't ours.
• Third-party services we depend on. Report those to the provider concerned.

Please don't

• Run denial-of-service tests, or scanners heavy enough to degrade the service for other people. We're a small service on modest hardware, and from where we're sitting a load test looks exactly like an attack.
• Touch data belonging to anyone else. Use your own account. If a flaw exposes someone else's data, stop at the point you've proved it and tell us what you saw.
• Phish or pretext us, our providers or our users. Physical access is out of scope too.
• Publish before we've had the window above.

What makes a report useful

Enough for us to reproduce it: the endpoint, the steps, what you expected and what actually happened, and why you think it matters. A rough sense of impact helps us prioritise honestly. Screenshots or a short recording are welcome. If you're unsure whether something counts, send it anyway. We'd rather read a few non-issues than miss a real one.

Things we'll probably decline: missing security headers with no demonstrated impact, raw scanner output nobody has verified, outdated-library findings with no working exploit path, and anything that needs a compromised device or someone standing in front of the hardware.

4. How to reach us

• Security reports: security@kerchunk.io
• PGP: coming soon. Until a real key is published, do not treat /.well-known/pgp-key.txt as a usable key. Plaintext reports get read promptly.
• Machine-readable: /.well-known/security.txt (RFC 9116)

Reports go into the same help desk as everything else, so an acknowledgement is tracked against the clock rather than depending on someone remembering. It runs on our own server, reachable only over a private network between our machines - not a third-party support platform.

You can write one up on the contact form if you'd rather not compose an email - it asks for severity and where to look, and goes to the same inbox as security@kerchunk.io. For anything that isn't a security issue, pick a different topic on the same form.

5. Thanks

Nobody yet. This page is new. When someone reports something real their name goes here, unless they'd rather it didn't.