Vulnerability triage process: how we analyze every security report
By Kike Gandia · Co-Founder & CEO, OSCP
Vulnerability triage isn't a quick read-through. Every report goes through a series of technical steps that confirm the vulnerability is real, assess its impact, and deliver the information the remediation team needs to act without further investigation. Transparency about how we work.
Step 1: Receipt and initial classification
When a report arrives, the first step is a full technical read-through. At this stage we determine:
- Is it within the defined scope? If not, the researcher gets an immediate response with a detailed explanation.
- Is it a duplicate? We cross-check it against the program's history of active and closed reports.
- What type of vulnerability does it describe? IDOR, XSS, SQLi, business logic, information disclosure, authentication…
- How detailed is the report? Does it include a PoC, reproducible steps, screenshots?
This initial classification lets us prioritize: reports that look critical or high go first.
Step 2: Technical reproduction of the attack
Reproduction is the core of triage. We attempt to replicate the attack the researcher describes:
- We follow the researcher's steps exactly as described.
- If the steps are ambiguous, we ask for clarification before assuming it isn't reproducible.
- If the attack requires specific conditions (an authenticated user, prior data), we create them in the test environment.
If the vulnerability isn't reproducible with the steps provided, we don't reject it immediately: we request more information and give the researcher time to respond. We only close it as "not reproducible" if, after a reasonable back-and-forth, we still can't verify the finding.
Step 3: Contextualized impact analysis
Reproducing the attack confirms the flaw exists, but it doesn't determine its real impact. At this stage we assess:
- What can an attacker do by exploiting this vulnerability? Access other users' data? Modify records? Escalate privileges?
- Does the affected system process sensitive data (personal, financial, health)?
- Are there compensating controls (WAF, rate limiting, monitoring) that reduce the real risk?
- How difficult is it to exploit this at scale versus against a single target?
This contextualized impact assessment can significantly change the final score relative to the base CVSS.
Step 4: Scoring and handoff to the remediation team
With reproduction confirmed and impact assessed, we calculate CVSS 4.0 (base and environmental, when we have enough context about the environment) and check EPSS for the CVE, if applicable.
The handoff to the remediation team includes:
• A clear description of the finding in technical terms.
• A documented PoC: exact steps to reproduce the attack.
• Calculated CVSS 4.0 with justification for each metric.
• EPSS and context on active exploitation in the wild.
• A remediation recommendation specific to the client's technology stack.
• Prioritization against the active backlog: what should be patched first.
FAQ
On average, how long does triaging a report take?
It depends on complexity. A well-documented XSS or IDOR report can be triaged in 1-2 hours. A complex business-logic report, a vulnerability chain, or an infrastructure finding can take 4-8 hours. Reproduction is the most time-variable phase.
What tools do you use for triage?
The same ones we use for pentesting: Burp Suite Pro for web analysis, API analysis tools, sandbox environments for controlled testing, and access to threat intelligence platforms to check EPSS and active exploitation context. Triage isn't just reading — it involves attacking.
Can you triage reports for every type of vulnerability?
Yes. Our team has experience with web vulnerabilities (OWASP Top 10 and beyond), APIs, mobile applications, infrastructure, cloud, Active Directory, and business logic. For highly specialized vulnerability types (hardware, firmware, OT/ICS), we evaluate on a case-by-case basis.
Related service
QuantumSec's vulnerability triage service