A finding you cannot reproduce is a rumour.

A scanner tells you which versions are old. It cannot chain three low-severity issues into an account takeover, it cannot reason about your business logic, and it cannot tell the difference between a vulnerable library you import and a vulnerable library you actually call. Scanning is a control you should run continuously and automatically. Testing is what tells you whether the controls work.

Not without asking. The rules of engagement are written before anything starts and they name the destructive classes explicitly: denial of service, data modification, credential lockout, social engineering of named staff. Anything in those categories happens only against a non-production environment or with written go-ahead, and there is a documented stop procedure with a phone number attached.

Yes. An attestation letter suitable to share with a customer or an auditor, describing scope, dates, methodology and remediation status, without disclosing the findings themselves.

For breadth, yes: enumeration, correlating one host’s behaviour against another, reading more source than a person can in the time. Never for the claim itself. Disclosure programs are currently drowning in AI-written reports that cite functions which do not exist and debugger output that was never captured, and two well-known open-source projects have curtailed their bounty programs over it. Our own research harness enforces the counter-rule mechanically: a finding cannot be written up unless every endpoint, parameter and response in it maps to a request we actually sent. You will get fewer findings from us than from a tool, and you will not spend your engineers' time disproving them.

We will, but we will also tell you that an independent tester is worth more. Testing your own work has a real blind spot: you inherit the assumptions you made while building it. For anything where the assurance is the point, use someone else, and we are happy to be the someone else for a system another firm delivered.

Probably not yet, and the honest sequence is disclosure policy first, paid bounty later. A vulnerability disclosure policy costs you a published page, a security.txt and a commitment to answer; it converts the finder who was going to tell you anyway from a legal risk into a report. A bounty adds money, and money buys volume rather than quality. The question that decides it is not budget, it is whether you can absorb the queue: an engineer who can reproduce a claim, a path to a fix with an owner and a date, and someone willing to write "not a vulnerability" and defend it. If a report today would sit unanswered for three weeks, a bounty will make that visible to the entire researcher community rather than fix it.

The programs that publish numbers say so. curl ran its bounty from 2019 and paid out over $100,000 across 87 confirmed vulnerabilities; its confirmed-report rate ran above 15% for years, fell below 5% during 2025, and the project ended the bounty on 31 January 2026 — then went back to accepting reports, without money, a month later. Nextcloud suspended its payouts in April 2026 for the same reason. The lesson is not that disclosure is finished, it is that the reward was paying for volume and the maintainers were paying for triage. If you launch one, expect the triage cost to be the real budget line, write a rubric that lets you close a report quickly on the threat model, and require reproduction that names a request the reporter actually sent.

An acknowledgement inside a stated window, a decision, and no legal threat for work that stayed inside your published scope. That last one is the part that has teeth: a policy without a safe-harbour statement is an invitation to a researcher to accept legal risk on your behalf, and most will simply not take it. Federal civilian agencies have been required to publish a policy that says this since CISA's Binding Operational Directive 20-01 in 2020, and the language there is a reasonable model for a private program.