• 问： 分析下：False negative - that one is going to kill you: Understanding Industry Perspectives of Static Analysis based Security Testing

在尝试为您在互联网搜索相关资料…
始获取资料…
找到了第 1 篇资料：[2307.16325] "False negative – that one is going to kill you … https://arxiv.org/abs/2307.25
找到了第 2 篇资料：1 POSTER: ‘False negative - that one is going to kill you … ps://www.ndss-symposium.org/wp-content/uploads/ndss24-posters-3.pdf
找到了第 3 篇资料："“False negative - that one is going to kill you”: … https://dblp.org/rec/journals/r/abs-2307-16325
找到了第 4 篇资料：“False negative – that one is going to kill you”: … ps://paperswithcode.com/paper/false-negative-that-one-is-going-to-kill-you
找到了第 5 篇资料：2307.16325 - "False negative – that one is going to kill you … https://www.rgentmind.com/papers/2307.16325
找到了第 6 篇资料：NDSS Symposium 2024 Accepted Posters - NDSS Symposium https://www.s-symposium.org/ndss2024/accepted-posters/
找到了第 7 篇资料：“False negative - that one is going to kill you”: … https://www.semanticscholar.org/paper/False-negative-that-one-is-going-to-kill-you"%3A-of-Ami-Moran/4d2b5eb3a76d2e8c227e06bd9dab7de90fbf5ce3
找到了第 8 篇资料：“False negative – that one is going to kill you”: … https://www.earchgate.net/publication/784695_False_negative_--_that_one_is_going_to_kill_you_Understanding_Industry_Perspectives_of_Static_Analysis_based_Security_Testing
找到了第 9 篇资料：1 静态分析概述 | 静态分析 - 爱扑bug的熊 https://static-analysis.cuijiacai.com/intro/
找到了第 10 篇资料：2024 IEEE Symposium on Security and Privacy (SP) https://www.computer./csdl/proceedings/sp/2024/1RjE8VKKk1y
一共找到 10 篇资料，正在阅读…

这篇文章的标题是“False negative - that one is going to kill you”: Understanding Industry Perspectives of Static Analysis based Security Testing，由Amit Seal , Kevin Moran, Denys Poshyvanyk, 和 Adwait Nadkarni撰写。文章的核心内容是探讨了静态分析安全测试（SAST）工具在工业界的应用情况，以及开发者如何感知、选择和使用这些工具。过定性研究的方式，对20位具有不同软件开发专长和安全、产品、组织背景的从业者进行了深入的半结构化访谈。
以下是文章的一些关键点：

1. 研究背景：随着对自动化安全分析技术（如SAST）的需求不断增长，了解开发者如何感知SAST工具、他们的期望、对工具局限性的了解以及如何应对这些局限性变得至关重要。
2. 研究目的：研究旨在探索使用SAST的开发者的假设、期望、信念和所面临的挑战，以期改进工具设计，使其更有效地被实践应用。
3. 研究方法：研究通过两阶段的方法进行，先是在线调查，然后是深入访谈。调查旨在初步了解现状，并指导访谈协议的设计。访谈则更深入地分析了从业者的观点。
4. 主要发现：研究识别了17个关键发现，这些发现揭示了开发者对SAST的看法和期望，并挑战了SAST设计优先级的长期信念。
5. 开发者的感知和期望：开发者对SAST工具的期望包括易用性、能够检测漏洞，以及对工具局限性的理解。他们还表达了对SAST工具过度乐观和信任的问题。
6. 局限性和期望：开发者对SAST的局限性（如误报和漏报）有不同程度的了解，并且他们对如何处理这些局限性有着自己的看法。
7. 未来方向：文章为研究人员和从业者提供了基于研究发现的具体未来方向。
8. 行业观点：文章强调了行业对SAST工具的依赖，以及当SAST工具未能检测到漏洞时可能带来的风险。
9. 发表情况：该研究可能在2024年IEEE安全与隐私研讨会（SP）上发表。
10. 研究支持：这项工作得到了NSF等机构的部分支持。

文章通过深入分析和访谈，提供了对SAST工具在工业界应用的全面理解，并指出了工具设计和应用中存在的问题，以及开发者对这些问题的看法。这对于改进SAST工具的设计和使用具有重要意义。

