The Vulnerability-Disclosure Read: Deep Skill, Padded, or Noise

You are holding a security candidate's resume with a row of CVE numbers, a couple of advisory acknowledgments, and a bug-bounty handle with a leaderboard badge. Before you spend an interview slot, you need to know whether that record proves real skill. This guide is for engineering managers, technical founders, developer-relations leads, and technical sourcers who have to turn a messy pile of CVE IDs and badges into a repeatable three-way verdict: deep skill, padded, or noise. It gives you the dimensions that matter, how to score each one, and what the combined score means.

The read matters more than it used to because the artifacts have gotten noisier. Mass CVE assignment, self-reported severity, and an AI-driven surge in low-quality bounty submissions have all pulled the headline numbers away from the underlying skill. The job here is to put each dimension back on a source you can defend to a panel.

Why a raw CVE count is no longer a skill signal

A CVE credit proves authorship of a record, not demonstrated skill, and the gap between the two has widened sharply. Roughly one-third of reviewed CVEs are unconfirmed or contested by product maintainers, per Dr. Aram Hovsepyan's review of work by Schoegel and colleagues, whose quantitative analysis found nearly one-third of the CVEs they studied were either unconfirmed or disputed. Carry one caveat with that figure: their dataset was drawn from other academic studies, not a random sample of all CVEs, so one-third is a defensible headline, not an ecosystem-wide census.

The bigger shift is who assigns. The Linux kernel CNA is the canonical mass-assignment case. Because the kernel sits at a layer where almost any bug might be exploitable, the assignment team is deliberately overly cautious and numbers almost any bugfix it identifies. In one May the Linux team issued over 1,100 CVEs, more than professional bug-bounty programs run by Trend Micro ZDI, Wordfence, and Patchstack combined. The team's own counter-framing is that it allocated 863 CVEs from 16,514 commits between v6.7.1 and v6.8.9, a 5% hit rate - but even that produces a flood, and over 200 CVEs went out in the first four days of CNA operation with no demonstrated security impact.

The practical consequence: the moment you see a long CVE list, the first question is not "how many" but "how many carry a non-kernel-CNA Source and a maintainer-confirmed security impact." Volume collapsed as a signal the day the kernel became a CNA.

The dimensions and what each one proves

Score the record across three dimensions, each with its own source and its own failure mode. Read them in order, because credit verification gates everything downstream.

Each dimension has a clean source of truth. Severity and independence resolve against the live CVE record and corroborating artifacts. Reputation resolves against the platform's Signal metric, not its reputation total. Credit resolves against two specific fields in the CVE JSON record. If any dimension is unverifiable, that is itself a finding, not a blank.

How to verify who actually got CVE credit

Pull the live record and read two fields: the assigning authority and the credited researcher. In the CVE JSON record there can be only one CNA container per record, because there can be only one assigning CNA, and on NVD and MITRE display this authority appears as the Source field - GitHub, Inc., for example, is the CNA shown as the Source on records it numbers. The credited researcher lives in a separate credits array, which the schema defines as statements acknowledging specific people, organizations, or tools for work related to the CVE. The array requires a minimum of one item and can hold many.

That last point is where a padded record hides. Being listed among five co-credits reads as solo discovery to an untrained eye. Count the other names in the credits array and find the primary reporter named in the underlying advisory. A single co-credit on someone else's finding is a weak signal; a self-credit as sole reporter on a vendor-CNA record is a strong one.

The verification procedure is mechanical. Pull the live record, read the Source and Assigner to see exactly which authority numbered it, then compare the record's own description against the NVD enrichment. Remember that assignment of a CVE number is not a guarantee it becomes an official entry - a number can be improperly assigned or duplicate an existing one.

The disputed and mass-assigned tags

Disputed status is tracked formally. The CVE Record Dispute Policy, published in 2022, provides an escalation pathway up through CNA, Root, Top-Level Root, and the Council of Roots, and a DISPUTED tag can be indefinite. A disputed CVE cited as a win is a direct red flag. Mark any Linux-kernel-CNA record or backfilled entry as mass-assigned, and any carrying a DISPUTED or REJECTED tag as disputed, before you score anything else. A vetted record instead shows a project that confirmed the bug posed a security risk before issuing the CVE.

How to read a bug-bounty profile without being fooled

