Sourcing an AppSec Engineer From Public Vulnerability Work

You have one application security req and a hiring manager who is tired of shortlists full of certificates and generic "Security Engineer" titles. This guide is for in-house recruiters, sourcers, and talent leaders who need a shortlist of AppSec engineers whose hands-on skill they can verify from public work, not infer from credentials. I carry a single search from brief to ranked, reachable shortlist, using the security-specific evidence trail: CVE credits, GitHub security advisory credits, bug bounty recognition, and CTF standings. Along the way I take the wrong turns on purpose, so you know which forks to avoid.

Most published sourcing advice for this role stops at "post a good job description and go to a BSides meetup." That is not sourcing; it is waiting. The reason it stops there is that the best evidence for an AppSec engineer is invisible to keyword search. It lives in vulnerability disclosures, not in profile text. This teardown works that trail all the way through, including the part nobody writes about: turning an anonymous handle into a named person you can actually contact.

Why headline sourcing misses the best AppSec people

The strongest AppSec evidence is invisible to keyword sourcing, so any method that starts from profile text will systematically miss the best hands-on people. This is the single most important thing to internalise before you write a query.

In Refolk's index, requiring that a profile headline contain "bug bounty," "CVE," or "vulnerability researcher" surfaced 0 of 1,113 US application security engineers. That is not a small leak. It is the whole pool. The people who find and disclose vulnerabilities do not describe themselves that way in a headline field; their proof lives in the CVE record, the GitHub advisory, the HackerOne thanks page, and the CTF scoreboard. If your sourcing string leans on the headline, you are filtering for people who talk about the work, not people who did it.

This inverts the usual sourcing order. Most guides tell you to run a LinkedIn keyword search and then verify the hits. This teardown reverses it: start from the disclosure evidence, then resolve back to the person. The reason is simple. When the evidence lives outside the profile, you have to enter from the evidence door.

The one req I am working, and its lane

I am sourcing one full-time application security engineer in the US, and I will accept a candidate only if there is public vulnerability evidence I can open in a browser. That is the brief. Before I write a single query, I fix the lane, because pay and evidence differ by lane and mixing them wastes a week.

Security engineering is not one job. Application and product security leaves the richest disclosure trail: CVE credits, GHSA reporter credits, bug bounty reputation, and CTF web or pwn standings. Cloud, network, and detection roles leave far thinner public disclosure trails and are better identified by the tooling named in their profiles. A cloud engineer proves skill with GuardDuty, Terraform, and CSPM work; an AppSec engineer proves it by breaking software and getting credited for it.

The lane matters for money too. Cloud security clusters between roughly $125k and $195k in base compensation, with a documented Glassdoor average of $169,173 and a 90th percentile of $264,537. A cloud engineer will out-earn a network engineer by $15,000 to $30,000 at the same seniority, metro, and company size. AppSec national averages are not established publicly as a single authoritative figure, so anchor comp against the cloud band and the cross-lane gap rather than a made-up AppSec number.

The separating terms are your first filter. For AppSec, look for CVE credit, GHSA reporter, Burp Suite, SAST or DAST, and bug bounty. For cloud, look for GuardDuty, Terraform, and CSPM. A profile whose only security evidence is Terraform sentinel policies is a cloud engineer wearing a "Security Engineer" title, and sourcing it against an AppSec req is the most common lane-mismatch error in this work.

Which public sources actually credit a named person

Four sources tie a named person or handle to real vulnerability work, and each carries the credit in a specific, searchable field. Knowing the field is the difference between browsing and sourcing.

The CVE JSON record format carries a dedicated credits container: statements acknowledging specific people, organizations, or tools recognizing the work done in researching, discovering, remediating, or helping with a vulnerability. You can search that field directly. One industry team found that 75 CVE records contained the term "Anthropic," and of those, 40 were credited to Anthropic-affiliated researchers in the credits field. That is the pattern to copy: pick a target, search the credits field, and harvest names.

GitHub Security Advisories carry structured credits too. Since a 2021 change, advisory credits appear on the researcher's GitHub profile and on profile hovercards when viewed in the context of an advisory. Since 2023 you can designate different credit types that mirror the CVE 5.0 schema. One catch that becomes a failure mode later: credit is opt-in. If a person accepts, their username becomes publicly visible once the advisory is published. If they never click accept, the structured credit is silent even though the work happened.