• Kimi 先搜索了10个资料。其中 9 个和这篇文章强相关，而且这些网站基本上是我们获得学术信息的主要渠道。

  • 第一个：从 arXiv.org（这个知名的预印本（preprint）存档和分发服务网站）中，找到了这个研究草稿。这个平台由康奈尔大学图书馆运营，并且得到了全球学术社区的支持。它为物理学、数学、计算机科学、定量生物学、定量金融、统计学、电气工程、系统科学以及经济学等领域的学者提供了一个平台，用于分享和存储他们的研究成果；
  • 第二个：从 https://www.ndss-symposium.org (NDSS Symposium，即Network and Distributed System Security Symposium (网络与分布式系统安全研讨会))，这个专注于网络和系统安全领域的顶级国际会议的网站中，找到了这个篇文章的上传记录。NDSS是一个学术会议，主要发布经过同行评审的高质量研究论文。会议内容覆盖了广泛的网络安全主题，包括但不限于密码学、网络基础设施安全、系统安全、隐私保护、安全协议、恶意软件分析等；
  • 第三个：从 dblp.org 这个提供计算机科学领域文献信息的在线数据库中，找到了这篇文章。dblp 最初是在1993年由特里尔大学（University of Trier）创建的，现在由德国的达格施图尔研究中心（Schloss Dagstuhl）运营和进一步开发；
  • 第四个：从 https://paperswithcode.com Papers With Code（PWC）这个专注于机器学习和人工智能领域的在线平台中找到了这篇文章。PWC 的核心特点是将研究论文与其对应的开源代码库联系起来，使得研究人员和开发者可以轻松地找到实现特定算法或模型的代码。
  • 第五个：从 https://www.emergentmind.com 这个专注于人工智能研究的在线平台中找到这篇文章；
  • 第六个：这篇文章被 NDSS 2024 收录的信息；
  • 第七个：从 Semantic Scholar（https://www.semanticscholar.org/）这个免费的、人工智能驱动的搜索引擎中找到这篇文章。这个网站专门用于搜索科学文献。它由艾伦人工智能研究所（Allen Institute for Artificial Intelligence, AI2）开发，旨在帮助研究人员快速找到相关的学术论文，特别是那些可能被传统搜索引擎忽略的论文；
  • 第八个：从 ResearchGate（https://www.researchgate.net）找到这篇文章。这个网站是面向科学家和研究人员的社交网络平台，旨在促进科学合作和知识分享；
  • 第九个：一篇关于静态分析的博客
  • 第十个：这篇文章将参与 https://www.computer.org 举办的 2024 五月在美国旧金山举行的《安全与隐私（SP）研讨会》的信息。该网站是 IEEE Computer Society（电气和电子工程师协会计算机学会）运营的 是一个专业的在线平台，旨在为计算机工程、技术和信息技术领域的专业人士、研究人员、学生和爱好者提供服务。

• 给出了这篇文章的主要信息，包括作者，核心探讨的问题：静态分析安全测试（SAST）工具在工业界的应用情况，以及开发者如何感知、选择和使用这些工具。

  • 从论文需要涵盖的主要要素进行了总结，这包括：背景、目的、研究方法、发现、局限性、未来方向做了阐述。
  • 从这些要素的描述中，我们可以得到这篇论文的大致框架和要探讨的问题。文章通过定性（访谈汇总）的方式，探讨了开发者对静态分析工具的选择和使用过程中对误报和漏报的感知。作者在研究和分析过程中总结了 17 个发现。我们可以试图从这些发现中，探寻开发人员，以及静态分析工具的开发者对静态分析工具的诉求和期望，从而引领静态分析工具未来的发展方向。

• 满意度: 4 分
  总体回答比较满意，但每个关键点的概括，过于简单，没有达到想象的期望。

• 问： 分别对这17个发现的细节做出描述，并将这些发现进行分类

在搜索结果中提供的信息有限，但我会根据提供的内容尝试对这些关键发现进行分类和详细描述：

1. 安全的重要性与个人及组织的关系

• 发现：个人和组织对于安全的看法可能不同，这影响了SAST工具的选择和使用。

2. SAST工具的选择过程

• 发现：选择SAST工具时，依赖于推荐、声誉、易用性、集成便利性、成本或合规要求。

3. 对SAST局限性的认知

• 发现：开发者对SAST的局限性（如误报和漏报）有一定了解，但可能缺乏对这些局限性影响的全面认识。

4. 误报与漏报的容忍度

• 发现 ：开发者更倾向于容忍误报而不是漏报，因为漏报可能导致严重的安全隐患。

5. 对SAST工具的不合理信任

• 发现 ：开发者可能对SAST工具有过度的信任，这可能阻碍他们对工具进行必要的评估和验证。

6. 使用SAST补充手动分析

• 发现 ：SAST工具被用来补充手动分析的不足，帮助发现开发者可能未意识到的漏洞。

7. 开发者对误报的态度

• 发现 ：开发者普遍反对让开发者自行定义“有效”的误报或决定何时运行SAST。

8. 规避开发者的风险

• 发现 ：存在一些开发者可能会尝试绕过SAST工具的检查。

9. 报告SAST缺陷的犹豫

• 发现 ：开发者可能因多种原因（如以往负面经历或组织内部问题）犹豫是否报告SAST的缺陷或漏报。

10. 减少漏报与误报的权衡

• 发现 ：开发者宁愿接受一定数量的误报，也不愿意漏掉真实的安全漏洞。

11. SAST的选择与组织需求

• 发现 ：在选择SAST时，开发者会考虑工具的性能和组织的具体需求。

12. 对基准测试的不信任

• 发现 ：开发者普遍不信任基准测试，认为它们可能过于基础或对特定工具有偏见。

13. 安全整合进产品开发生命周期

• 发现 ：开发者对于如何将安全整合进产品开发生命周期有不同的理解和实践。

14. SAST在组织中的角色

• 发现 ：开发者对SAST在组织中的作用和依赖程度有不同的看法。

15. 安全期望与实际使用的差异

• 发现 ：开发者对SAST的期望可能与他们实际使用工具的方式不一致。

16. 对SAST改进的建议

• 发现 ：开发者对如何改进SAST工具有具体的想法，以更好地满足他们的需求。

17. 未来研究方向

• 发现 ：研究提出了基于开发者期望和工具局限性理解的未来研究方向。

