跑一个 代码质量检查 对代码库进行分析，即可获得有关复杂性、重复代码、无用代码和命名规范的报告。运行以下命令： code security 查 在同一个代码库上，你会得到一份关于……的报告 SQL注入 , 跨站点脚本和 身份验证缺陷相同的文件。两份报告。通常是两种不同的工具，两种不同的 dashboard以及两支很少交流意见的队伍。
这种分离在软件开发中非常普遍，以至于大多数团队都习以为常了。这也是为什么同一个函数中存在的可维护性问题和安全问题会被当作两个互不相关的工单来处理，而不是合并为一个工单的原因。
以下是每项检查的实际作用、它们的重叠之处以及“双工具”模型失效的地方。
什么是代码质量检查？
代码质量检查是一种静态分析，它衡量代码库的可维护性、可读性和结构健全性，而与代码库是否易受攻击无关。它不问“攻击者能否破坏这段代码？”，而是问“六个月后，开发人员能否安全地修改这段代码？”
代码质量检查通常会评估：
- 代码异味随着时间的推移，使代码更难更改的结构模式。
- 环路复杂性和认知复杂性：已经发展到任何人都无法安全修改的程度的函数和类
- 可维护性继续处理给定文件或模块的总成本
- 死代码：无法访问或未使用的代码，需永久付费。
- 复制：复制粘贴造成的债务，一个需要修复的问题实际上只在三个地方解决了。
- 命名约定违规行为会增加未来每位读者的成本
代码质量检查的输出通常是一个分数、一条趋势线和一长串按固定规则严重性排序的发现列表，而不是按实际影响排序。
什么是 Code Security 查看？
A code security 检查，更正式地说 静态应用程序安全测试（SAST)它会在应用程序运行之前扫描源代码，查找可利用的漏洞。它会寻找特定的模式，这些模式能让攻击者执行应用程序原本不应该允许的操作。
A code security 检查通常会发现：
- 注塑缺陷SQL注入、命令注入、代码注入
- 跨站脚本（XSS） 未经处理的输入，允许攻击者在其他用户的会话中运行脚本。
- 配置错误和信息泄露：无意中暴露数据的设置和代码路径
- 缓冲区溢出可能损害应用程序完整性的内存处理问题
- 身份验证和授权漏洞访问控制薄弱或缺失
来自的发现 code security 检查工具应包含 CWE 分类、严重性评级，以及（在成熟的工具中）可利用性证据，这正是区分严重漏洞的关键所在。 SAST 一个工具，它只是进行模式匹配并寄希望于运气。
代码质量检查与 Code Security 检查：主要区别
| 代码质量检查 | Code Security 查看 （SAST) | |
|---|---|---|
| 核心问题 | 这样可以安全地维持下去吗？ | 这可以被利用吗？ |
| 它测量什么 | 复杂性、重复代码、无用代码、命名、可维护性 | 注入攻击、跨站脚本攻击、配置错误、身份验证缺陷、内存问题 |
| Standard 参考 | 内部质量模型，无通用认证 standard | CWE（通用弱点枚举），已通过 OWASP 等基准测试验证 |
| 典型业主 | 工程/工程副总裁 | 应用安全/DevSecOps |
| 忽视它的后果 | 变革成本上升、用户迁移速度变慢、版本发布不稳定 | 数据泄露、合规性失效、生产系统被利用 |
| 运行位置 | CI，本地 CLI | CI、本地 CLI 以及（在更高级的工具中）IDE |
它们并非相互冲突的检查。它们针对的是同一行代码，回答的是两个不同的问题，而这正是单独运行它们会导致问题的原因。
为什么大多数代码分析工具将它们分开
大多数组织已经运行这两种检查。他们只是在两个不同的产品、两个不同的控制台、两个不同的待办事项列表和两种不同的优先级模型中，对相同的存储库运行这两种检查。
这种分裂会引发三个可预见的问题：
- 没有人同时看到这两个积压案件。 一个存在严重安全问题且可维护性评分处于危险区域的函数，在两个不相关的工具中显示为两个不相关的工单，而实际上它只是一段需要双倍紧急关注的代码。
- 问题堆积如山，根本来不及解决。 市面上所有的代码分析工具都能很好地识别问题。真正的瓶颈从来不在于发现问题，而在于对任何实际代码库进行质量扫描或安全扫描都会发现远超团队处理时间的缺陷数量，而简单的严重性标签无法告诉你应该优先修复哪十个问题。
- 统一的规则严厉程度并非首要考虑因素。 从规则引擎的角度来看“关键”和“因为实际可访问且可利用而认为关键”是不同的论断。大多数代码分析工具只能得出前者。
更佳方案：统一平台、统一人工智能、统一优先级模型
Xygeni 运行代码质量和 code security 在同一扫描器、同一控制台和同一优先级模型中进行分析，因此同一文件中的可维护性问题和安全漏洞可以同时显示，而不是存在于两个不相关的系统中。
- 测量。 Xygeni 的 code security 查看 （SASTXygeni 的代码质量检查工具会对注入漏洞、跨站脚本攻击 (XSS)、配置错误、缓冲区溢出和身份验证漏洞进行扫描，每项发现都会被赋予一个 CWE 分类。Xygeni 的代码质量检查工具对 Java、JavaScript、Python、PHP、C#、Go、HTML、Swift、Kotlin 和 C/C++ 这十种语言采用相同的分析方法，在一个统一的框架下衡量代码的复杂性、可维护性、重复代码、死代码和命名规范。 standard因此，质量发现与安全发现具有相同的严重性、CWE（如适用）和文件行详细信息。
- 优先。 两种检查类型都输入到同一个 AI 分类漏斗中，该漏斗根据实际影响而不是扁平的规则严重性对结果进行排名，并且都参与到统一的“所有风险”视图中，因此安全主管和工程主管看到的是同一个风险图景，而不是两个单独的电子表格。
- 补救。 Xygeni 的功能不仅限于识别安全漏洞。AI 修复功能还提供可直接应用的修复方案，以解决安全问题，包括： pull request 创建规则，并对质量发现进行同样的处理，按修复复杂度和预计节省的工作量进行排序。代码分析工具应该回答的问题不是“你有多少条规则”，而是“当它发现一千个问题时，谁来修复它们？”
无论检测结果来自 Xygeni 自有的扫描器，还是来自已集成到平台中的第三方工具，此方法均适用。AI 分类和 AI 修复功能既适用于 Xygeni 自身的安全检测结果，也适用于从 Snyk、Veracode 或 Checkmarx 等工具提取的安全检测结果，因此切换到统一检查并不意味着需要先移除任何现有功能。
代码分析工具应该关注哪些方面
如果您正在评估代码分析工具，无论是用于代码质量检查，还是其他用途， code security 检查一下，或者两者都做，几个问题就能快速识破大多数供应商的推销话术：
- 它是根据实际影响对调查结果进行排名，还是仅仅根据固定的规则严重程度进行排名？ 严重程度标签并不等同于优先级排序。
- 它是否通过独立基准测试验证其检测准确性？ SAST 声称准确性很容易，但很难证明；已发表的 OWASP 基准测试结果披露真阳性率和假阳性率，就能区分主张和证据。
- 规则是否透明？ 在运行扫描之前，您可以浏览探测器目录，了解该工具在运行扫描之前会检查哪些项目。 commit 到它。
- 它只是指出问题所在，还是会提出解决方案？ 如果发现问题但没有补救措施，那只会让问题积压得更久，而不是解决问题。
- 它是否适用于您的整个技术栈，包括您已运行的工具的发现结果？ 第一天就整合供应商比整合信息来源更重要。
- 它是否与现有工作流程相衔接？ CI/CD pull request 检查，以及安全发现，在编写代码时提供 IDE 反馈，而不仅仅是在合并代码之后。
简短版
代码质量检查会询问您的代码是否可以安全维护。 code security 检查会询问代码是否存在可被利用的漏洞。这两个问题都很重要，都会得出需要采取行动的结论，但如果使用两个互不关联的工具来运行它们，同一段代码就会看起来像是两个独立的问题，而不是一个优先级排序的问题列表。
西吉尼 在一个扫描器中运行这两项检查，在一个流程中按实际影响对两项检查进行排名，并使用以下方法修复这两项检查： pull requests 而不是让你积压更多的工作。
想看看你自己的 code security 对研究结果进行优先级排序，而不是仅仅列出？ 立即加入 Xygeni 的开发者计划，开始免费扫描。
想知道在您的产品组合中实现统一的质量和安全视图是什么样的吗？ 预约演示 Xygeni 代码质量 Code Security.
常见问题解答
代码质量检查与……相同吗？ code security 校验？
不。代码质量检查衡量的是可维护性、复杂性、重复性和命名规范。 code security 查看 （SAST）衡量可利用性：注入漏洞、跨站脚本攻击 (XSS)、配置错误和身份验证弱点。它们分析相同的代码，但回答不同的问题，并且发现的问题可以被标记为质量问题、安全问题，或同时被标记为两者。
什么是 SAST它与……有何关系？ code security 校验？
SAST 代表静态应用程序安全测试。它是大多数人所说的“静态应用程序安全测试”的技术名称。code security 检查”：在应用程序运行之前（无需执行）扫描源代码是否存在漏洞。 code security 本帖中的签到指的是 SAST 具体来说，它与 DAST 不同，DAST 是从外部测试正在运行的应用程序。
一个工具能否同时运行代码质量检查和 code security 校验？
是的。Xygeni 运行代码质量和 code security 由于分析在同一扫描器和控制台中进行，两种检查类型共享一个优先级模型，而不是分别位于两个独立的工具中，各自拥有独立的待办事项列表。每种检查结果仍然保留各自的分类（安全检查采用 CWE 指标，质量检查采用复杂性/可维护性指标）。
应该多久运行一次代码质量检查或 code security 校验？
两者都应该持续进行，而不是作为一次性审计。 standard 模式是对每个扫描 pull request 在 CI 中，与 guardrails 该门槛是针对新引入的问题，而不是针对全部继承的积压问题，因此团队的评判标准是他们增加了什么，而不是多年积累的债务。
