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

*You will be able to score a candidate's public vulnerability-disclosure record and defend a verdict of deep skill, padded, or noise to a hiring panel.*

- Canonical URL: https://www.refolk.ai/guides/vulnerability-disclosure-hiring-read
- Pillar: Engineering and open source
- Format: Framework
- Published: 2026-10-04
- Last reviewed: 2026-10-04
- Reading time: 17 min

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.

**~33% - Reviewed CVEs unconfirmed or disputed by maintainers**

From a non-random academic sample, so a defensible headline rather than an ecosystem census.

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.

| Dimension | What it proves when real | What it looks like when it lies |
| --- | --- | --- |
| Severity and independence | Maintainer-confirmed impact, solo discovery | Mass-assigned or disputed CVEs, five-way co-credit read as solo |
| Platform reputation mechanics | Report validity and discipline over time | High reputation total masking a low Signal and noisy work |
| Credit verification | The candidate's name is primary on a vetted record | A handle that resolves to nothing, or a DISPUTED tag cited as a win |

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.

#### Where each dimension gets its source of truth

1. **Resume claims** - CVE numbers and badges, lowest trust
2. **Live CVE record** - Source/Assigner field and credits array
3. **Platform profile** - Signal, Impact, resolved count
4. **Disclosed work** - Hacktivity reports, PoC code, conference talks

*Read from the outside in - the resume is the weakest layer and the platform record is the strongest.*

## 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.

> **Rule:** Credit verification comes before severity
>
> Always resolve the Source field and the credits array before you look at a CVSS score. A critical severity on a record the candidate did not primarily report, or on a disputed record, is worth nothing to your read.

### 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.

| Outcome | Reputation change |
| --- | --- |
| Resolved Critical | +50 |
| Resolved High | +40 |
| Resolved Medium | +25 |
| N/A report | -10 |
| Duplicate | 0 to +2 |

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.