• 分类
  这些发现可以被分为几个主要类别：

  • 个人与组织的安全观念差异（1, 13, 14）
  • SAST工具的选择与使用（2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12）
  • 对SAST局限性和误报漏报的态度（3, 4, 7, 9, 10）
  • 基准测试与工具评估（12）
  • 产品开发中安全的角色（13）
  • 改进建议与未来方向（16, 17）

请注意，这些分类和描述是基于搜索结果中的信息。为了获得更全面的理解，建议查阅原始论文以获取每个发现的详细内容和深入分析。

单从分类的描述来说，输出的六个分类，可以归纳为以下三个：

• 个人与组织的安全观念差异。 可以包括：产品开发中安全的角色；
• SAST工具的选择与使用。可以包括：对SAST局限性和误报漏报的态度、基准测试与工具评估；
• 改进建议与未来方向。

这样就不会存在一个发现归属多个分类的问题。

输出的最后一句话，让我引起了我的疑问。

“请注意，这些分类和描述是基于搜索结果中的信息。为了获得更全面的理解，建议查阅原始论文以获取每个发现的详细内容和深入分析。”
难道引擎并未看实际的原文？完全是从前面搜索的结果进行了推断？

• 满意度: 3 分
  分类没有达到预期，只能说可以接受。

• 问： 阅读 https://arxiv.org/pdf/2307.16325 这个文章，详细阐述17个发现的具体内容

在阅读了您提供的链接中的文章后，以下是对文章中提到的17个关键发现的具体内容的详细阐述：

1. 安全优先级与截止日期的冲突：开发者普遍倾向于优先考虑安全性，即使这可能意味着错过功能发布的截止日期。

2. 特定情况下安全性的降优先级：在某些情况下，如维护现有功能或修复重要用户正在经历的错误，安全性可能会被降优先级。

3. 在组织成长的早期阶段可能完全忽略安全性：特别是当客户不关心安全性，或者组织处于早期增长阶段时，可能会优先发布功能。

4. 选择SAST工具的原因：选择SAST工具通常基于推荐/声誉、易用性/集成、企业压力、成本或合规要求。

5. 对基准测试的态度：开发者通常不信任基准测试，认为它们要么太基础，无法模拟真实问题，要么对特定SAST有偏见。

6. SAST的有用性：开发者认为SAST对于减少开发者的工作量和帮助发现主观手动分析可能遗漏的问题非常有用。

7. 不依赖SAST的原因：一些开发者不使用SAST，理由是产品不需要广泛的测试，或者因为通用的SAST会将功能（例如处理标准规定的易受攻击的HTTP请求）标记为漏洞。

8. 对SAST的期望：开发者期望SAST能够检测所有在范围内的漏洞，但他们通常不期望SAST能检测所有类型的安全漏洞。

9. 即使错过某些漏洞也认为SAST有价值：开发者认为，即使SAST错过了某些漏洞，它们仍然是有价值的，因为发现一些问题总比没有发现要好。

10. 减少误报与误漏的权衡：几乎所有从业者都表示更喜欢更少的误漏，即使这意味着要接受更多的误报。

11. 对误报的容忍度：与文献中提出的20%的上限相比，从业者通常对误报有更高的容忍度，鉴于他们的偏好和他们当前使用的工具，有些人甚至发现80%或更多的误报是实际可行的。

12. 有效误报和SAST：从业者普遍反对让开发者定义“有效”的误报，或者让他们决定何时运行SAST。

13. 不健全SAST的影响：从业者并不过分担心SAST中未知的不健全问题的影响，因为他们期望后续的手动审查能够发现SAST遗漏的内容。

14. 开发者可能对SAST的缺陷视而不见：开发者可能会假设SAST正常工作，并且因此简单地忽略任何SAST的误漏或缺陷。

15. 报告SAST缺陷的犹豫：参与者可能会犹豫是否要报告SAST中的缺陷/误漏，原因包括以前与SAST的负面经历（包括对报告的缺陷不采取行动），或者组织内部的问题，如保持产品机密性的需要（没有明确的保密协议），繁文缛节，以及缺乏执行额外工作的动力。

16. 规避开发者的风险：尽管一些参与者认为“规避开发者”的场景通过现有的代码审查得到了充分的预防，但这种乐观情绪并不普遍：其他人有团队中规避开发者的先前经验，或者自己尝试规避过SAST。

17. SAST工具的主要痛点：开发者对SAST工具的主要痛点包括：误漏、缺乏有意义的警报消息/报告，以及配置/集成到产品CI/CD管道中的问题。

这些发现提供了对SAST工具在工业界中应用的全面理解，并指出了工具设计和应用中存在的问题，以及开发者对这些问题的看法。这对于改进SAST工具的设计和使用具有重要意义。

指定了具体的文件后，输出的结果和实际的内容基本上一致了。从比较可以看出上一个回答的 17 个发现，虽然有文中的 17 个发现的影子，但很多还是不一致的。所以在提问的时候需要加上严格的或尽可能的定语以明确讨论的范围。

下面是实际文档中的研究发现，在文档中已经将这些发现做了分类。我也把自己感知的放在了每个分类的后面做了陈述。具体如下：

