直接从安全通告页面屏蔽用户

你现在可以直接在组织或个人账户拥有的公共仓库的安全通告页面中屏蔽用户。这为安全通告带来了与议题和拉取请求一致的简化版审核体验。安全通告包含用户创建的内容，并与其他协作界面一样，可能吸引垃圾信息或滥用行为。以前，处理此问题需要导航到组织设置、个人设置或用户个人资料。现在，无需离开页面，即可通过安全通告描述或评论中的三点菜单屏蔽用户。在采取行动前，你会看到清晰的确认信息，说明屏蔽用户意味着什么。在移除垃圾信息或滥用来源的同时，保持安全通告的完整性。在组织拥有的仓库中，只有组织版主或管理员才能发起屏蔽。在个人账户拥有的仓库中，账户所有者可以发起屏蔽。加入社区讨论以分享你的问题或反馈。

GitHub 现在允许在安全通告页面直接屏蔽用户，简化了社区管理流程，支持组织和个人仓库，并保持通告内容完整。

• 安全通告页可直接屏蔽用户，操作快捷
• 组织仓库仅管理员可屏蔽，权限明确
• 个人仓库所有者拥有唯一屏蔽权限
• 屏蔽前有确认弹窗，降低误操作风险
• 解决垃圾信息无需跳转，提升审核效率

这是什么信号

GitHub 将社区审核能力从议题和拉取请求扩展到安全通告，表明平台在持续优化协作场景的治理效率。安全通告作为安全漏洞披露的重要载体，其可靠性至关重要，而用户评论和描述中出现的垃圾信息会干扰有效信息的传递。此次更新直接响应了维护者长期以来的痛点——以往需要多层跳转才能完成屏蔽操作，现在一键可达。

为什么重要

安全通告通常涉及敏感信息，时间敏感度极高。垃圾信息或滥用内容可能掩盖关键漏洞细节，甚至误导用户。通过减少操作步骤，维护者可以更快地清理环境，降低风险。同时，该功能在组织与个人仓库间设定了分权机制，避免了权限过度扩散，这体现了治理结构对安全场景的适配。

对谁有价值

对开源维护者、安全研究团队和有公开仓库的个人开发者而言，该功能直接提升日常维护效率。尤其是那些管理多个仓库或高流量项目的组织，能够以更少的时间成本维持公告区的整洁，并减少因不当操作引发的社区争议。

可以怎么行动

作为维护者，应迅速熟悉新功能，并在团队内部更新安全通告的审核流程。建议将“屏蔽用户”纳入应急处置标准操作，结合现有议题审核经验，形成统一的社区管理策略。对于个人仓库所有者，需明确自己的管理权限边界，避免误操作。

风险或限制

屏蔽功能仅在公开仓库有效，私有仓库的安全通告是否支持尚未提及。此外，屏蔽是重操作，可能导致用户申诉或反感，因此 GitHub 提供确认机制，但维护者仍需谨慎判断，避免因垃圾信息以外的原因滥用屏蔽。最后，该功能仅做“屏蔽”，未提供举报或内容折叠等轻量选项，对于轻微违规可能过重。

这条信息差在于，多数维护者仍习惯通过传统设置路径处理滥用行为，而 GitHub 已经将审核下沉到内容层。这种“场景内操作”的设计理念，揭示了平台治理向实时化、轻量化演进的趋势。对于依赖 GitHub 协作的团队，及时掌握此类细节更新，能在社区运营中建立更专业的响应形象。

业务启发是：安全通告的评论区同样需要秩序，而不仅是代码审核。维护者应将其纳入日常巡检，并制定比传统议题更严格的屏蔽标准，因为通告的公共属性更强。可沉淀动作包括：更新团队内部《社区治理手册》，添加“安全通告屏蔽流程”；在模板中增加提醒，引导贡献者使用规范格式，从源头减少垃圾信息。

长期看，这类功能的迭代会减少第三方管理工具的需求，但也会提高对维护者判断力的要求。建议定期审查屏蔽记录，提炼常见滥用模式，甚至形成反垃圾规则集。同时，关注 GitHub 后续是否将此能力扩展到私有仓库或更多协作场景，以便提前准备策略。

• Allison 原帖