低严重性发现比关键漏洞更能反映您的审计 许多审计公司在销售宣传中将重点放在发现的高严重性漏洞数量上，仿佛这个数字没有上下文的支持：之前的审计、同行评审、测试覆盖率、代码复杂性、行数以及许多其他指标。这是最低级的销售手法，与通过毫米长度比较USB驱动器质量没有什么不同。 为了展示一种替代方案，我们首先必须确认几个支持性论点的正确性： - 意外漏洞注入的概率对高影响没有偏见（开发者在高风险代码中并不会更加鲁莽，通常情况正好相反）。 - 用于发现各种严重性缺陷的全面方法论同样会发现高严重性问题（反之则不成立）。 - 随机漏洞要符合高严重性的要求要高得多（通常它会被限制在无法达到的条件下，或涉及非关键功能）。 - 从基本统计学来看：更高的抽样率与更低的预期偏差/方差相关，因此测量更为准确。 我们将审计报告定义为对代码库质量的抽样结果。我们推断，预期的真实（没有遗漏）高严重性漏洞数量远低于低严重性漏洞数量，而围绕它的预期偏差则要高得多（由于样本较小）。换句话说，高严重性漏洞的数量对遗漏的高严重性漏洞数量几乎没有帮助。 因此，令人惊讶的是，1个高严重性漏洞和10个低严重性漏洞的报告在其他条件相同的情况下，比10个高严重性漏洞和1个低严重性漏洞的报告更令人安心。尽管实际上绝大多数销售人员更愿意展示后者作为质量的指标。关键是，高频率指标是衡量低频率结果的更好工具。 Web3建设者，下次当公司向您展示他们的关键/高严重性漏洞数量和数十亿美元的安全资金时，您知道该关注哪里以寻找真实信号。 Web3审计员，认识到没有一致的秘密公式可以在寻找所有高严重性漏洞的同时不去寻找低严重性漏洞——每一个未完全调查的低严重性漏洞都是一个潜在的高严重性漏洞——并给予每一行最好的关注。您的客户会因此感谢您。 低严重性被定义为不会导致更高层次影响的具体编码错误。不包括格式、最佳实践和填充发现。

昨天发布了一个在 git 中的关键漏洞，可以通过克隆不受信任的仓库来触发。这是攻击审计员并窃取他们的赏金/审计资金的理想途径。在引用任何新客户之前，请修补你的系统！并期待在接下来的几周内收到访客的消息...

原来你可以在比赛中获得五位数的奖金，而实际上并不需要发现任何问题，只需要一个半功能的大脑。 在2024年3月的OP Fault Proofs比赛中，开发者在比赛开始前一天修复了一个关键问题，但并没有合并它。🔗 只需查看公共提交日志，你就能获得高额奖金 🔗 🔗 最终获得了$16680的奖金： 这只是找到范围内漏洞而不实际寻找它们的众多技巧之一。总是要努力聪明地工作，而不是辛苦工作。