pixiv's Playbook for Continuous Risk Reduction

Before: Confidence came from internal reviews, external assessments, and automated tools.

After: More critical vulnerabilities, including remote code execution, were discovered only after opening testing to a global security researcher community. Bug bounty became a way to validate what is exploitable in production, not just what controls exist. 

After we started using HackerOne, we found some critical vulnerabilities that had not been discovered before.

Stop treating “no findings” as assurance. Require exploit evidence in production.

Actions to take:

• Treat external researcher findings as control validation, not gap-finding.

• Ask: “Could this be exploited in our live environment?” before accepting risk.

• Use bug bounty to pressure-test assumptions made by internal reviews and scanners.
   

Before: Program health was assumed from report counts and response averages.

After: Critical issues were fixed immediately, medium issues were deprioritized if they didn’t threaten business continuity, and out-of-scope reports were still reviewed for insight. pixiv measures what threatens the business, not how busy the program looks.

Actions to take:

• Escalate and fix critical issues immediately.

• Explicitly deprioritize medium issues that don’t impact business continuity.

• Review out-of-scope reports for signal and pattern recognition, not just closure.

Before: Discovery was the goal; remediation was assumed to follow.

After: pixiv formalized remediation flow:

1. Infrastructure Unit reviewed reports
2. Routed findings to product teams
3. Verified fixes centrally

Discovery only matters if remediation ownership is explicit.

Actions to take:

• Define a single intake and review function for researcher reports.

• Route validated findings directly to accountable product teams.

• Centralize fix verification to avoid fragmented “done” states.

Before: Bug bounty was expected to require significant internal staffing.

After: pixiv relied on HackerOne triage services to reduce noise and protect engineering focus. Scale came from process and support, not headcount. 

Actions to take:

• Use managed triage to filter noise and duplicates before engineering sees reports.

• Protect developer focus by only surfacing validated, high-impact findings.

• Invest in process and external support instead of adding internal reviewers.

Before: Program value was hard to express using traditional ROI models and revenue-generating metrics.

After: Conveyed program value using language around proven risk reduction:

• 162 valid vulnerabilities resolved
• ~$137,811 total bounty spend
• Value evaluated in relation to avoided business risk

Actions to take:

• Track resolved vulnerabilities against potential business impact.

• Relate bounty spend to mitigated breach likelihood and severity.

• Communicate value as risk removed, not dollars earned.

• Turn on Return on Mitigation dashboard and reach out to your Customer Success Manager to validate inputs and assumptions.

Before: The known vulnerabilities were assumed to be the worst ones.

After: Real vulnerability reports made risk tangible--and drive alignment faster than theory or training decks.

Instead of thinking ‘maybe there are no vulnerabilities,’ leadership now understands that they exist and must be addressed.

Actions to take:

• Share real vulnerability reports with internal teams and use researcher findings as concrete teaching moments.

• Ground security conversations in evidence, not hypotheticals.