Why Your Vulnerability Report Titles Suck, and What to Do About It
What if I told you that your vulnerability reports might get overlooked or deprioritized during security triage because of the report title? Ya, it happens.
Think about it. A good title should be so compelling and clear that someone reading it can fully understand the issue immediately.
Do your report titles stand on its own and be this clear? Probably not.
So let’s fix that.
Why good vulnerability report titles matter
Good vulnerability report titles are important because they:
- Help accurately communicate the issue
- Allow people to understand the severity of the problem quickly
- Help prioritize reports and assign resources to address the issue
You want to write something so catchy that it compels people to want to fix the issue. That only works if you know who your audience is and what they care about.
Know your audience
Have you ever considered who will read your vulnerability reports anyways? Sure, you know someone will read it in security triage, but who are they? What is their role in the organization? What impact do they have on getting things fixed?
Who else might read it? How about their ability to affect change? What will motivate them to care?
The thing is, you just don’t know who will even see your report titles.
And you don’t know what motivates them.
If you read my article on The Security Researcher’s Guide to Reporting Vulnerabilities to Vendors, you already know you need to lead with empathy. There are people on the other end of these reports, and you just can’t know what is going on over there.
So your report title is critical to explain the issue’s complete story arc clearly and concisely.
A practical example of good vs. bad titles
Remember a few years back when the Internet went bonkers over the vulnerability in log4j on Apache? Here are some real report titles for this vulnerability. Which would you think is the “good” title from all of them?
- I found CVE-2021-44228 on your website
- log4j issue detected
- You’re vulnerable to log4shell
- RCE at https://[REDACTED]/REDACTED.jsp
- Unauthenticated attackers can cause remote code execution (RCE) on server [REDACTED] due to a vulnerable version of log4j used on /[REDACTED].jsp
Yeah, it’s pretty clear that the last title better articulates the issue and leads to a much more definitive remediation plan.
See it through the eyes of your audience. Not just the security triage team but the product managers who are responsible for deciding what technical debt gets scheduled to be fixed first and the developers who end up having to do the work.
What is the most useful title that motivates action? It’s in these moments where the right words can make all the difference. Make an effort to put extra thought into the title and get it right.
How to create great vulnerability report titles
Like any writing exercise, it’s good to follow some recipe or template pattern.
One of the more popular patterns is:
[VULNERABILITY TYPE] in [PRODUCT NAME] (CVE-XXXX-XXXX)
This formula might work if the Vulnerability Disclosure Program (VDP) scope is clearly articulated and the targets are static. However, I don’t really like this approach. It missed far too much detail that should be in the title.
I’d rather you explain who the potential attacker is, what they can do, and how they would go about doing it.
The pattern might look something like this:
[WHO] can do [WHAT] and [HOW]
The “WHO”
Every title should explain the entity or identity that can trigger the vulnerability and in which privilege context. This usually represents the attacker, but it doesn’t have to.
Some examples include:
- Authenticated user
- Unauthenticated user
- Administrator
- Employee / Staff
- Customer / Client
- etc
TIP: If it’s possible that more than one entity could represent the “who,” always go for the one that has the most damage potential or has the most technical or business impact. You can explain the other scenarios in the details of your report.
The “WHAT”
A vulnerability is meaningless unless it can be exploited to do harm in some way. The more damage potential and business impact, the more compelling it will be to fix.
There could be several different ways to demonstrate harm, so it’s important that you select one that is easiest to showcase the seriousness of the problem.
The “HOW”
Finally, we come to the how. It’s easy to say “by exploiting the vulnerability found” and get deeply technical, but that kinda misses the point.
Get technical in the details of the report, not the title.
This is the perfect opportunity to summarize what the vulnerability is and where it resides in the app stack so all stakeholders can understand if it applies to their work and how they may contribute to the fix.
Writing Tips for Good Vulnerability Report Titles
- Clearly articulate the issue in the titles, including who is affected, what vectors can be used, if exploit code exists, etc.
- Be precise but succinct with your wording – avoid words like “security issue” and try to focus on the practical implications.
- Make sure you use key terminology when appropriate, such as CVEs
- Include a call to action – prioritize or escalate if necessary.
- Be persuasive but not too salesy – good titles should compel people to immediately start looking into the issue instead of just skimming it over
A cautionary tale: Worry about information disclosure
So let me throw a wrench into the middle of this.
Yes, I want you to write titles that are so compelling and clear that someone reading it can fully understand the issue immediately. But you can’t use that in the subject line of an email to a vendor. 
If your title is as good as it can be, it could leak sensitive information about the vulnerability and its potential impact if you include it in an email. Instead, REDACT sensitive information in the subject line, but include the title in full in the encrypted report you will send to the vendor.
If that concept is new to you, I suggest you read my article on how to use GPG as a security researcher. It’s important that you protect your vulnerability reports and proof-of-concept exploits from being seen or tampered with by those who shouldn’t have access.
You can’t guarantee an email transmission won’t be intercepted on the way to triage. Assume it will be intercepted, and protect the sensitive information accordingly.
Conclusion
Crafting a good vulnerability report title is far more critical than you might think. It’s the first thing someone will read, setting the tone for the entire conversation.
So don’t let it suck.
Your title should clearly articulate who can trigger the vulnerability, what they can do, and how they would go about doing it. Keep this information concise but compelling so all stakeholders who read it get it… and want to take action… or maybe take some Tums. 
One last thing…
Did you find this article helpful? Then subscribe to the FREE API Hacker Inner Circle newsletter and join thousands of other developers, testers, and hackers who are leveling up their API security testing skills too.
Cya there!
The post Why Your Vulnerability Report Titles Suck, and What to Do About It appeared first on Dana Epp's Blog.
*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/why-your-vulnerability-report-titles-suck-and-what-to-do-about-it