源代码安全：从信号到经过验证的风险 | Ostorlab

扫描器在某个代码仓库中发现了一个危险函数。

这是一个信号。

它还不足以证明攻击者能够触及它、不足以证明不可信数据会流入它，也不足以证明没有其他控制措施让这条路径变得安全。正是这些问题决定了该代码是否代表一个真实的漏洞，以及开发人员是否应当放下手头的工作去修复它。

这就是源代码安全测试的核心问题。

发现可疑代码已经变得很容易。更难的部分在于把漏洞从噪声中区分出来、结合上下文解释风险，并为开发人员提供一个他们真正用得上的修复方案。

什么是源代码安全测试？

源代码安全测试在应用代码进入生产环境之前检查其中的弱点。它可以包括静态应用安全测试（SAST）、密钥检测、依赖分析、人工安全代码审查，以及 AI 辅助的调查。

NIST 将源代码安全分析器定义为一种检查源代码并报告可能导致安全漏洞的弱点的工具。这一区分很重要：一个可疑的弱点可能导致漏洞，但两者并不会自动等同。

一个有用的源代码安全流程应当回答四个问题：

1. 弱点在哪里？
2. 在这个应用中，它能否被触及或被利用？
3. 它可能造成什么影响？
4. 什么样的改动能够安全地修复它？

如果一个工具只回答了第一个问题，那么它为安全团队找到的是工作量，而未必是一个漏洞。

漏洞可以在应用运行之前就存在

安全问题不会坐等生产环境出现。

一个密钥可能早已被硬编码在配置文件中。一个有漏洞的依赖可能早已被固定在清单（manifest）里。用户可控的输入可能早已能够触及一个不安全的查询。一项授权检查可能早已在某个敏感操作中缺失。

这些情况成立，都不需要一个公开的 URL、一个测试账户，或一个正在运行的应用。

源代码测试使得在相关改动还记忆犹新时就捕获这些弱点成为可能。检测结果可以直接指向受影响的文件、函数和代码路径，而反馈可以在代码成为共享基础设施和生产风险之前送达开发人员。

这就是尽早测试的价值。但只有当结果值得信任时，早期检测才有帮助。

传统 SAST 如何发现漏洞

静态应用安全测试在不运行应用的情况下分析代码。根据引擎的不同，它可能会：

• 将代码解析为 token 或抽象语法树；
• 识别输入、敏感函数和已知的不安全模式；
• 跨函数追踪数据流和控制流；
• 识别净化器（sanitizer）和安全控制措施；
• 应用与漏洞类别相关联的规则或查询；
• 报告疑似问题以及产生它的路径。

以一个可能的 SQL 注入为例。仅仅找到一个数据库查询是不够的。扫描器必须判断攻击者可控的输入能否触及它、该输入是否经过参数化或净化，以及这条路径在实际中是否可能成立。

GitHub 对 SAST 架构的解释清楚地阐明了这一区分：找到一个敏感汇点（sink）本身并不能证明存在漏洞。相关的证据是从源头（source）到该汇点的不安全路径。

这正是简单模式匹配达到其极限的地方。

为什么源代码扫描器会产生误报

误报是指一个被报告的问题，它在扫描器看来很危险，但在应用的上下文中并不是真实的漏洞。

这种情况常常发生，是因为扫描器只看到了故事的一部分。它可能遗漏了另一个文件中的自定义净化器、无法理解某个框架控制措施、沿着一条不可达的路径前进，或把测试数据误认为是生产密钥。

常见原因包括：

• 不完整的数据流或控制流分析；
• 扫描器无法识别的自定义校验；
• 缺失的框架、依赖或构建上下文；
• 死代码或不可达代码；
• 测试值和示例配置；
• 基于通用弱点而非实际影响的严重程度评定。

OWASP 将误报、漏报，以及难以证明某个问题是真实漏洞列为静态分析的局限之一。

其代价不仅限于审查一条错误告警所花费的时间。反复出现的噪声会训练开发人员不再信任扫描器。当一个真实漏洞出现时，它进入的是一个所有人都已学会忽视的队列。

这就是为什么标准不应是“找出更多”，而应是“在要求开发人员采取行动之前，尽可能消除不确定性”。

从静态扫描到智能体式调查

传统扫描通常遵循一条短路径：

Pattern or query → match → alert

智能体式源代码安全则增加了一个调查层：

Signal → gather context → follow the path → challenge the hypothesis → assess impact → report or discard → propose a fix

