从要做的决策出发
“我们需要做一次安全检查”是个不错的起点，但作为测试范围还不完整。您是要上线新的权限模型、接手一套现有代码，还是要回应客户的安全评估要求？不同情况对应不同的问题。在选择服务之前，先把这个问题写下来。
对于一个新的授权模块，您可能需要了解代码是否始终如一地执行了产品规则。对于一个正在运行的应用，您可能需要证明一个权限受限的用户实际上能访问到什么。这些目标可以对应相互补充的工作。
什么时候应从源代码入手
安全代码审计检查的是实现及其上下文：信任边界、数据流、权限以及对不可信输入的处理。当问题聚焦于某个特定模块、某次变更或疑似的根本原因时，它最有用。所需的访问权限可能包括相关代码、构建说明和测试。
有价值的结果会指出受影响的位置、解释缺陷成因，并为开发人员提供切实可行的修复和验证方法。自动化 SAST 可以辅助调查，但它的告警仍需要解读和验证。请确认会审计哪些模块，以及结论将如何得到证据支撑。
什么时候应优先关注运行时行为
应用渗透测试通过约定的接口和攻击路径来考察产品。账户、角色、环境和运行限制决定了可以测试哪些内容。它适合用来检查某个对外暴露的流程是否允许非预期的操作，并了解其可观察到的影响。
报告应说明测试范围、经确认的发现、复现步骤和修复优先级。如果能提供源代码，评估质量会更高；渗透测试并不一定只能完全以黑盒方式进行。请在方案中确认所采用的方法。
围绕一个重要问题组合多种方法
对于一次敏感的 API 变更，可以先审计相关的访问控制代码，再用约定的角色实际验证其行为。对于一个原生解析器，可以审查输入和大小的处理，并在可行时考虑定向动态测试或模糊测试。方法应当服务于测试对象和目标。
预算有限时，选择一个范围明确的组件或流程，并保持足够的深度。以书面形式约定交付物、排除项以及任何修复验证。只要简要介绍您的产品、技术栈和审查原因，我就可以帮您确定这样的范围。
参考来源
需要在您自己的产品中检查这个问题吗？
应用渗透测试想学会自己发现这类漏洞吗？
Web 应用渗透测试课程（一对一）