Vulnerability reporting
What to write when they ask how someone reports a vulnerability
The row asks where a report goes, and whether anyone is paid to send one. Name the address someone reads. A support inbox can be the whole answer. If you do not run a bounty, say so. If there is no published place to send a report, say not yet. If you are still deciding, say so. Write an acknowledgment time only when someone will keep it.
This is a practical note for a security review, not legal advice.
What the row is asking
Reviewers ask how someone reports a vulnerability. They want the address a stranger can use, and whether you pay people to send reports. A scan schedule does not answer the inbox. How soon you tell the customer about an incident is a different clock.
EFROS, on a page that says Updated September 11, 2026, by Stefan Efros, CEO and Founder, asks: "B14. Do you publish a Vulnerability Disclosure Policy or run a bug bounty? What is the median time to remediate reported findings?" A citation block on the same page says "Efros, S. (2026, May)." This note uses the Updated line. The questionnaire is one EFROS says it uses on third-party risk assessments. This is their page, not a founder asking for help. A different question on the same page, A6, asks for scanning frequency and remediation times by severity. That scanning sentence is already in the penetration-test guide. B14 is the place a stranger sends a report, and how long a reported finding sits.
Teralo Pty Ltd, on a page that says Last Updated: October 2026, with no day, answers: "Do you have a vulnerability disclosure process? Report suspected vulnerabilities to support@teralo.co." The page names Ross Sanderson as a director and says the company is a small team. Headcount is "provided on request" and is not stated. This is the company answering its own assessment in public. The same page's penetration-test answers say they use automated testing, the most recent completed run was in July 2026, and they do not use a third-party firm. That row is the penetration-test guide. The disclosure line is only the address. A bounty is a second sentence, and this page does not claim one.
Valtik Studios, on a page whose footer says © 2026 Valtik Studios LLC and shows no published day, offers a template "to send to vendors, or adapt it to answer the questionnaires you receive." The meta author is Valtik Studios. Section 8 asks "Bug bounty program?" and "Process for handling third-party disclosed vulnerabilities." This is their template, not a founder asking for help.
Decryption Digest, by Eric Bang, Founder and Cybersecurity Evangelist, on a page that says Practitioner Guide May 20, 2026, and Updated July 1, 2026, asks "Q: Do you have a bug bounty or responsible disclosure program?" The Growth sample on that page: "We maintain a responsible disclosure policy published at [URL]. Security researchers who discover vulnerabilities may report them via [email/platform]. We commit to acknowledging submissions within [48 hours]." That 48 hours is his Growth template. It is not a reported clock from a named company. The patching numbers on this page are already in an earlier note. They are not repeated.
An older page, outside that window: SaaSFort, on a page that says March 7, 2026, byline SaaSFort Security Team, asks "Do you have a documented VDP or Bug Bounty program?", "Is your security.txt published (RFC 9116)?", and "What is your SLA for acknowledging and responding to external vulnerability reports?" Its minimum viable list says acknowledgment in 5 business days and an update in 30 days. Those are the firm's list. They are not a customer's clock. Do not paste the 48 hours or the 5 business days because a template printed them.
A comment on Hacker News, September 11, 2026, from hnd9q09qk4, on the story "HuggingFace: Security.txt" (story id 49659245): "Ran the disclosure inbox at a previous job and the biggest win from security.txt was just cutting the "hi I found a bug, is there a bounty" emails to sales. Put an expires date on it though, stale ones get ignored." They say they ran the disclosure inbox at a previous job. Employer is not named. This is not a founder filling a vendor form.
A post on r/cybersecurity, July 8, 2026, from u/PublicUniversity9586, opens "For those who run VDPs." Employer and headcount are not stated. The post says: "Trying to figure out how to best approach this situation so I'm not burning all my time trying to validate bunk reports." A comment the same day, from u/NebulaElectrical1467: "ask for 1-2 minute video pocs." Those are people who already have a program. No source in this set says a deal stalled because security.txt was missing.
What reviewers accept
Name the address someone reads. A support inbox can be the whole answer. Write that address only when it is true and someone will read what arrives.
If you do not pay people to send reports, say we do not run a bounty. Leave the bounty line off until someone will read what arrives. A program with no reader is a second inbox.
If there is no published place to send a report, say not yet. If you are still choosing whether you need a published address, say still deciding. Leave the address out until you have chosen it.
Write an acknowledgment time only when someone will keep it. The 48 hours on the July 1 page is Eric Bang's Growth template. The 5 business days on the March 7 page are SaaSFort's list. Neither one is a clock a named customer required. Leave the time out until a person will keep it.
A scan schedule, how soon a scan finding is fixed, and an independent penetration test are a different row. How soon you tell the customer about an incident is a different clock. The rest of the questionnaire is a different page.
The contact email on the public page can be the address, once you type it and decide reports go there. That email is not a disclosure policy until you decide it is the place reports go.
An honest gap is a complete answer. The answer that fails is a bounty, or a clock, that nobody will keep.
Answers you can paste
Use the line that is true. Replace the brackets. Delete anything that is not true. Write an address only when someone will read it. Write a time only when someone will keep it.
Reports go to this address
Report suspected vulnerabilities to [the address someone reads]. Write the address only when it is true, and only when someone will read what arrives.
We do not run a bounty
We do not run a bounty. Reports still go to [the address someone reads]. A bounty is a second sentence. This one says we do not pay people to send reports.
Not yet
We do not have a published place to send a vulnerability report. We will not write an address, a bounty, or an acknowledgment time we do not keep.
Still deciding
We are still deciding whether we need a published place to send a vulnerability report. We will not name an address, a bounty, or an acknowledgment time we have not chosen.
Acknowledgment time
We acknowledge a report within [the time someone will keep]. Write this only when someone will keep it. Leave the time out until that person exists.
These are other rows
Where a report goes is this sentence. An independent penetration test, how soon a scan finding is fixed, and how soon we tell you about an incident are separate sentences.
What not to write
Do not paste 48 hours or 5 business days because a template printed them.
Do not write that you run a bounty unless someone will read what arrives.
Do not write a disclosure policy you have not published.
Do not write an acknowledgment time nobody will keep.
Do not answer the penetration-test row, how soon a scan finding is fixed, or how soon you tell the customer about an incident here.
Do not put a bounty, a disclosure policy, or an acknowledgment time on the vendor row. There is no field for them.
Do not invent an address, a bounty, a clock, or a deal that stalled because security.txt was missing.
Where this answer lives
Keep these sentences in the questionnaire answer you control.
The public page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it.
The contact email can be the address, once you type it and decide it is where reports go. The contact email is not a disclosure policy until you decide it is the place reports go.
If the editor already knows a company, a suggestion can offer a location or a public agreement link, and only after you use it.
There is no field for a vulnerability-report address, a disclosure policy, a bounty, or an acknowledgment time. The page does not fill this row. The page does not store a disclosure policy, a bounty, or an acknowledgment time.
That suggestion does not write a disclosure policy, a bounty, or an acknowledgment time.
If you want the longer notes
An independent penetration test, and how soon a scan finding is fixed, are a different row from where a report goes. What to write is in the penetration test guide.
How soon you tell the customer about an incident is a different clock from where a report goes. What to write is in the incident notification guide.
How to answer the rest of a vendor security questionnaire is in the security questionnaire guide.
Related guides
Optional next step: a living page
The sentences above are enough for the row in front of you.
If you want one link for the companies that handle customer data, Trust Prep is a page you edit when a company changes. The page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it.
The contact email can be the address, once you type it and decide reports go there. The page has no field for a disclosure policy, a bounty, or an acknowledgment time. It does not store those. Those sentences stay in the answer you keep.