Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Proposal: Moving security reports to a public workflow

未关闭
  • 哪里不对？
#1,826 13 条评论 7 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
javascript, node.js
领域
security

调研方向

从 SECURITY.md 和链接的 HackerOne 信号要求公告开始，了解当前的威胁模型、报告规则和升级路径。查看讨论，并定义公开工作流需要涵盖的内容，包括需要保密期的少数报告；完成的标准是项目已经就一个可持续的流程达成一致并将其记录下来。

由索引模型根据 Issue 内容生成。

描述

security-wg-agenda

I've been handling Node.js security for quite a long time, and I want to propose a strategy that may sound controversial, but I believe it deserves serious discussion given the reality we're facing today.

Over the last six months, the Node.js project has seen a significant increase in both contributions and HackerOne reports. In my view, this surge is largely driven by AI: contributors are using LLMs to fuzz and scan our codebase for potential vulnerabilities, and the reports we're receiving are remarkably similar -> strongly suggesting they originate from the same or similar LLM/tooling.

We've already taken steps to address this:

These measures have helped, but they haven't solved the problem. We are still overwhelmed. Reports that get automatically closed due to insufficient signal are now reaching our OpenJS CNA email and following our escalation path, and soon that team will be overwhelmed too.

The obvious path would be dropping bounties for security reports, but I have a second strategy that I think is worth considering

Most of the reports we receive are not vulnerabilities. They don't meet the bar defined by our threat model, but that doesn't mean they aren't bugs worth fixing. The reports are also highly duplicated, which tells us something important: anyone with access to a capable LLM (such as Opus 4.6) can surface the same findings at any time. These findings are effectively public already. If a commonly available tool can reproduce them on demand, treating them as private secrets provides a false sense of security. More effectively, our disclosure policy is set to 90 days and due to the fact I mentioned above, anyone would be able to find valid vulnerabilities before we even issue a security release.

So why do we need a private workflow for them?

I'm proposing that Node.js handle all security reports through a public workflow, similar to how Chromium/V8 has operated for a long time (@nodejs/v8 please correct me if I'm wrong) EDIT: Chromium/V8 does not handle security reports in public, though the issue tracker allows flipping visibility of bugs easily. See https://www.chromium.org/Home/chromium-security/. Most of what we receive aren't vulnerabilities, but they are bugs, and they'd get fixed faster if they were visible to the entire contributor community instead of sitting in a private queue. The security team's capacity would be freed up to focus on dependency vulnerabilities and shipping releases faster (as we won't need to lock ci, and follow all 26 steps) rather than triaging a flood of AI-generated noise. We would of course still need a defined process for the rare cases that do warrant an embargo.

I'd love to hear everyone's thoughts. The goal is to find a sustainable approach that keeps Node.js secure without burning out the people doing the work.

cc: @nodejs/tsc @nodejs/security @nodejs/security-triage

主要语言
JavaScript
星标
693
派生
143
平均合并
8 天 7 小时
30 天内合并 PR
3

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

nodejs/TSC 的其他 Issue

查看 nodejs/TSC 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。