Pulseguard
Under Attack?Find something in ours, and we will pay for it.
We sell a product that tells people what is wrong with their infrastructure. It would be difficult to do that honestly without inviting the same treatment. The bands, the response targets, and the rules are all published below, before you spend an evening on it.
A programme is only worth entering if the researcher can predict what happens.
Most disclosure pages ask for reports and promise nothing back. No bands, no timelines, no statement about legal action. The result is predictable: the researcher who finds something has to weigh an unknown reward against an unknown risk, and the rational move is to not send it.
So everything on this page is a commitment rather than an aspiration. Reports are acknowledged by a named person within a day. Triage is done within five, and a rejection comes with the reasoning, because a report dismissed without explanation is how programmes lose the people who were finding real things.
We would also rather be told plainly than told carefully. If you found it by accident, send it anyway. If it is only a vulnerability when chained with two other issues, send the chain. If you think our triage is wrong, argue with us, and if you are right the severity moves up rather than the conversation ending.
What a report is worth, and what happens after you send it.
Bands are a guide rather than a ceiling. A report that chains a low finding into real impact is paid for the impact it demonstrates.
- ≤ 24hAcknowledgedA person confirms receipt and tells you who is handling it.
- ≤ 5 daysTriagedReproduced or rejected, with the reasoning either way.
- ≤ 30 daysFixedCritical and high findings are fixed or mitigated, and you are told which.
- On fixPaid and creditedReward paid, and public credit if you want it.
- Your own test account, created for the purpose
- Automated scanning at a rate that will not degrade service
- Reporting anything you find by accident, without penalty
- Accessing, modifying, or exfiltrating another customer's data
- Denial of service, resource exhaustion, or spam
- Social engineering of staff, customers, or suppliers
- Physical attempts against offices or hardware
Stay inside these and we will not pursue legal action over your research. Go outside them and the safe harbour does not apply.
What you can test
The dashboard and API
The application itself, and every endpoint behind it.
Authentication, session handling, and above all the tenant boundary: anything that lets one organisation read, modify, or infer another organisation's projects, findings, or evidence is the highest value thing you can find here, and it is graded accordingly.
The agent
The binary that runs on customer servers, and how it talks to us.
Enrolment and credential handling, the update path, privilege boundaries on the host, and the transport. An agent that can be made to run attacker-controlled code, or to accept an update it should have rejected, is a critical finding regardless of how many steps it takes.
Public infrastructure
The marketing site, the edge, and anything else we expose on purpose.
Hosts and services under our own domains are in scope. Anything you reach through them that clearly belongs to a third party is not, and if you stumble into it, stop and tell us rather than continuing to see how far it goes.
Reports we will not pay for
Scanner output without impact, and issues with no path to a victim.
Missing headers, weak TLS suites, version disclosure, self-XSS, missing rate limits on harmless endpoints, and anything whose proof of concept requires the victim to already be compromised. If you can demonstrate a real path to impact from one of these, that changes the answer and we would rather see it.
Out of scope entirely
Other customers, availability, people, and buildings.
Never touch another customer's data: create your own test organisation and stay inside it. No denial of service or resource exhaustion, no social engineering of staff, customers, or suppliers, and nothing physical. These are the boundaries the safe harbour depends on.
What turns a report into a payment.
Reproduction
The exact steps, in order, from a clean account. If we cannot reproduce it, triage stalls, and that is the most common reason a good finding gets stuck.
Impact
What an attacker gets at the end of it. Severity is graded on demonstrated impact, so say what the payload would have been, not just that one is possible.
Evidence
Requests, responses, and a short video or screenshots. Redact anything sensitive you happened to touch, and tell us that you did.
Restraint
Prove it and stop. Pulling one record shows the bug; pulling ten thousand is an incident, and it moves the report outside the safe harbour.
Send it to us.
Encrypted mail is welcome, plain text is fine, and you will hear back from a person within a day rather than from an autoresponder.