• 组织与安全

  • 发现-1：参与者普遍表示，他们在安全方面犯了错误，无论截止日期如何，在发布功能之前都会修复任何已知漏洞。
  • 发现-2: 某些情况可能导致软件安全优先级降低，包括保持对现有功能的支持，或修复知名用户遇到的错误。
  • 发现-3: 与会者表示，在某些情况下，组织可能会完全放弃安全考虑，并优先考虑尽快发布功能，尤其是在客户不关心或组织处于早期发展阶段时。

• 实际感知:

  • 发现-1 给出了调研中一个普遍的认知：安全问题大于实际的发布时间。
  • 发现-2、发现-3 给出了发现-1 的两个特例。
  • 对于 SAST 工具的使用多为大企业，小企业优先要解决的问题是生存（业务），还无暇顾及安全问题，安全可以在有了资金后进行修补。

• SAST的组织背景

  • 发现-4: 参与者通常回忆起由于推荐/声誉、易用性/集成、公司压力、成本或合规性要求等因素而选择 SAST。只有一名参与者通过使用（自定义）基准对 10-15 种工具进行详尽测试，为他们的产品选择了 SAST。
  • 发现-5: 了解基准的参与者通常不信任它们来评估/选择 SAST，认为基准要么过于基础而无法模拟实际问题，要么偏向于特定的 SAST，因为供应商经常为他们的构建做出贡献。
  • 发现-6: 参与者认为 SAST 对于减少开发人员的工作量和帮助涵盖主观手动分析可能遗漏的内容非常有用。
  • 发现-7: 少数不使用 SAST 的参与者表示，他们的产品缺乏“契合度”：即，产品不需要广泛的测试（与先前工作中的类似观察结果相呼应），或者因为通用 SAST 将功能（例如，处理标准规定的易受攻击的 HTTP 请求）标记为漏洞。

• 实际感知:

  • 发现-4、发现-5 给出了组织选择 SAST 工具的主要参考依据：成本、知名度。对 SAST 工具本身的能力并未做详细的测评，这主要是业界缺少对工具的评测标准。
  • 发现-6 给出了大家认可 SAST 工具能够减少人工排查问题的工作量，有一定的作用。
  • 发现-7 给出了不使用 SAST 工具的原因，这个和前面发现结果：小企业必须优先解决生存压力相吻合。
  • 确实如发现结果所述，业界缺少一个 SAST 工具的具体的衡量标准，由于程序实现的多样行，无法量化工具的检查能力。虽然有一些用例集可以做出一些基本的测试，但这个很容易被工具厂商有针对性的用例进行处理，从而达到一个理想的测试结果。反过来我们是否可以这样思考，如果连这些基本的测试用例都不能通过，是否说明工具更加无法发现实际代码中复杂的场景。在实际的评估过程中，可以通过：用例集 + 实际工程的方式进行评估。但这也意味着更大的评估成本，同样由于少量验证工程的特殊性，很多时候测试结果仍无法真实的反映工具的能力范围。
  • SAST 检测能力的评估，也一直是业界在不断探讨的话题。目前来看，无法有一个有效的、简单的、量化衡量方法。
  • 关于这部分的讨论可以参看:《静态分析工具的评估测试》。

• SAST 开发人员的期望

  • 发现-8: 尽管表示没有工具可以找到所有内容，但参与者认为 SAST（应该或确实）检测范围内考虑的所有漏洞（即 SAST 工具声称检测的漏洞）。
  • 发现 9: 参与者认为 SAST 即使错过了某些漏洞也很有价值，因为找到一些东西总比没有好。
  • 发现-10: 几乎所有从业者都表示倾向于减少漏报，即只要 SAST 能够找到有效的安全漏洞，他们就会容忍甚至宁愿以许多误报为代价来减少误报。
  • 发现-11: 考虑到他们的偏好和他们目前使用的工具，从业者通常比文献中提出的 20% 上限更能容忍误报，有些人甚至发现 80% 或更多的误报是可行的。
  • 发现-12: 从业者通常反对让开发人员定义“有效”误报，或让他们决定何时运行 SAST。这种保留源于他们之前对在代码中留下漏洞的不利成本的经验，和/或他们对开发人员的了解 （1） 缺乏对漏洞影响的理解，（2） 容易错误地将实际问题标记为误报，（3） 不可信/偏向于将问题标记为有效的误报。

