A bug bounty program scoped for general application security will not find your supply chain risks, and a program scoped naively for supply chain will bury your team under dependency CVE reports that are already in your scanner. Striking the balance is a scoping problem first and a budget problem second. We scoped a supply chain bounty program at a B2B SaaS with about 80 production services and learned most lessons the painful way, including the month we paid out $24,000 for reports that were duplicates of existing findings our triage queue already owned. The program below, now two years in, produces roughly 40-60 valid submissions per year with a median payout of $1,800 and has surfaced at least three findings that neither scanners nor internal research would have caught. This piece describes the scope definition, the payout structure, the triage workflow, and the four scoping mistakes that cost us the most money and goodwill before we fixed them.
What should be in scope for a supply chain bug bounty?
Four asset categories earn bounty scope: build systems and CI/CD infrastructure, signing and attestation infrastructure, artifact registries and package mirrors, and first-party services that process vendor data or customer-controlled supply chain artifacts (SBOMs uploaded by customers, attestations, etc).
Explicitly out of scope: known CVEs in third-party dependencies unless the reporter demonstrates a novel exploitation path specific to your implementation, SOC 2-scope control gaps (go to your auditor, not a bounty), and any finding that a published scanner would detect in the first run. The out-of-scope list must be published as prominently as the in-scope list; vague scope is the fastest way to demotivate researchers and overwhelm your triage team. We learned this by paying out $800 for a bog-standard outdated-dependency report before we got the exclusions right.
How should payouts be structured?
Payouts tier on impact, not CVSS. Five tiers: P1 (critical, $15,000-$50,000), P2 (high, $5,000-$15,000), P3 (medium, $1,500-$5,000), P4 (low, $500-$1,500), P5 (informational, $0-$250 with swag).
A P1 example is a demonstrated build system compromise that would allow unsigned artifact injection into the release channel. A P2 is registry access that lets an attacker replace a signed artifact post-publication. P3 covers things like bypassing a policy gate enforcement. P4 handles misconfigurations with limited blast radius. Pay P5 only occasionally and only with a clear rationale; over-rewarding low-impact reports attracts noise.
Tie payouts to the Exposure Factor score internally: for each valid submission, compute the potential dollar exposure using the same model used in executive reporting ($165 per record baseline for PII). The payout is a bounded function of exposure, typically 2-5% of estimated exposure up to the tier cap. This keeps payouts defensible at budget review time and prevents ad-hoc negotiation with researchers.
What does triage look like for supply chain submissions?
Supply chain submissions route through a dedicated triage queue separate from the general AppSec bug bounty queue. The routing rule: if the submission references build systems, signing, registries, SBOMs, or vendor-provided artifacts, it goes to supply chain triage, otherwise to AppSec triage. Both queues have a published SLA of 3 business days for initial response, 10 business days for severity determination, 30 business days for payout decision.
The triage team is two supply-chain-specialized engineers on a rotating two-week on-call for bounty triage. Each submission gets: reproducibility verification (did it actually work), novelty check (is this already in the known-findings database), severity assessment against the tier rubric, and a written rationale for the final payout decision. The rationale gets shared with the researcher; opaque decisions are the fastest way to lose researcher trust.
What are the most expensive scoping mistakes to avoid?
Four mistakes cost us the most. First, accepting dependency CVE reports as in-scope; this generated a flood of duplicates until we explicitly excluded them and directed researchers to report to the upstream project. Second, allowing open-ended "supply chain risk" submissions without a specific exploitable impact, which turned into philosophical debates about risk posture. Third, paying out for reports against vendors (go to the vendor's own program), which set a precedent we had to walk back. Fourth, under-scoping build systems, which resulted in one report being declined because GitHub Actions was "not your asset" when in fact the misconfiguration was ours.
Fix these in the published policy before launch: dependency CVEs out unless novel exploitation demonstrated, submissions require a clear impact path with proof-of-concept, vendor reports redirected, and any infrastructure we control is in scope regardless of ownership.
How do you integrate bounty findings with internal response?
Valid bounty findings merge into the same remediation queue as internal findings, with one addition: bounty findings carry a researcher-specific disclosure timeline that may differ from internal SLAs. Default disclosure is 90 days from triage confirmation; researchers can negotiate extensions for complex fixes, and we publish a coordinated disclosure statement on remediation.
Track bounty findings alongside internal metrics: mean time to remediate by tier, percentage remediated within disclosure window, and external disclosure quality. A healthy program has 90%+ of findings remediated before disclosure and zero surprises for the researcher. We failed this once when a P2 finding slipped past the 90-day mark and the researcher tweeted before our fix shipped; the subsequent process improvement added a 30-day-remaining escalation automation.
What does the program cost annually?
Annual program cost at our 80-service scale: $120,000-$200,000 in payouts, $60,000 in platform fees (HackerOne or Bugcrowd), $180,000 in triage engineer time (two engineers at 25% each), $30,000 in legal and program management overhead. Total roughly $400,000-$500,000 fully loaded.
Budget justification: compared to equivalent depth from a retained pen test firm ($40,000-$80,000 per engagement, two engagements per year, roughly $100,000-$160,000), the bounty program covers a wider surface continuously and produces findings a retainer could not. The program is not a substitute for pen testing, which remains required by SOC 2 and covers scenarios bounty researchers do not (insider threat, phishing, physical). Budget both; treat them as complementary, and route the most interesting bounty findings to next year's pen test scope.
How Safeguard Helps
Safeguard's inventory and reachability data makes bounty triage defensible. When a researcher claims a dependency is exploitable, reachability analysis via Griffin AI immediately shows whether the vulnerable path is actually reachable in the live service, turning a 4-hour debate into a 15-minute decision. SBOM history lets the triage team verify claimed version ranges against the actual production deployment. TPRM data disambiguates vendor-scope versus internal-scope findings, closing one of the most expensive scoping ambiguities. Policy gates ensure that a remediated bounty finding cannot be accidentally re-introduced during the disclosure window, protecting the researcher relationship and the payout budget from repeated payouts on the same bug.