> **Watch out:** Reputation total is not Signal
>
> A big reputation number can come from sheer volume of low-value work. Confusing the two is the most common bounty-profile mistake. Always pull the Signal value and the ratio of resolved reports to informative and N/A reports before you form an opinion.

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 ran this search: `Find US security researchers credited on non-Linux-kernel CVEs who also have disclosed HackerOne reports.` - [see the full result list](https://www.refolk.ai/s/nwbzep0v4b).

*Returns researchers whose CVE credits come from vetting CNAs and who also have platform-confirmed disclosed work to read, which is exactly the corroborated profile this read is built to find.*

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.

| Band | 2025 share | 2026 share |
| --- | --- | --- |
| Critical | 8.3% | 8.66% |
| High | 31.1% | 35.72% |
| Critical + High combined | 39.4% | 44.38% (derived) |

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.

#### Severity source versus corroboration

Horizontal axis runs from CNA-self-reported to Independently enriched or KEV-listed. Vertical axis runs from No PoC or external proof to PoC, EPSS, or KEV corroborates.

| Quadrant | What it means |
| --- | --- |
| Unverified self-score | Treat severity as claim, score as padded unless proven |
| Enriched but unproven | Credit it as moderate, ask for the work in the screen |
| Self-score with proof | Credit it - the PoC carries the claim |
| Corroborated and enriched | Strong signal, weight heavily toward deep skill |

*A credit is only as strong as the independent evidence behind its severity.*

## 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.

#### From a pile of identifiers to a three-way verdict

1. **Pull every claimed identifier** - Collect each CVE ID, advisory URL, and bug-bounty handle from the resume. Done when every item has a verifiable URL, not just a number or a badge screenshot. (sourcer, ~15 min)
2. **Verify CNA and credit per CVE** - Open each live record, read the Source/Assigner field and the credits array, and confirm the candidate's name appears. Done when each CVE is marked self-credited, co-credited, or unverifiable. (sourcer, ~20 min)
3. **Flag mass-assignment and disputed records** - Mark any Linux-kernel-CNA or backfilled CVE and any carrying a DISPUTED or REJECTED tag. Done when each CVE is tagged vetted, mass-assigned, or disputed. (technical screener, ~15 min)
4. **Read severity critically** - Record who set the CVSS, whether CNA, NVD, or CISA, and whether KEV, EPSS, or a PoC corroborates it. Done when severity is attributed to a source, not taken at face value. (technical screener, ~15 min)
5. **Read the bounty profile** - Capture Signal, Impact, percentile, and the resolved versus informative/N/A counts, then pull two or three disclosed Hacktivity reports and read the work. Done when the Signal 1.0 baseline is checked and at least two reports are read. (technical screener, ~20 min)
6. **Corroborate independence** - Match headline CVEs and reports to PoC code, conference talks, or named writeups under the same handle. Done when each headline finding has at least one independent artifact or is marked uncorroborated. (hiring manager, ~20 min)
7. **Score and reach a verdict** - Combine the dimensions into deep skill, padded, or noise. Done when you have a one-line defensible rationale per dimension. (hiring manager, ~10 min)

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.

**9.4x - US-to-Germany gap in CVE and vulnerability-research profiles**

In Refolk's index, 66 US-based researchers match versus 7 in Germany.

| Market | Matching profiles | Top employer examples | Share of US pool |
| --- | --- | --- | --- |
| US | 66 | Apple, Synack, Bugcrowd, HackerOne | 100% (base) |
| Germany | 7 | Apple, Zellic, Binary Gecko, Ruhr University Bochum | 10.6% (derived) |

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.

## Frequently asked questions

### Are CVE credits a good hiring signal?

They are a signal only once you account for how the record was assigned. Roughly one-third of reviewed CVEs are unconfirmed or disputed by maintainers, and the Linux kernel CNA alone issued over 1,100 CVEs in a single month by assigning a number to almost any bugfix. A CVE credit proves authorship of a record, not demonstrated skill. Weight credits from a vendor CNA that vetted security impact far above mass-assigned numbers.

### How do I tell a HackerOne Signal score from cosmetic reputation points?

Reputation is a running total that climbs with volume, while Signal is the average reputation per report on a scale from -10 to 7, so it measures report validity rather than activity. A high reputation total with a Signal near zero means noisy work. Node.js now requires a Signal of 1.0 or higher to submit reports, which is a usable credibility baseline. Note that Signal only calculates after more than three closed reports.

### How do I verify who actually got CVE credit?

Pull the live CVE record and read two fields. The Source or Assigner field names the CNA that numbered it, and the credits array lists the acknowledged people, organizations, or tools. The array holds multiple names, so being one of five co-credits is not solo discovery. Count the other names and find the primary reporter in the underlying advisory before you treat the finding as the candidate's own.

### Why can't I just trust the CVSS severity on a critical CVE?

Because severity is now often set by the CNA itself rather than independently enriched. NIST announced it would stop enriching most CVEs with around 300,000 backlogged, so scores are increasingly self-reported with an incentive to shade upward. Over 40% of vulnerabilities were scored differently by the same expert after nine months. Check whether a KEV listing, EPSS score, or public PoC corroborates the claimed severity.

### Do bug-bounty submission counts mean anything anymore?

Raw submission counts are near-meaningless. HackerOne reported submissions up 76% year over year with a record month, and only around 25% of findings were confirmed exploitable. One curl bounty stretch brought seven reports in sixteen hours, none valid. Use the resolved-and-disclosed count as your denominator, never total submissions, and read the actual disclosed reports to judge the work.

### What if the candidate lists no bug-bounty profile at all?

Absence is not evidence of weakness. In Refolk's index only one US profile self-listed Bug Bounty as a skill versus 66 tagged with CVE and vulnerability-research skills, so serious hunters tend to live on Hacktivity rather than their resume. If a handle is claimed, it must resolve to disclosed reports or the claim is noise. If none is claimed, judge the CVE and advisory record on its own and ask about bounty work in the screen.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/vulnerability-disclosure-hiring-read*