智能体可以从一个可疑操作入手，检查周围的函数，追踪导入和调用路径，在代码仓库的其他地方寻找控制措施，测试其他替代解释，并在答案不明确时继续调查。

区别并不在于规则消失了。确定性分析在发现候选弱点方面仍然有用。智能体的工作是调查最初的信号在这个应用中意味着什么。

它可以提出单条规则往往无法回答的问题：

• 这个输入是否真的由攻击者控制？
• 受影响的函数是否可达？
• 校验是否应用在共享的中间件中？
• 这个可疑密钥是真实且被使用的，还是仅仅是一个示例值？
• 依赖中的某个有漏洞的能力是否真的被调用？
• 某个授权控制措施是否在流程的更早阶段就已生效？
• 利用该漏洞需要哪些条件？
• 可能的影响是否足以支撑所评定的严重程度？

结果不应是一条更长的告警，而应是一个更小的检测结果集合，并带有一条更清晰的证据链。

这正是 Ostorlab Source Code 背后的方法。Ostorlab 不会止步于一个可疑的匹配，而是将代码仓库上下文、受影响路径、严重程度、可利用性、业务影响和修复指导整合在一起。其源代码 Agent 旨在深入复杂路径和逻辑漏洞，然后返回开发人员可以审查并据以采取行动的检测结果。

验证如何在实践中减少误报

传统扫描器常常报告每一个可疑模式，然后把判断哪些检测结果是真实的这件事留给安全团队。

Ostorlab 将这项调查移入扫描本身。源代码 Agent 会追踪有漏洞的路径、检查周围的控制措施、评估可达性和可利用性，并丢弃那些在更深入分析下站不住脚的信号。

送达开发人员的是一个小得多的检测结果集合，每一个都带有受影响路径、影响、支撑性上下文，以及采取行动所需的修复指导。验证会减少误报。它并不能消除误报，因此每一个检测结果仍然附带审查者快速确认或否定它所需的证据。

这就是“生成更多告警”与“发现真正重要的漏洞”之间的区别。

源代码安全测试能看到什么——又看不到什么

源代码分析可以检测诸如以下的弱点：

• SQL、NoSQL、命令和模板注入路径；
• 不安全的文件操作和路径遍历；
• 跨站脚本和服务器端请求伪造模式；
• 硬编码密钥和不安全的加密使用；
• 不安全的反序列化；
• 有漏洞的依赖使用；
• 缺失的校验和安全控制措施；
• 身份验证和授权弱点；
• 不安全的状态转换和工作流绕过；
• 在存在足够上下文时的应用特定逻辑漏洞。

但源代码并不是整个系统。静态分析在面对仅存在于生产环境的配置、外部服务、基础设施关系、运行时状态，或仅存在于文档或人们脑海中的业务规则时，可能会力不从心。

这就是为什么源代码测试应当补充，而非取代其他形式的测试。

方法	它最擅长看到什么	它可能遗漏什么
SAST	执行前源代码内部的弱点	运行时和环境上下文
DAST	运行中应用的外部可观测行为	它无法触及或观测的内部路径
SCA	第三方依赖中的已知风险	有漏洞的能力是否真的可达
人工代码审查	架构、意图、自定义控制措施和业务逻辑	覆盖每一次改动的持续覆盖能力
智能体式源代码测试	覆盖整个代码仓库的上下文、迭代式验证和修复	代码之中或周围并不存在的上下文

OWASP 的安全代码审查指南同样将自动化分析与人工审查视为互补：自动化凸显可疑区域，而更深入的审查则处理工具可能遗漏的上下文、架构和逻辑。

智能体式分析能否发现业务逻辑漏洞？

业务逻辑漏洞之所以困难，是因为代码在技术上可能完全有效，而工作流却不安全。

一个用户反复使用同一张折扣券。一位经理批准了自己的交易。一个租户通过一个合法的端点访问了另一个租户的资源。这些情况不一定会表现出任何普遍意义上的危险函数。漏洞存在于角色、状态和预期行为之间的关系之中。

智能体式分析可以通过重建工作流、在相关操作之间比较控制措施，以及对状态转换和授权边界进行推理，来提升覆盖能力。

但“AI 驱动”本身并不构成证据。一个可信的检测结果应当展示受影响路径、被违反的假设、利用所需的条件，以及可能的影响。

Ostorlab 明确地将这种更深入的分析应用于复杂漏洞和逻辑缺陷，包括授权缺口、不安全的状态转换和工作流绕过。其价值不在于“智能体式”这个标签，而在于调查所产生的上下文。