Reputation is a running total that climbs with volume; Signal is the metric that reveals discipline. On HackerOne, Signal is the average reputation per report, an aggregate representation of report validity, measured on a scale from -10 to 7 corresponding to triage states from Spam to Resolved. Impact is the average reputation per bounty, an aggregate representation of report severity, measured from 0 to 50. Self-closed and duplicate reports are excluded from the Signal calculation.

The exclusion is what makes Signal hard to fake and reputation easy to inflate. A researcher who withdraws weak reports keeps Signal clean, so Signal reveals discipline that a reputation total hides. There is now a concrete baseline: Node.js updated its HackerOne program to require a Signal of 1.0 or higher to submit vulnerability reports. Treat 1.0 as a floor, not a target. One caveat matters: Signal and Impact only calculate when there are more than three closed reports or three bounties, so a sparse profile will show no Signal at all, which is a reason to read the reports directly rather than to penalize.

These reputation values are practitioner-documented rather than official HackerOne figures, so use them to understand the shape of the incentive, not as exact arithmetic. The shape is the point: a single critical pays as much as two mediums, and an N/A costs real reputation, which is why Signal separates disciplined hunters from volume submitters.

Then read the actual work. HackerOne's Hacktivity is the community feed that lets you search disclosed reports by program and weakness so you can see how specific weaknesses were exploited. Each disclosed report there represents a confirmed vulnerability validated by the program's security team before disclosure, and the feed ranks activity primarily by aggregated upvotes, weighted slightly more when the vote comes from a hacker with high Signal. Pull two or three disclosed reports under the candidate's handle and read the methodology, the PoC, and the severity the program assigned. If the handle resolves to nothing in Hacktivity, the claim is noise until proven otherwise.

I built Refolk so you can ask for the people you want in plain English and get them back across GitHub, LinkedIn, and the open web. When the record you need lives on a platform rather than a resume, asking for the combination directly saves the manual cross-referencing this section describes.

Why severity is now a sourcing question, not a fact

A critical rating proves authorship of a record, not demonstrated impact, because severity is increasingly self-reported. NIST announced it would stop enriching most CVEs with around 300,000 backlogged, which means the CVSS score is now often set by the CNA itself, and a vendor acting as its own CNA has an incentive to shade upward. The underlying scoring is unstable even in expert hands: over 40% of vulnerabilities were scored differently by the same expert after nine months.

So record who set the score and whether anything corroborates it. The real corroborators are a CISA KEV listing, which means the vulnerability is known to be exploited, an EPSS score that estimates exploitation probability, and a public PoC. If a candidate claims three criticals and none carries KEV, EPSS, or PoC backing, treat the severity as unverified.

Those are distribution shares, not a validated overrated rate - a true false-high rate is not publicly established. Use the distribution as context: critical is rare and high is common, so a resume that is all criticals deserves a harder look at who assigned them. A related reliability signal from a large audit: NVD's CWE weakness label is correct in 81.07% of 15,556 audited CVEs, with 3.63% where the label is inconsistent with the evidence. Even the structured metadata is imperfect, which is why you read the report rather than the label.

The scoring procedure

Work the record in a fixed order so credit gates severity and the resume never outranks the platform. The timings below assume a single candidate with up to a dozen claimed CVEs and one bounty handle; split the work across a sourcer, a technical screener, and the hiring manager as noted.

There is one order disagreement worth naming. Practitioner write-ups put reading actual reports first, while platform docs imply checking the Signal threshold first. Either works for the bounty profile. But do credit verification before severity regardless, because a severity score on a record the candidate did not report is a dead end.