• 实际感知:

  • 这部分引出了 SAST 最关心的一个话题，如何平衡漏报和误报，每个使用者都希望漏报和误报越小越好，误报和漏报客观存在的主要原因有以下几种；
    • Rice 定理已经从理论上证明: 无法使用一个程序去完全判断另一个程序存在的错误；
    • 对问题的判断模式越精确，势必引入更多的判断条件和大量的计算，这必然会导致扫描空间和时间的增加，而时间、空间是有限的，工具必须在实际的应用中对误报和漏报做出平衡；
    • 由于输入的不确定性，不可避免的为工具引入了误报或漏报；
    • 工具无法识别的缺陷场景，例如不同的应用框架对信息的不同传递机制和事务流；
    • 第三方库在以二进制方式引入的时候，导致的分析工具对第三方库所使用户函数的行为不确定性，引入的误报和漏报。
  • 这里提到了一个误报率的容忍度 20% 的问题。
    • 这个量值最初是由一篇关于 google 内部 Tricoder 平台使用静态分析工具的文章引入的这个量值。如果平台上的工具的误报率 >= 15%, 就进入观察期，当大于 >= 25%，则规则下线；
    • 但请注意：在文中所涉及的静态分析工具主要为 lint 类型的检测工具，这类工具只对代码进行浅层次的语义分析，检查的问题多为质量类型的缺陷，并不涉及进行过程间的深度分析，所以通常工具都可以达到这样一个精度。
    • 对于业界高危的漏洞，往往需要采用数据流的分析例如 log4j 之类问题的分析，工具往往需要采用污染传播的分析方式，分析十几个文件，几十个的函数调用，才能发现。再比如 缓冲区溢出，业界的 TOP 分析工具的实际误报率都会高达 60% 以上。这也是为什么文中对于一些高危的漏洞的容忍度可以到达 80%；
    • 因此对于误报容忍度的问题，需要区分所检测问题的危害程度。危害程度越高，自然开发人员的容忍度也会越高，因为一但有一个这类问题暴漏出去，对应用系统的打击都是致命的。
    • 对于不同的类型的静态检查工具用于不同的检查阶段的讨论可以参考：构建DevSecOps中的代码三层防护体系
  • 发现-12 引出了一个误报审计的问题，发现列举了普通的开发人员会错误将告警标记为误报的三个主要原因。所以通常我们会在流程中增加误报的审核这样一个步骤，以减少误标记导致遗漏的可能性。

• 不健全/有缺陷的 SAST 的影响

  • 发现-13: 从业人员并不过分担心 SAST 中未知的不健全问题的影响，因为他们希望随后的人工审查能够发现 SAST 遗漏的内容。
  • 发现-14: 开发人员可能在抵触状态下使用 SAST，即假设 SAST 只是工作，因此，简单地忽略了任何假阴性的证据，或导致假阴性的 SAST 缺陷。
  • 发现-15: 参与者可能出于多种原因对报告 SAST 中的缺陷/漏报犹豫不决，包括之前对 SAST 的负面体验（包括对报告的缺陷不采取行动）或组织内部的问题，例如需要维护产品机密性（没有明确的 NDA）、繁文缛节以及缺乏执行额外工作的动力。
  • 发现-16: 逃避开发人员的风险是真实存在的。也就是说，虽然一些参与者认为现有的代码审查已经充分防止了“规避开发人员”的情况，但这种乐观情绪并不普遍：其他人在他们的团队中已经有规避开发人员的经验，或者他们自己也规避了 SAST。

• 实际感知:

  • 发现-13 到 发现-14 更多的是开发人员对待漏报的态度。
    • 由于我们前面讨论的漏报和误报的原因，以及 SAST 工具存在分析的不健全（unsound），漏报会是普遍存在的，而且通常程序员是无法感知的;
    • 在开发任务繁重的情况下，去处理 SAST 工具的大量的分析结果，人的惰性也自然会让大多数开发人员采用了悄然漠视的态度对待可能的漏报；
    • 当大部分程序员将软件开发作为一种职业，一项为生活换取必须品的时候，SAST 工具的检查也只是被认为是一项工作，漠视漏报也会成为一种常态；
    • 对程序中的漏洞，职业道德教育会显得很乏力，只能通过提升 SAST 的检查能力，以及管理流程的完善，来降低应用程序中漏洞被发生的可能性；
    • 当然对静态分析工具的必然需求，也会在某种程度上激发 SAST 工具从业者的使命感，提升工具的检查能力和检查精度，发现应用程序中更深层的漏洞。

• 挑战和改进

  • 发现-17: 开发人员在使用 SAST 工具时的主要痛点包括：漏报、缺乏有意义的警报消息/报告以及配置/集成到产品 CI/CD 管道中。

• 实际感知:

  • 发现-17 给出了开发人员使用 SAST 工具的几个主要痛点。
    • 漏报
      • 原因：
        • 随着算力和存储空间的增大，代码的规模正变得越来越大；
        • 业务的复杂性也导致代码的逻辑和复杂度变的更高；
        • 在一个应用系统中多个开发语言的使用，也进一步增加了代码从端到端的检查复杂性；
        • 静态分析技术虽然自变成语言产生以来变应运而生，但这些年来以模式匹配、异常检测的方式发现软件漏洞的算法没有质的突破；
        • 加上我们前面分析的漏报和误报的原因。
      • 解决方法：
        • 由于这些因素，在短时间内，漏报和误报还无法得到有效的解决。目前火热的大模型应该能够给静态分析带来一次变革。
        • 大模型在训练数据上存在很大的致命的问题，即代码中存在潜在的漏洞。依照Synopsys的《2024年的开源风险报告》中指出77%的代码源于开源代码，在开源代码中 84% 的包含风险评估的代码库至少包含一个已知的开源漏洞；这些代码库中有 74% 包含高风险漏洞。这有需要我们在训练材料上通过静态分析工具做出有效的筛选。
    • 缺乏有意义的警报消息/报告
      • 原因：
        • SAST 工具在分析代码时，留下了分析过程的信息，但这些信息往往过于专业或随意，让开发人员难以理解；
        • 告警的规则名，往往不知所云，即使是专业的安全人员，也需要仔细推敲才能明白工具所要表达的问题；
        • 规则的描述信息过于简单，没有给出问题发生的原因，带来的后果，如何修改。
        • 程序员即使想改这个错误，也要花不少时间去寻找个问题的正确解决方式。有的时候即使反复修改，工具仍然会给出告警。这也是为什么文中也提到“聪明的程序员”为了完成任务，会巧妙的绕过工具的检查。
      • 解决方法：
        • 做工具要从产品的角度出发，产品服务的是广大的开发人员，需要把文档做的更加细致，提升用户的满意度。
        • 规则名要易于理解问题；规则描述需要涵盖问题发生的原因、场景，问题造成危害、修复建议，这里可以通过正确的示例和错误的示例给出示范，毕竟程序员最能懂的是代码。
        • 规则的内容中还可以包含规则的出处、参考、相关的规范，这些延申的信息，有助于有追求的开发人员进一步探索问题的本源，更清楚的理解问题，起到培训和教育的作用。
    • 配置/集成到产品 CI/CD 管道
      • 原因：
        • 静态分析工具在对输入信息的处理上主要分为：编译和非编译两种。编译型的分析工具可以获得更准确的获得代码的依赖信息，能够在很大程度上减少误报和漏报。但编译是软件产品发布中最复杂的一个环节。不同的编译器、不同的编译器版本、不同的编译环境、不同的编译依赖信息的获取、不同的构建工具，特别是上百种的 C 编译器的适配。这些都会使工具的配置变的复杂起来。
        • 工具为了适应各种语言，各种场景，不得不提供大量的参数；
      • 解决办法：
        对主要的应用场景提供通用模板，以满足大多数用户的基本需求。

