成熟度模型中的建筑安全 15 15

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。