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

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。