Home / Blog / HackerOne Got Breached

HackerOne Got Breached

What does third-party software risk actually look like? And what does vendor audit has to do with that.

Content

Make Your Applications Secure Today

Sign up for a personalized demo to see how DerScanner can meet your Application Security needs

The company whose entire business is helping organizations find security vulnerabilities just had employee Social Security numbers, dates of birth, and health plan details exposed — through a Broken Object Level Authorization vulnerability in a benefits vendor’s API.

Navia Benefit Solutions, a U.S.-based employee benefits administrator, disclosed in March 2026 that attackers had accessed its systems between December 22, 2025 and January 15, 2026. The breach affected 2.7 million individuals across Navia’s client base. HackerOne, one of those clients, confirmed that 287 employees’ data was compromised — and publicly criticized Navia’s weeks-long delay in sending formal breach notifications.

A BOLA vulnerability is number one on the OWASP API Security Top 10.

 

The Structural Problem

HackerOne’s own infrastructure was not compromised. Its bug bounty platform, customer data, and internal systems were unaffected. The breach came through a vendor that handles employee benefits — a system that sits entirely outside the security perimeter that HackerOne’s considerable expertise protects.

This is the core lesson, and it applies to every organization regardless of size or security maturity: your security posture is only as strong as your weakest vendor. A company can run the most sophisticated AppSec program in the industry and still lose employee SSNs because a benefits administrator did not test its API for authorization flaws.

The Verizon 2025 DBIR quantifies this: third-party involvement in breaches doubled year-over-year, rising from 15% to 30% of all confirmed data breaches. And the OWASP Top 10 2025 has responded by introducing Software Supply Chain Failures as a new category at number three — with 50% of community survey respondents ranking it their top concern.

 

Where SCA and SBOM Discipline Fit

The Navia incident was not a software composition issue in a common sense. Navia is a service provider, not a library. But the principle is identical: when risk lives outside of the perimeter, visibility is the only defense.

For software supply chains specifically, this means maintaining SBOMs that document every third-party component in your products, running SCA continuously to catch known vulnerabilities before they reach production, and evaluating the security posture of the libraries and packages the app depends on — whether they are maintained, their maintainers have been compromised (as in the Trivy incident), and their publish infrastructure is trustworthy.

DerScanner’s SCA addresses this through its package health scoring — evaluating components on eight metrics beyond CVE presence, including maintainer activity, project health, domain integrity, and indicators of supply chain manipulation. For the code build, this is the equivalent of what HackerOne should have demanded of Navia: evidence that security basics are in place, continuously verified.

 

 

What to Do

 

Audit vendor security the way you audit your own

HackerOne is now evaluating whether to change benefits providers. A better practice is to require security evidence — pentest reports, SOC 2, API security testing results — before signing the contract.

Run scans against every API or service you expose and consume. If Navia had run a DAST scan against its own API, this breach likely would not have happened.

 

Treat supply chain security as a continuous practice

SBOMs, SCA in CI/CD, package reputation scoring, and vendor risk assessments are not one-time exercises. 

The OWASP Top 10 2025 now places supply chain failures at #3 precisely because the threat is systemic and ongoing.

Loading blogs...
Get Started

Ready to Reduce Technical Debt and
Improve Security?

Clean code. Fewer risks. Stronger software

dashboard