• 满意度: 4 分
  在得到明确的阅读文档后，输出的结果和实际的内容基本上一致了。但没带给我惊艳的感觉，所以维持 4 分。

• 问： 业界商用工具的误报率和漏报率是多少，举例说明

2.4.1. Kimi 回答

业界商用静态分析安全测试（SAST）工具的误报率（False Positives, FP）和漏报率（False Negatives, FN）可以有很大的差异，这取决于多种因素，包括工具的复杂性、它们所使用的分析技术、被分析的代码库的特性，以及工具的配置和定制化程度。由于这些变量的广泛性，很难给出一个具体的误报率或漏报率的数值，适用于所有商用SAST工具。
然而，根据安全研究和行业报告，一些工具可能会有以下特点：

1. 误报率：一些高质量的SAST工具可能会将误报率控制在相对较低的水平，比如20%以下。这意味着在所有被报告的潜在问题中，最多有20%实际上是无害的误报。然而，一些工具可能会有更高的误报率，特别是那些使用较宽松的检测标准以捕获更多可能漏洞的工具。

2. 漏报率：漏报率通常更难量化，因为它涉及到未被工具检测到的漏洞。一些工具可能专注于不遗漏关键或高危漏洞，即使这意味着会有更多的误报。在某些情况下，工具的漏报率可能与特定类型的漏洞、代码库的复杂性或使用的特定编程语言有关。

举例说明：

• Coverity：根据一些案例研究和用户反馈，Coverity工具以其较低的误报率而闻名，这得益于其强大的数据流分析和路径敏感分析技术。

• SonarQube：SonarQube是一个广泛使用的代码质量分析平台，它包括安全漏洞检测。虽然SonarQube提供了大量有用的安全相关信息，但在某些情况下，用户报告了相对较高的误报率，这可能需要手动验证以确定真实性。

• Fortify：Micro Focus的Fortify是另一个知名的SAST解决方案，它提供了深入的代码分析和广泛的安全测试。Fortify的用户可能会根据其配置和使用的具体版本，体验到不同程度的误报和漏报。

值得注意的是，即使是最先进的SAST工具也可能无法达到100%的准确性。因此，许多组织将SAST工具作为多层安全测试策略的一部分，结合其他工具和技术，如动态分析（DAST）、渗透测试和代码审查。

为了获得关于特定工具误报率和漏报率的准确信息，最好的方式是查阅该工具的官方文档、用户手册或与供应商直接沟通，以及查看独立第三方的安全测试报告和用户评价。此外，一些工具可能提供基准测试和性能评估，这些也可以提供关于误报和漏报率的见解。

2.4.2. 输出结果分析

说实在的这个问题有些挖坑的意思，没想到回答有效的避免得罪厂商。

• 先是一个汇总影响误报率和漏报率的因素很多：

  • 工具的复杂性
    工具的类型不同，设计目标的差异，会使分析结果有很大的差异。也可以理解为每个工具擅长的检测问题不同；
  • 它们所使用的分析技术
    工具的设计检测目标，决定了工具所采用的分析技术的差异；
  • 被分析的代码库的特性
    检测目标的差异；
  • 以及工具的配置和定制化程度
    • 工具的检测策略，也会影响分析结果。比如：是采用尽可能多的发现问题，还是采用较小误报率；
    • 使否针对检测目标做了适配，比如污染源和爆发点的配置、函数行为的配置。做过适配和不做适配的扫描结果差异会很大。

• 分别阐述工具的误报率和漏报率

  • 给出误报率在检测工具上的差异，这里使用了比如 20%，并未给出具体的厂商；
  • 给出了漏报率难以量化的事实。也指出的由于检测目的对漏报率的影响。