一个可操作的检测结果应当包含什么

开发人员不应当在能够开始修复问题之前，先把扫描器的整个调查过程重做一遍。

一个可操作的检测结果应当包括：

• 受影响的代码仓库、修订版本、文件和代码位置；
• 对漏洞的清晰描述；
• 相关的数据流或控制流路径；
• 攻击者可控的输入或被破坏的信任边界；
• 缺失、被绕过或失效的安全控制措施；
• 现实的前置条件和影响；
• 说明为何认为该检测结果可被利用的证据；
• 针对该应用的具体修复指导；
• 在能够生成安全修复时，一个建议的代码改动。

仅有严重程度并不是解释。一个没有可信路径的“严重”标签，只不过是把调查工作又推回给了开发人员。

Ostorlab 围绕受影响路径、可利用性、影响、严重程度和修复优先级来组织检测结果。修复可以被发送回拉取请求，让开发人员在引入风险的代码旁边审查所建议的改动。

将源代码安全融入开发者工作流

当安全反馈在代码早已合并并被遗忘许久之后才到来时，它就失去了价值。

一个务实的工作流会结合：

• 变更级扫描，对当前正在审查的代码提供快速反馈。
• 完整代码仓库扫描，用于建立基线覆盖和处理遗留应用。
• 发布检查，针对即将交付的确切代码修订版本。
• 定期重新评估，随着代码库和威胁知识的变化而进行。
• 集中可见性，让应用安全团队能够跟踪风险，而无需让开发人员为每项任务都离开其日常工作流。

Ostorlab 当前的源代码工作流支持 GitHub、GitLab、Bitbucket、Azure DevOps、标准 Git 代码仓库以及 ZIP 上传。团队可以选择一个分支、标签或提交进行分析，审查有漏洞的路径和相关证据，并将修复发送回拉取请求。

目标很简单：让检测结果、代码和修复处于同一场对话之中。

如何评估一款源代码安全工具

一长串功能清单并不能告诉您使用一款扫描器会是什么感受。请针对有代表性的代码对它进行测试，并同时衡量它所制造的工作量以及它所发现的漏洞。

请追问：

检测结果是否值得信任？

• 每个检测结果是否都展示了可信的路径和支撑性上下文？
• 严重程度是否反映了实际的可达性和影响？
• 有多少被报告的问题能够经受住专家审查？

它是否理解您的代码库？

• 它是否支持您的语言、框架、代码仓库和构建系统？
• 它能否追踪自定义的库和安全控制措施？
• 它的推理能否超越孤立的语法模式？

在第一个信号之后会发生什么？

• 该工具是验证假设，还是仅仅给它打个分？
• 它能否识别净化器、授权控制措施和不可达路径？
• 它是否会在不成立的检测结果到达开发人员之前就将其丢弃？

修复是否有用？

• 指导是否触及了根本原因？
• 所建议的修复是否针对该应用和框架？
• 开发人员能否在接受改动之前先行检查它？

它是否契合开发工作流？

• 团队能否扫描正在审查的那个确切的分支、标签或提交？
• 检测结果和修复是否出现在开发人员已经工作的地方？
• 反馈是否足够快，足以影响发布？

在进行概念验证时，请纳入已知漏洞、以往修复过的真实问题、自定义控制措施，以及经常让通用扫描器困惑的代码。请跟踪已确认的检测结果、漏掉的漏洞、分级处理时间、修复时间，以及开发人员对所建议修复的接受程度。

更多的告警数量并不能证明更好的覆盖。它可能只意味着该工具把更多的不确定性转移给了您的团队。

AI 生成软件时代的源代码安全

AI 编码工具正在提升软件变更的数量和速度。安全团队无法以同样加快的速度生成告警来应对。

如果代码生成实现了规模化，而每一个安全假设仍然需要人工分级处理，那么瓶颈就只是转移到了应用安全和工程团队身上。

因此，源代码安全必须变得更具调查性。它需要理解代码仓库上下文、验证真正重要的内容，并把修复带到开发人员可以安全审查它的那个节点。

有意义的问题不再是：

这款扫描器有多少条规则？

而是：

在要求人类采取行动之前，它消除了多少不确定性？

这正是 Ostorlab Source Code 所围绕构建的标准：跟踪信号、理解路径、在答案不明确时持续深挖，并带着采取行动所需的上下文和修复一起返回风险。

探索 Ostorlab Source Code