进行了交谈，他告诉我，改写漏洞等级并不是一件很酷的事情。他们继续解释说，降低安全漏洞的等级是一种“逃避”（因为让我们面对现实吧，谁曾经将漏洞风险改写到更高的等级？）他们说：“如果这是个问题，我们应该修复它，而不是仅仅将其最小化。”我自己以前也改写过漏洞等级，主要是从“低”改写为“信息”，而且大多只是作为一种报告形式。
外和时间限制例外
与抑制类似，我们在 CI/CD 管道中实施 S 顶级电子邮件列表 AST 工具时看到的最大挑战之一是异常。允许发现，并经过开发人员的论证和同行的批准应该是可能的。
允许发现进入环境的原因有很
最简单的原因是开发速度在某种程度上超过 想要了解如何完善销售周期的每个阶段？ 了业务风险。如果出于某种原因允许某事，审计审查需要记录异常。Github Advanced Security 使用 UI 和 API 方法很好地标记了误报，并且可以提供一些不错的预设响应，例如在测试中使用。
但是，例外应该只
允许在一定时间内出现。大多数安全例外审查或审计实践每月或每季度重新审查记录的例外，因此允许 30、60 和 90 天的间隔例外才有意义。例外用完后，警报会再次发生。如果开发人员仍然无法修复，但仍需要例外，他们将再次经历该过程。这是少数必须给开发人员增加负担的情况之一。
结论
修复这些漏洞的开发人员的上下文切换和工 移动数据库 作量。Netlify 的安全意识强的客户在 Github 上托管源代码，他们可以利用 GitHub Advanced Security 来帮助确保在 Netlify 上运行的站点、工作负载和应用程序的安全。