Count CVEs and you measure paperwork. Read them and you measure the person. </pull> ## How this read goes wrong Most bad verdicts come from trusting a headline number instead of its source. These are the failure modes to check explicitly, each with the false positive it produces and the test that catches it. - **Counting CVEs instead of reading them.** Thirty Linux-kernel-CNA numbers read as elite. Check how many carry a non-kernel-CNA Source and a maintainer-confirmed security impact; the kernel self-describes as overly cautious. - **Treating the credits array as sole authorship.** One name among five co-credits reads as solo discovery. Count the other names and find the primary reporter named in the advisory. - **Taking CVSS at face value.** Post-enrichment-halt, scores are often CNA-self-reported. Check who set the score and whether KEV, EPSS, or a PoC agrees. - **Confusing reputation with Signal.** A big reputation total can be pure volume. Check Signal against the 1.0 baseline and the ratio of resolved to informative and N/A reports. - **Mistaking cosmetic Signal gaming.** Self-closed and duplicate reports are excluded from Signal, so a profile can dodge penalties by withdrawing weak reports. Check the absolute resolved count and read the actual Hacktivity text. - **DISPUTED or REJECTED hiding in plain sight.** A disputed CVE gets cited as a win. Check the record's tag; a DISPUTED tag can be permanent. - **AI-slop era inflation.** With submissions up 76% year over year and only around 25% confirmed exploitable, raw submission counts are near-meaningless. Use the resolved-and-confirmed count only. - **Unverifiable handles.** A resume claims a handle you cannot find in Hacktivity. The handle must resolve to disclosed reports or the claim is noise. The AI-slop failure mode deserves its own weight. HackerOne's validation data showed submissions up 76% year over year and a record 46,947 in a single March, with only about 25% of findings confirmed exploitable. The curl project ended its bounty in early 2026 after 87 confirmed vulnerabilities in seven years, and one sixteen-hour stretch brought seven reports, none valid. The defensible denominator is the resolved-and-disclosed count, never total submissions. Three of four submissions are discardable, so a "500 reports" line means nothing until you see the resolved share. ## Corroborating independence before the verdict Independent artifacts under the same handle are what separate a real finding from a name on a shared record. Match each headline CVE or report to at least one of these: PoC code published on GitHub for a CVE the candidate is credited on, a conference talk at a venue like Black Hat or DEF CON, or a named writeup. No single study quantifies how reliably these corroborate discovery, so treat them as supporting evidence rather than proof, but their absence is telling: a headline finding with zero independent artifacts is marked uncorroborated and scored down. Cross-source search helps here. Public mirrors index disclosed HackerOne reports alongside GitHub Security Advisories, so a handle that appears across the CVE record, a Hacktivity report, and a PoC repo is far stronger than one that appears in only one place. The combination is the signal. ## What the three verdicts mean Combine the dimensions into one of three verdicts, each with a one-line rationale per dimension that you can read aloud to a panel. - **Deep skill.** Primary credit on vetted vendor-CNA records, severity corroborated by KEV, EPSS, or PoC, Signal comfortably above 1.0 with a healthy resolved count, and independent artifacts under the handle. Advance and use the interview to go deep on the hardest finding. - **Padded.** A long list that is mostly mass-assigned or co-credited, severity that is all self-reported with no corroboration, high reputation but thin or absent Signal. Not a reject by itself, but the record is not the reason to interview; probe for work the record does not capture. - **Noise.** Unverifiable handles, disputed CVEs cited as wins, submission counts with no resolved denominator, or nothing that resolves to a live record. The record contributes no signal; judge the candidate on everything else.

checklist title: Before you call the read done item: Every claimed CVE and handle resolves to a verifiable URL item: Each CVE is marked self-credited, co-credited, or unverifiable item: Each CVE is tagged vetted, mass-assigned, or disputed item: The CVSS source is attributed and checked against KEV, EPSS, or PoC item: Signal is checked against the 1.0 baseline with resolved vs N/A ratio noted item: At least two disclosed Hacktivity reports have been read item: Each headline finding has an independent artifact or is marked uncorroborated item: The verdict carries a one-line rationale per dimension

## Keeping the read current and widening the pool

Two facts will keep moving, so re-check them rather than memorizing a value. First, severity sourcing: NIST enrichment is halted with a large backlog, so confirm on each record whether the score came from the CNA, NVD, or CISA, because the default is drifting toward self-report. Second, bounty-submission quality: the AI-slop surge means the confirmed-exploitable share is the number to watch, so always anchor on resolved rather than submitted.

One more reason to get this read right: the verifiable pool is small and concentrated, which raises the cost of a wasted interview slot.

In Refolk's index, 66 US-based security and vulnerability researchers carry CVE and vulnerability-research skills, against 7 in Germany - a 9.4x gap. European pipelines therefore have to widen title and skill filters or recruit remotely. And bounty skill is badly under-declared: only 1 US profile in the index self-listed Bug Bounty as an explicit skill versus 66 tagged with CVE and vulnerability-research work, which means serious hunters live on Hacktivity, not their profile. Absence of a stated bounty skill is not evidence of a weak hunter. The read has to go to the platform, not the resume, which is also why describing the candidate you want in plain English and letting Refolk resolve it across GitHub and the open web beats keyword-matching a self-declared skills list.