Security

Two things live on this page. How to tell us about a problem in Seatbelt, and the policy we hold ourselves to when we find a problem in someone else's code. If you are a maintainer who just received a report from us, the second half is the part you want.

Reporting something in Seatbelt

Email security@withseatbelt.com. That address is also published at /.well-known/security.txt so you can verify it belongs to us.

Tell us what you found, how to reproduce it, and what an attacker gains that they did not have before. A working proof of concept helps more than a severity score. If you are not sure whether something counts, send it anyway and we will tell you.

What we promise you in return:

• A human reply within three working days. Not an autoresponder.
• Credit, if you want it. Tell us the name or handle to use, or tell us you would rather stay anonymous. We will ask before publishing either way.
• No legal threats. See safe harbour below.
• We will tell you what we decided and why, including when we decide something is not a vulnerability. A clear no beats silence.

Safe harbour

If you make a good faith effort to follow this policy, we will not pursue or support legal action against you, and we will say so publicly if anyone else tries. Good faith means: do not access, modify, or destroy data that is not yours; stop as soon as you have established that a problem exists rather than seeing how far it goes; do not degrade the service for anyone else; and give us a reasonable chance to fix things before going public.

If you are unsure whether a specific test crosses a line, ask first. We would much rather answer a question than argue about it afterwards.

How we disclose what we find

We scan software and we find things. When what we find is in code we do not own, this is what we do.

The maintainer hears first

Always privately, and always before anyone else. We use a project's own stated channel if it has one. If it does not, we ask for a private channel before sending any detail, and we do not put findings in a public issue tracker.

Ninety days, and we mean it as a starting point

We hold publication for ninety days, or until a fix ships, whichever comes first. That number is a starting point for a conversation, not a deadline we drop on you. Most software is maintained by people doing it around a job. If you need longer, tell us and we will work it out. We would rather a fix landed late than early and wrong.

We will move faster only if a problem is already being exploited, or already public. We will not accelerate because a publication date is convenient for us.

We say what we did not verify

Every report we send separates what we reproduced from what we inferred. If we could not test something, we say so in the report rather than implying we did. If part of a finding rests on documentation rather than an observed result, that sentence is in the report too. Overstating a finding to a maintainer is the fastest way to waste their time and ours.

We bring a fix, not just a bug

Every report includes a specific suggested change, and we will review a patch or test one if that helps. A report that creates work without reducing it is not much of a contribution.

We tell you what tooling we used

Our reports state plainly how the finding was discovered, including where automated scanning or a model was involved and where a person read the code. Maintainers are currently drowning in machine-generated reports of little substance, and several projects have closed their intake because of it. You are entitled to know which kind of report you are holding. Everything we send has been read and confirmed by a person who can explain every line of it.

What we will not do

• We do not test against your users. We reproduce on our own machines, against copies and files we created. We do not probe live deployments and we do not touch anyone's data.
• We do not use credentials we find. If a scan surfaces a live secret, we report it and we do not try it.
• We do not publish working exploits against versions people are still running. The mechanism is enough to explain a finding.
• We do not name victims. Anything we publish about patterns across many projects is aggregated and anonymised.
• We do not ask to be paid before disclosing. If a project runs a bounty we are happy to follow its process, but the report comes either way and it is never conditional.

If we cannot reach you

Silence is the hard case. We will try a second channel, and we will keep trying for longer than the ninety days if a project looks maintained but busy. If a project appears abandoned and the problem affects people who depend on it, we may ask a coordinating body such as a CVE Numbering Authority to assign an identifier so that downstream users can at least see it. That is a last resort and we will tell you we are doing it.

Contact

security@withseatbelt.com for anything on this page, in either direction.