Closing the Exposure Gap: What pixiv Learned About Continuous Security Testing
pixiv supports a global network of creators who publish and share illustrations, manga, and other digital works, build audiences, and collaborate.
It's a platform built on trust, where security incidents can quickly become brand issues that impact real people in the community.
As a fast-growing organization, pixiv had already invested in the basics: code reviews, shared security knowledge across engineering, external assessments, and automated testing like SAST and dependency scanning.
For pixiv Inc., the central question remained: Were they catching what was truly exploitable, or were they just generating activity?
The Problem: Point-in-Time Confidence in a Continuous-Release World
Traditional testing creates a familiar pattern.
- Scanners produce volume, but not always impact.
- Periodic assessments produce snapshots, but not ongoing coverage.
- Regional programs can limit perspective and participation.
As pixiv expanded globally and shipped changes more frequently, those limitations turned into an exposure gap. The work was anchored to tooling and schedules that didn’t match how modern risk shows up.
Business logic flaws, configuration mistakes, and chained attack paths don’t always light up in automation. They show up when someone thinks like an attacker, with time, context, and creativity.
Outcomes That Matter
The goal for pixiv was straightforward: They wanted to reduce real risk with less noise.
That meant:
- Proof of real, exploitable risk (not theoretical severity)
- Continuous validation between releases and audits
- A high-signal workflow engineers could act on quickly
- Faster remediation through clear reproduction and dialogue
In other words, fewer surprises, fewer false alarms, and clearer evidence of what could actually be abused in production.
The Action: Always-On Researcher Scrutiny as a Testing Layer
pixiv added a continuous testing layer by opening its program to a broader, global set of security researchers. The program was designed to complement existing controls, not replace them.
Two operational choices made the difference:
- Treating researcher reports as a collaboration, with direct clarification to speed up fixes.
- Using reporting and analytics to track severity and resolution trends over time.
These changes keep the signal high enough that security and engineering teams could move quickly without drowning in duplicates or low-quality submissions.
Apply pixiv’s approach to your program with this one-page playbook for continuous risk reduction.
The Impact: Visibility Into Risks Hiding in Plain Sight
The most meaningful impact wasn’t just a higher count of issues. It was a different class of issues.
pixiv saw that continuous, adversarial testing could surface problems that often slip past periodic testing and automation, including:
- Infrastructure misconfigurations that exposed internal server data
- Application-specific authorization and business logic weaknesses
- UI-driven attack paths with real account-level consequences
As a concrete example, pixiv discovered a payment bypass vulnerability that had existed for several years; thanks to the report, they were able to fix it before it could impact any users.
It also wasn’t a one-off. Over the life of the program, pixiv resolved 162 validated vulnerabilities, turning external signal into concrete fixes.
That single finding is the point.
Continuous validation changes what becomes visible, and it reduces the chance that long-lived vulnerabilities quietly ride along release after release.
See how pixiv turned continuous testing into measurable risk reduction
About the Author
