If you have found a vulnerability and want to send it to the company so they can validate and fix it, you need to write a report.
Reports are typically reviewed first by the Secur0 triage team and then by the company’s technical team.
If your report is to a program with the “CVE” label, then the report will also be reviewed a third time, specifically by the Secur0 triage team acting as a CNA. For more information on this you can consult our CVE faq.
To write a report correctly you need to bear in mind 5 questions:
- What category of flaw you want to describe
- Where the flaw occurred
- How the flaw occurred
- What impact has been demonstrated
- What impact has not been demonstrated but may exist If your report answers all of these questions correctly, your experience of the triage process will be simple and fast.
Below we go through one by one how to write these categories:
What category of flaw you want to describe
Reports must always have an executive and technical summary describing the vulnerability in broad terms by taxonomic type (for example reflected XSS, IDOR…) and under what conditions it occurred. There is no need to go into excessive detail.
Where the flaw occurred
All Secur0 report forms will ask you for an endpoint and domain. You must add them so that the triage team can validate the vulnerability quickly.
How the flaw occurred
Every report must contain a proof of concept. Proofs of concept have a relatively strict format: they must be a numbered list of simple steps. Do not worry about what counts as one step or two, just do not submit a narrative paragraph instead of a proof of concept.
We also have a payload field that lets you communicate exact payloads, PoC scripts or HTTP requests in plain text.
What impact has been demonstrated
We need to know the impact both in prose and in a standard format. At Secur0 we use CVSS 4.0; filling it in on reports is optional but strongly recommended.
We also publish (and allow public dispute of) our interpretation of the standard, so you can consult past cases and know in broad terms what severity we will assign to a flaw.
You can read this record on our EGAD! Docs page.
What impact may exist
At Secur0 we will calculate severity solely on demonstrated impact, or on impact that is immediately and obviously escalable (for example Wordpress admin compromise -> RCE in most cases).
It is nonetheless important that you describe the potential impact, since that way the company can properly understand its situation and, in the event of extreme risk, can ask the triage team to raise the severity.
How not to behave in a report
There is a set of behaviours that are not advisable, either because they degrade how things work for everyone or because they prevent triage and remediation from being carried out properly. All of these situations may be sanctioned where appropriate.
Fixed rules
They are published here.
Contacting the company through external channels
Every organisation has confirmed a VDP or BBP agreement with Secur0. In the case of FOSS developers it is possible that they will not respond quickly. That will never be an excuse to try to contact companies and organisations, or to pressure them, through external channels.
Excessive pings on reports
All parties try to work as fast as possible, and we understand that researchers want their recognition quickly. That is why we accept pings or Discord tickets asking for updates, but the interval of two weeks or 14 working days between update requests must be respected.
Breaching any rule of conduct
Harassment, doxxing, attacks based on personal identity, etc., between any parties is strictly forbidden and will be answered with full bans from the Secur0 platform.
Recommendation
Use of AI slop
We understand that generating arguments with LLMs is tempting when a triager gives a lower CVSS 4.0 score than we were hoping for, but you should bear in mind the sycophantic nature of LLMs, which will always try to side with whoever is interacting with them.
While we invite you to argue with triage if you believe the score is incorrect, we ask that you trust our experience in application security and vulnerability management.
While we will not get into metacognitive arguments such as whether “LLM writing really cannot be detected”, the triage team reserves the right to stop responding to technical discussions if the arguments have become circular, excessively dense and/or devoid of technical validity.
Excessive descriptors (“Claudish” style)
We understand that describing vulnerabilities in code analysis contexts is complex, and that many researchers work either assisted by LLMs or using them as autonomous agents.
Bear in mind that the triage process includes a human reading of the report, and that although we have LLM tooling we never accept a report on its inference alone.
Reports containing traces with excessively verbose code inside narrative text paragraphs are clear examples of “Claudish” style descriptions.
Although traces are necessary for triage, we ask that they be kept solely in the proof of concept and/or payload fields.