HackerOne exposes Reputation, Signal, and Impact per researcher, plus organisation "thanks" pages that list who reported to a given program. Bugcrowd uses a separate Kudos system that accumulates points scaled by priority level from P1 through P5. Both give you a name or handle attached to accepted, valid findings.

These are your evidence sources in rank order of signal strength for AppSec. A CVE or GHSA credit for a High or Critical software vulnerability is the strongest single artifact. A HackerOne Impact above 5 is close behind. CTF standings are supporting evidence, strong for individuals with their own writeups, weak when they are only a name on a team.

The teardown: one search from brief to shortlist

Here is the full procedure, in order, with the owner and rough time for each step. Follow it on your own req and you will end with a ranked list whose order is driven by disclosure evidence rather than credentials.

On my worked req, step two produced roughly three dozen raw names and handles across a few weeks of target CVEs and two HackerOne program thanks pages. Step three cut that by about a third, mostly cloud-config profiles and one detection engineer who kept appearing in advisory description text but had never reported a software bug. That left the list that had to survive the hard part: turning handles into people.

The funnel numbers past the first two rows are from my single worked req and will vary with your target companies and how much time you spend. The two index figures are fixed: 1,113 in the pool, 0 surfaced by headline. Everything downstream is the work.

Resolving a handle to a real, reachable person

The alias-to-person problem is where this job actually gets hard, and the documented method is three moves: enumerate, correlate, pivot. Miss any one of them and you either lose the person or match the wrong one.

Enumeration is checking whether a username exists across many platforms. Correlation is confirming that the user123 on GitHub is the same person as the user123 elsewhere, using bio details, avatars, or location. Pivoting is using a unique fact found on one profile, such as a real name or a recovery email, to launch a new search. The method works because most people reuse usernames consistently, which makes a single handle a key that unlocks connected accounts.

Tooling scale differs sharply, and it changes what you can do in an afternoon. Sherlock checks 400 or more platforms for username existence. Maigret checks 3,000 or more sites and adds profile parsing and recursive search, which means it can pull the bio and location that you need for correlation without a separate visit. WhatsMyName is a browser-friendly enumerator for a quick pass. Use enumeration to find candidates for the same person, then correlate before you believe any of them.

The reason resolution deserves its own step is that it is the point where false positives enter. A handle that exists on eight platforms is not one person until a second signal confirms it. The rule below is not optional.

Record a confidence note for every resolution: what you matched on and how sure you are. "Same avatar on GitHub and HackerOne, plus matching city in both bios" is a strong note. "Same handle, nothing else" is not a resolution, it is a lead.

Grading the evidence, and the thresholds that separate hands-on from hobbyist

Grade each candidate against documented platform floors so that "hands-on" means something specific rather than a gut feel. No regulator sets these bands, so your hiring team owns the exact numbers, but the platform mechanics give you defensible starting lines.

On HackerOne, Signal and Impact only compute after more than three closed reports or three bounties respectively. Signal runs from -10 to 7; Impact runs from 0 to 50. The critical distinction is that Reputation can inflate on volume while Impact stays honest. Signal is the average reputation per report and Impact is the average reputation per bounty, so a hunter who submits many low-severity findings can carry a big Reputation number and a mediocre Impact. The working benchmark from practitioners is Impact above 5 for top private invites, which usually means the person filtered themselves to High and Critical findings. Rank on Impact.

Context for how selective real bounty work is: valid-report rates average 19 percent, and some programs run as low as 6 percent. So a researcher with a stable Impact above 5 is clearing a bar that rejects four out of five reports. For a sense of the top end, one top researcher uncovered nearly 500 vulnerabilities on HackerOne in two years. You are not looking for that; you are looking for someone whose findings were severe enough to move Impact, and recent enough to still count.

On CTFtime, only the 10 best results count toward the yearly rating, inside an 18-month window. That window is also your recency check. A CVE from years ago with nothing since is stale evidence; weigh recent disclosures far more heavily. Bugcrowd's Kudos, scaled by priority from P1 to P5, is the equivalent signal on that platform, and P1 and P2 findings are the ones that map to hands-on skill.

Tag each candidate: hands-on when there is severe, recent, individually-attributed evidence; borderline when the evidence is present but thin or shared; hobbyist when the trail is old, low-severity, or unresolved.

How this goes wrong: the failure modes to check for

Every strong signal in this method has a way of lying, and the value of a standard is naming the lie and the check. These are the false positives that produce a confident, wrong shortlist.