• 举例说明

  • 列举了目前比较流行的三款商用工具；
  • coverity: 用户反馈误报率比较低，分析技术成熟；
  • sonarqbue: 指出了该工具在安全检测能力上的欠缺，误报率较高；
  • Fortify: 不同的用户反应不一。
  • 这三个工具在误报和漏报率上的描述基本上和我们的感性认知一致。

• 最后指出SAST 的局限性，无法达到 100%，需要结合动态分析（DAST）、渗透测试和代码审查。

• 满意度: 5 分

有点小惊艳，回答时有效的避开了敏感信息，以免引起不必要的商务纠纷，同时准确概括了问题的主要因素。

• 问： 就SAST工具的开发者，该如何降低工具的误报和漏报，分别给出建议

为了降低SAST工具的误报（False Positives, FP）和漏报（False Negatives, FN），开发者可以采取以下措施：

• 降低误报的建议：

1. 改进分析算法：持续优化静态分析算法以更准确地识别潜在的安全漏洞。

2. 上下文感知分析：开发更智能的上下文感知技术，以便更好地理解代码的意图和实际用途。

3. 机器学习和人工智能：利用机器学习算法分析大量的代码样本，以提高识别真正漏洞的准确性。

4. 开发者反馈循环：建立一个有效的反馈机制，让开发者可以轻松地报告误报，以便不断从实际使用中学习并改进。

5. 自定义规则：允许用户根据特定项目的需求定制和调整分析规则，减少不相关的警报。

6. 代码基准线：为新项目设立代码安全基准线，将已知的非漏洞行为纳入考量，减少误报。

7. 集成其他分析工具：与动态分析（DAST）和其他安全测试工具集成，通过多种方法交叉验证以减少误报。

8. 提供详细报告：生成详细的漏洞报告，包括漏洞可能产生的影响、位置和推荐修复步骤。

9. 持续教育：向开发者提供关于如何减少误报的指导和最佳实践。

• 降低漏报的建议：

1. 全面覆盖：确保SAST工具覆盖所有已知的安全漏洞类型和编码模式。

2. 定期更新数据库：定期更新漏洞和模式数据库，以识别新出现的安全威胁。

3. 深入代码分析：采用更深入的静态分析技术，如抽象解释、控制流分析和数据流分析。

4. 代码复杂性评估：对代码库中的复杂区域进行更细致的分析，因为这些区域可能更易出现漏洞。

5. 安全编码实践：提供安全编码指导和自动检测常见安全漏洞的模式。

6. 开发者培训：教育开发者关于安全最佳实践，以减少在编码过程中引入漏洞的可能性。

7. 代码审查集成：将SAST集成到代码审查过程中，以便在代码提交阶段捕获潜在的安全问题。

8. 使用真实世界的例子：通过分析真实世界的漏洞案例来训练和测试SAST工具。

9. 社区合作：与安全研究社区合作，共享关于新漏洞的信息，以便快速响应新出现的威胁。

10. 透明度和开放性：对SAST工具的工作原理和检测机制保持透明，以便用户和社区可以更好地理解和信任工具。

通过这些措施，SAST工具的开发者可以有效地降低误报和漏报，提高工具的准确性和用户的信任度。同时，这也需要开发者与用户之间持续的沟通和合作，确保工具能够适应不断变化的安全威胁和开发实践。

• 降低误报的建议

  • 从工具内部：改进分析算法、上下文感知分析、机器学习和人工智能；
  • 工具的使用：开发者反馈循环、自定义规则、代码基准线、集成其他分析工具；
  • 提供详细报告、持续教育，这两点有不同的看法，这个属于减少开发人员将扫描结果打成错误的误报的解决方法，不属于问题的针对SAST 的开发者。这里可能都是开发者，大模型无法有效区分这两个开发者的含义，给出了不合适的输出。

• 降低漏报的建议

  • 漏洞识别模式的改进：全面覆盖、定期更新数据库、深入代码分析、安全编码实践、代码审查集成、使用真实世界的例子、社区合作、透明度和开放性。
  • 减少漏洞发生：开发者培训。这个是减少漏洞的方法，虽然能间接的减少漏报率，属于治本的方法。一个字：绝！

• 满意度: 5 分
  给出我能想到的降低误报和漏报的主要方法。特别是在降低漏报中，给出了治本的方法。

• 问： 通过这边文章的内容，给出开发者选择SAST工具的主要因素，以及分析SAST工具的主要痛点，给出工具的改建建议

根据文章内容，开发者选择SAST工具的主要因素包括：

1. 声誉和推荐：开发者倾向于根据工具的行业声誉或者同事的推荐来选择SAST工具。

2. 易用性和集成：工具的用户友好性和集成便利性是选择的重要因素。

3. 企业压力和成本：成本效益和/或企业决策层的压力也会影响工具的选择。

4. 合规要求：为了满足特定的法规或标准要求，某些工具可能会被选用。

5. 基准测试：尽管开发者对基准测试的信任度不高，但它们可能仍作为选择工具时的一个参考因素。

分析SAST工具的主要痛点包括：

1. 误报和误漏的权衡：开发者更关注减少误漏（false negatives），即使这意味着接受更多的误报（false positives）。

2. 有效误报的问题：开发者通常不愿意让非安全专家的开发者来决定哪些是有效的误报。

3. 不健全SAST的影响：开发者对SAST工具的不健全问题（如未检测到声称能检测的漏洞）并不过分担心，因为他们依赖手动审查来补充。

