Security Tooling Proposal

This is a proposal for a security tooling pilot, not a code change. To understand the context, review the Node.js security-wg repository, its existing processes, and HackerOne integration. The ask is for feedback and potential adoption, not implementation. 'Done' means the working group has discussed and decided whether to proceed with the pilot.

Ravn × Node.js — Pilot Proposal

We're building free tooling to help maintainers and security teams triage vulnerability reports.

For Node specifically: reporter metrics gathered across all platforms rather than H1 alone, so you can separate slop from real reports more accurately than any single source lets you today. We'd like Node.js to try it and tell us what actually helps.

A note on data access & security

Our team originated from both the OSS and Security ecosystems, and recognizes the inherent need for tightly controlled access to security information.

We only ever record the report ID and title, the reporter, and the outcome. We don't access report bodies, comments or reproductions unless you turn on a feature that explicitly requires it — and even then, that content isn't retained.

In the first phase nothing reads a body at all: triage runs off the title, and the historical scan has no ability to fetch content. That's how it's built, not a policy we're asking you to trust us on.

Additionally, any sub-processor involvement (including frontier models) is disclosed upfront and operated on subscription tiers that prevent training of models or data exposure.

The problem we're solving, briefly

Volume is up, signal-to-noise isn't improving, and today's tooling has reached a point of diminishing returns. The challenges and processes are fairly universal, yet we're all still triaging and coordinating individually. That's the gap we're targeting.

We're seeing early success on three initial verticals:

1. Vendor-neutral reporter metrics — the signal triagers currently assemble by hand, gathered automatically and attested so you don't have to take any one party's word for it.
   • We deliberately do not provide a score or rank; a number that sorts people can't be checked, can't be explained to the person it describes, and can't differentiate "new" from "bad".
2. Agent-assisted enrichment — optionally let an agent read report content and feed what it finds into your policy; analysis can include customized prompts for minimum requirements, slop estimation, etc.
3. Modern, configurable automation — you set the thresholds, you keep the controls. Open Policy Agent under the hood. As your processes evolve and mature with reliable metrics, automate your SOPs based on easily verifiable signals.

What trying it actually costs you

Our mantra is low risk + low effort + high reward.

Three steps to get started:

1. Connect the program. An API token from HackerOne.
2. Set up the webhook. Lets us see report outcomes as they happen.
3. Scan back over your closed reports. We scan historical reports for the outcome and the reporter — who filed it, what you decided — not report content or reproductions.

Day 1 you get: a view of what our policy would have decided across reports you've already closed, next to what your team actually did. You move the thresholds and calibrate the Decisioning to match your team's judgement.

Nothing we do is visible to your participants. No comment, no state change, no close, no notification — not on day one, and not until you explicitly decide otherwise. You can back out at any moment without impact.

Plenty is happening from your perspective, though: reports get triaged as they arrive, reporter metrics get built, and your policy runs against all of it. It just runs where only your team can see it.

Your outcomes make the signal better for everyone, including you

When you close a report, that outcome becomes part of that reporter's standing across the ecosystem — without leaking sensitive information. The next program to see them has better context — and so do you, when someone who's been filing elsewhere for years shows up in your queue for the first time.

Other programs only ever see this in aggregate. Nobody else can see what you decided on a given report, or that a given report was yours. The contribution is the outcome, never the triage.

This is the part that compounds: the metrics are useful on day one from your own history, and they get better as more programs participate.

Who we are

A small team led by two repeat co-founders. Technical and security direction are led by David Welch (co-chair for the CVE Automation Working Group; former founding CTO at HeroDevs and Chief Architect of the Never-Ending Support program), guided by a vendor-neutral advisor group drawn from CVE, OpenSSF/LSF, FIRST PSIRT, ISACs, and the leading enterprise security scanners.

We're structured with both a Commercial and a Community arm. The Community arm is the focus for at least the next 12–18 months, built to stand on its own and to embrace/revert to community ownership should the Commercial entity fold. The community tooling is free forever — unconditionally, and universally.

The commercial side is what pays for that, and it's deliberate rather than incidental: addressing the gaps early in the SDLC and supply chain drives better outcomes today and opens new opportunities tomorrow — the latter where we expect to make our bread. And serving paying security teams holds us to a higher operational bar at private industry scale and regulatory compliance, which is what keeps the free tier durable rather than dependent on community sacrifice or continued goodwill.

The ask

The initial investment is minimal. An hour of someone's time, and one Bounty/Research program connected which is only visible inside your team.

What you get: reporter metrics, with deep insights from multiple platforms & ecosystems instead of one; a decisioning policy, which you can calibrate against your own closed reports and unique processes; and direct influence over what gets built next.

What we're hoping to get: honest feedback on what's useful and what isn't. You know your queue and pain points better than anyone, and we'd rather learn early what actually reduces burden and improves outcomes.

More details available upon request. Happy to jump on a meeting and dig deeper, at your convenience.