• Handle collision. Two unrelated people share a username, and a "match" on name alone is a false positive. Check with a second correlated signal, looking for where an anonymous identity and a named identity overlap.
• Credit acceptance gap. A real reporter never clicked accept, so the structured advisory credit is blank. Absence of credit is not absence of contribution. Check the advisory description text, which often thanks people informally.
• Reputation inflation by volume. A high HackerOne Reputation built on many Lows looks impressive and proves little. Check Impact; if someone only submits low-severity findings like missing headers, Impact stays low even with perfect Signal.
• CTF team credit is not individual skill. A name on a top-ranked team may belong to a low-contributing member. Check the individual's own solve writeups before crediting the team's rank to the person.
• Cert gating. Filtering on CISSP screens out hands-on hackers who never bothered with it. Check for disclosure evidence instead; the cert targets managers, not exploiters.
• Lane mismatch. A "Security Engineer" title with only CSPM and Terraform evidence is a cloud profile against an AppSec req. Check for software-vulnerability disclosure, not configuration work.
• Stale evidence. A single old CVE with nothing since is a lead, not a qualification. Check recency against the 18-month CTFtime window and past-year HackerOne stats.
• Headline blindness. Requiring "bug bounty" in a headline returns almost nobody, as the 0-of-1,113 result shows. Check disclosure sources directly rather than profile keywords.

The cert failure mode deserves a hard line, because it is the one hiring managers push back on most. CISSP requires at least five years of full-time relevant experience before the exam, and the multiple-choice format does not validate the ability to configure a firewall, analyze malware, or perform a penetration test. Even a CISSP defender concedes he would not require it when hiring a pen tester or network security engineer. It proves tenure and breadth, not exploitation ability.

Market depth changes the strategy

The size of the pool you are working in decides how much you can rely on volume, and the US and UK are not the same problem. Know which one you are in before you set expectations with the hiring manager.

In Refolk's index, the US holds 1,113 AppSec and product-security engineers against 129 in the UK, a depth of 8.6 times. In the US you have enough people that some volume filtering is survivable even after the evidence-first funnel narrows hard. In the UK, with 129 people, there is no large pool to keyword-narrow, so the evidence-first method is not just better there, it is the only method that finishes with anyone reachable.

The employer distribution also tells you where the evidence concentrates. In the US cut, the top employers are Google, Meta, AWS, Apple, and SAP. In the UK cut, they are Wise, Meta, Santander, and Boeing. Those companies run bug bounty programs and ship software that generates CVEs, so their current and former engineers are more likely to carry the disclosure trail this method needs. Use that to prioritise which company thanks pages and advisory sources you mine first.

For context on demand, one workforce report documented more than 514,000 cybersecurity job postings in a 12-month window against a global workforce of roughly 5.5 million. The pool is deep enough that keyword sourcing produces motion; it is the evidence step that produces a defensible shortlist. When the pool is thin, as in the UK, Refolk lets you ask for the evidence directly rather than reconstruct it by hand, which is the difference between a shortlist and an empty search.

Before you send: the pre-outreach checklist

Run this before the shortlist leaves your hands. It catches the failure modes above at the last responsible moment, when they are still cheap to fix.

Keeping the method current

The mechanics of this method are stable, but the specific numbers and platform rules are not, so re-check the moving parts rather than trusting a value you cached. Three things drift: platform thresholds, comp bands, and pool depth.

Platform rules change. HackerOne's Signal and Impact scales, the three-report computation floor, and CTFtime's best-10 and 18-month window are documented today, but treat them as citations to re-verify against the platform docs before you set a hiring bar on them. When a rule changes, your "hands-on" definition should change with it.

Comp bands move faster than anything. The cloud average of $169,173, the roughly $125k to $195k band, and the $15,000 to $30,000 cross-lane gap are anchors to re-pull, not constants. Because no authoritative AppSec national average is published, keep anchoring AppSec against the cloud band and the documented cross-lane gap, and re-run that read each time you open a new req in a new metro.

Pool depth shifts as people change jobs and as new disclosures land. The 8.6x US-to-UK ratio and the specific counts are snapshots. The durable lesson is the shape, not the number: the US is deep enough to survive some volume filtering, the UK is not, and either way the headline keyword returns near zero. Re-run the evidence-first search each time, start from CVE, GHSA, HackerOne, and CTFtime, and resolve back to the person. That is the part that does not go stale.