4. 报告缺陷的挑战：开发者在报告SAST工具缺陷时可能会犹豫，这可能是由于以前与SAST供应商的负面经历，或组织内部的问题。

5. 规避开发者的风险：存在开发者可能会尝试绕过SAST工具检查的风险。

6. 配置和集成问题：SAST工具与现有CI/CD管道的集成可能是一个挑战。

基于上述分析，以下是对SAST工具改进的建议：

1. 提高真实漏洞检测率：开发者希望SAST工具能够检测到所有声称范围内的漏洞，因此提高工具的漏洞检测能力是至关重要的。

2. 减少误漏：相比于误报，开发者更关注减少误漏。工具开发者应致力于降低误漏率，即使这可能会稍微增加误报率。

3. 改进误报处理：提供更好的误报分类和管理机制，帮助开发者更有效地筛选和处理误报。

4. 强化与CI/CD的集成：改进SAST工具与持续集成/持续部署（CI/CD）管道的集成，使其更易于配置和使用。

5. 提供有意义的警报：生成更具体、更有指导性的警报消息，帮助开发者理解漏洞的性质和如何修复。

6. 建立更透明的缺陷报告流程：为开发者提供一个明确、透明的缺陷报告和跟踪流程，鼓励他们报告SAST工具的不健全问题。

7. 提供有效的开发者培训：为开发者提供关于如何有效使用SAST工具的培训，包括如何解读和行动警报。

8. 社区和行业合作：鼓励SAST工具供应商与开发者社区合作，收集反馈，持续改进工具。

9. 开发更全面的基准测试：开发和使用更全面的基准测试，帮助开发者客观评估SAST工具的性能。

10. 鼓励开源和透明度：鼓励开源SAST工具的发展，以增加透明度和社区的参与度，从而提高工具的质量和信任度。

• 选择SAST工具的主要因素

  • 企业压力和成本、合规要求。这两个因素是刚性的指标，在实际的选择时，会产生至关重要的作用；
  • 基准测试、易用性和集成。这两个因素是检查能力的反映，也是工具的核心竞争力；
  • 声誉和推荐。这个是工具拥有核心竞争力后，逐步积累起来。

• SAST工具的主要痛点

  • SAST工具的设计：误报和误漏的权衡、不健全SAST的影响。这里有个小错误漏报说成了“误漏”。误报和漏报是 SAST 工具永恒的话题。再加上扫描效率，构成了 SAST 工具的制约三角。
  • 其他四个是工具使用层面的痛点，这些是技术男做产品时，需要特别注意的几个因素。

• 对SAST工具改进的建议

  • 一句话，总结的不错。

• 满意度: 4 分
  三个问题都得到了满意的答案。尽管有一个小输出错误。

• 问： 总结开发者对SAST工具的需求和期望

开发者对SAST工具的需求和期望可以总结为以下几点：

1. 准确性：开发者期望SAST工具能够准确地识别出代码中的安全漏洞，同时最小化误报（False Positives）和漏报（False Negatives）。他们希望工具能够提供高置信度的报告，以便能够专注于真正的安全威胁。

2. 易于集成：开发者希望SAST工具能够无缝集成到现有的开发流程和工具链中，包括持续集成/持续部署（CI/CD）流程，以便在软件开发生命周期的早期阶段捕捉潜在的安全问题。

3. 可操作的反馈：SAST工具应该提供清晰、具体的反馈，包括详细的漏洞描述、修复建议和修复优先级，帮助开发者快速理解和解决安全问题。

4. 上下文感知：开发者期望SAST工具能够理解代码的上下文，区分实际的安全问题和非安全问题，减少误报，并提供与项目特定的安全需求相关的分析。

5. 性能和效率：SAST工具应该在不会显著影响开发速度和软件性能的前提下进行安全分析。开发者希望工具能够在不牺牲准确性的情况下，快速地分析大型代码库。

6. 用户友好的界面：工具应该具有直观的用户界面，使得非安全专家的开发者也能轻松地理解和使用。这包括易于导航的报告、清晰的指示和帮助文档。

7. 灵活性和可配置性：开发者希望SAST工具能够根据组织的安全策略和需求进行定制。这可能包括自定义规则、插件或扩展，以及与现有安全工具和流程的兼容性。

8. 持续的支持和更新：随着新的安全威胁和漏洞的出现，开发者期望SAST工具能够定期更新其漏洞数据库和分析引擎，以保持最新的安全防护能力。

9. 教育和培训：开发者期望SAST工具提供商能够提供充分的教育和培训资源，帮助他们更好地理解工具的功能和最佳实践。

通过满足这些需求和期望，SAST工具可以更有效地帮助开发者提高软件的安全性，同时减少对开发流程的干扰。

这些关注点可以总结为以下几点：

• 工具能力：准确性、上下文感知、性能和效率。做为工具的硬实力，必须扎实；

• 工具软实力：易于集成、用户友好的界面、灵活性和可配置性。让用户容易用，用的好，无疑会让工具更容易推广；

• 售后服务：可操作的反馈、持续的支持和更新、教育和培训。和客户的沟通和持续改进是维系商业成功的重要因素。

• 满意度: 4 分
  说出了作为一个用户期望的 SAST 工具成功的主要要素。