好的，我现在需要帮用户总结一篇文章的内容，控制在100字以内。用户已经给出了文章的原文，我得先仔细阅读一下，理解其主要内容和重点。 文章主要讨论了安全工具在识别漏洞方面的能力。作者提到，大多数工具擅长指出“有什么问题”，比如依赖项中的CVE、SQL注入风险、敏感数据泄露等。但这些工具在解释“这有什么影响”方面表现不佳。作者举例说明，即使发现了一个路径遍历漏洞，但如果没有上下文信息，比如该漏洞是否能被用户访问到、是否涉及敏感数据等，就无法准确评估其实际影响。 接着，作者指出由于缺乏上下文，所有漏洞都得到了相同的处理方式。例如，影响公共端点的严重漏洞和死代码中的理论问题被同等对待。这导致了优先级的混乱：核心用户流程中的中等漏洞可能得不到应有的关注，而仅限于少数人使用的高严重性漏洞却吸引了更多注意力。 为了改善这种情况，作者提到他们正在开发名为Kolega的工具，并尝试为安全发现添加更多业务背景信息。这样做显著改变了漏洞的优先级排序，从“先修复所有红色”转变为“先修复真正影响用户的”。作者还表达了对其他团队如何处理这一问题的好奇心，并询问是否有方法将安全发现与实际业务影响联系起来，还是大家仍然主要依赖严重性评分。 总结下来，文章的核心观点是现有安全工具在提供上下文信息方面存在不足，导致漏洞处理效率低下。引入业务背景信息可以有效提升优先级管理，并希望了解其他团队的做法。 现在需要将这些内容浓缩到100字以内。要抓住关键点：安全工具擅长识别问题但缺乏上下文分析；缺乏上下文导致优先级混乱；引入业务背景信息能改善这一状况；以及对其他团队做法的兴趣。 可能的结构是：首先说明工具的问题（识别问题但不分析影响），然后指出缺乏上下文带来的后果（优先级混乱），接着介绍解决方案（引入业务背景），最后提到对其他团队做法的兴趣。 确保语言简洁明了，避免使用复杂的句子结构。 </think> 文章讨论了现有安全工具在识别问题上的能力与缺乏上下文分析的问题。由于缺少上下文信息（如漏洞是否可被利用、是否涉及敏感数据等），所有安全发现都得到了同等对待，导致优先级混乱。引入业务背景信息可以有效提升漏洞管理效率，并询问其他团队如何应对这一挑战。 2026-3-25 17:33:45 Author: www.reddit.com(查看原文) 阅读量:2 收藏
been thinking about this after looking at vulnerability reports from different teams
most security tools are pretty good at the "what"
* this dependency has CVE-2024-whatever
* this function might have SQL injection
* this secret was committed to git
* this container image has 47 vulnerabilities
but they're terrible at the "so what"
like, okay, there's a path traversal in some utility function
but is that function even reachable from user input?
is it behind authentication?
does it handle sensitive data?
would exploiting it actually matter for this specific application?
without that context, everything gets the same treatment
critical findings that affect public endpoints get the same urgency as theoretical issues in dead code
medium severity vulns in core user flows get less attention than high severity findings in admin-only features that three people use
we've been experimenting with ways to give findings more business context while building kolega, and it's wild how much it changes prioritization
instead of "fix all the reds first" it becomes "fix the things that actually affect users first"
curious how other teams handle this
do you have ways to map security findings to actual business impact, or is everyone still mostly going by severity scores and hoping for the best?been thinking about this after looking at vulnerability reports from different teams
most security tools are pretty good at the "what"
* this dependency has CVE-2024-whatever
* this function might have SQL injection
* this secret was committed to git
* this container image has 47 vulnerabilities
but they're terrible at the "so what"
like, okay, there's a path traversal in some utility function
but is that function even reachable from user input?
is it behind authentication?
does it handle sensitive data?
would exploiting it actually matter for this specific application?
without that context, everything gets the same treatment
critical findings that affect public endpoints get the same urgency as theoretical issues in dead code
medium severity vulns in core user flows get less attention than high severity findings in admin-only features that three people use
we've been experimenting with ways to give findings more business context while building kolega, and it's wild how much it changes prioritization
instead of "fix all the reds first" it becomes "fix the things that actually affect users first"
curious how other teams handle this
do you have ways to map security findings to actual business impact, or is everyone still mostly going by severity scores and hoping for the best?
如有侵权请联系:admin#unsafe.sh