SAST/DAST/IAST 基础

• SAST 静态分析原理与盲区
• DAST 动态黑盒原理与盲区
• IAST 交互式代理原理与盲区

SAST（静态应用安全测试）在源码层面分析，不运行程序，通过数据流、污点传播与控制流分析发现漏洞，如 SQL 注入、XSS、硬编码密钥；优势是覆盖全、可定位代码行、左移，缺点是误报高、难发现运行时与环境类问题、对复杂业务逻辑判断弱。DAST（动态应用安全测试）运行系统从外部黑盒发起请求，模拟真实攻击，能发现运行时配置、认证、会话等真实可达漏洞，误报低；缺点是需运行环境、覆盖依赖功能可达性、扫描慢、无法覆盖未部署或深层代码。IAST（交互式应用安全测试）在运行时部署 Agent 并实时分析请求与代码执行，兼顾 SAST 的代码定位与 DAST 的真实性，误报低、覆盖广；缺点是需资测环境、Agent 有性能开销、平台依赖。三者的盲区互补：SAST 补逻辑与源码、DAST 补运行时与配置、IAST 补真实执行下的数据流，工程上常组合使用。

三种技术"静态/动态/交互"构成不同视角，无单一技术全覆盖。测试者应理解各自盲区，组合选型以覆盖源码、运行时与环境各层。

• 误报的分类与标记
• 抑制（Suppression）机制的正确使用
• 误报反馈闭环

SAST 误报管理是工程落地关键。首先要建立误报分类：将结果分为真实漏洞、误报（规则误判）、非可利用（理论存在但不可达）、待确认等，形成统一的判定标签。其次建立抑制机制：对确认的误报用平台规则（如 code comment、配置文件）进行抑制，并记录抑制原因与责任人，避免误抑制真实漏洞；抑制需可审计、可回溯。再次建立反馈闭环：将误报样本反馈给规则维护者，优化规则降低误报率，并定期清理历史抑制项。误报率过高会严重损害团队信任度——"狼来了"效应使开发忽略扫描结果，导致真实漏洞被放行，安全门禁形同虚设。治理策略包括：调优规则、分级展示（先高风险）、人工复核样本、用高效规则优先、结合 IAST 交叉验证，并通过降低误报率指标持续改进。

误报管理的核心是"信任度"。只有通过分类、抑制、反馈循环把误报压到可接受水平，扫描结论才能被团队采纳，安全门禁才有意义。

• CodeQL 查询编写与数据流分析
• Semgrep 模式匹配与自定义规则
• 业务特有漏洞模式的识别

面向业务特有漏洞需开发自定义规则。CodeQL 通过编写 QL 查询进行语义与数据流分析，可定义 source（污点源）、sink（敏感落点）与 taint 流，如检测"用户输入直达 SQL 执行"或"内部审计函数被绕过"；能力强大但需 QL 语言经验。Semgrep 用 YAML 定义模式规则，通过 AST 模式匹配定位代码模式，语法简单、上手快，适合快速覆盖固定模式（如使用不安全的 API、绕过校验的判断），并支持参数化与元数据。开发流程：先识别业务专有漏洞模式（如公司自研的加密函数被误用、特定遗留 API 的注入），编写规则原型，用正/负样本测试规则（确认能命中真实漏洞、不误报正常代码），评审后纳入规则库并维护。规则自身也需测试与定期复审，防止过时或误报。

自定义规则把"团队经验"固化为"自动检测"。CodeQL 强于数据流、Semgrep 强于快速模式，选型取决于场景，且规则需持续测试维护。

• 黑盒测试的适用场景与交付物
• 白盒测试的适用场景与交付物
• 灰盒测试的适用场景与交付物

渗透测试按信息掌握程度分三种：黑盒测试模拟外部攻击者，不提供任何内部信息，仅凭公开接口测试，最接近真实攻击视角，但耗时、覆盖有限，适用对外合规评估与真实威胁模拟；白盒测试提供完整源码、架构与配置，测试者可结合代码审计深入测试，覆盖全面、效率高，能发现深层逻辑与源码漏洞，适用关键系统上线前深度评估；灰盒测试介于两者之间，提供部分凭据或架构信息，模拟"有部分权限的内部白客"，兼顾真实性、效率与覆盖，适用大多数内部安全评估。交付物通常包括：测试报告（漏洞清单、复现步骤、风险定级、修复建议）、测试日志与证据、以及改进建议。选择取决于目标（合规、深度、真实感）与资源。

黑/白/灰盒是"信息量的梯度"，决定测试的深度、效率与真实度。测试者应据评估目标选择，并关注交付物中漏洞定级与修复建议的可用性。

• SBOM 的生成与格式
• 依赖清单与漏洞匹配
• 供应链漏洞扫描方法

软件供应链安全测试的核心是建立并扫描"软件物料清单"。SBOM 生成：通过工具（如 CycloneDX、SPDX 标准，或 Syft、Trivy、OWASP Dependency-Check）解析依赖树，生成包含组件、版本、许可证、传递依赖的清单，并在 CI/CD 中随构建自动生成，保证其与产物版本一致。漏洞扫描：将 SBOM 中的组件与版本比对 CVE 数据库（NVD、GitHub Advisory、OSV），识别存在已知漏洞的组件，结合传递依赖解析避免漏报；利用 SCA 工具的漏洞库与严重度评分定级。工程上把 SBOM 生成与漏洞扫描作为构建门禁，对高危漏洞阻断发布，并定期重新扫描以纳入新披露漏洞。同时验证 SBOM 完整性（签名、哈希）以支撑审计。

SBOM 是供应链安全的"食材清单"，漏洞扫描是"逐项核查"。测试者应确保 SBOM 自动生成、与版本一致、并与漏洞库联动形成门禁。

• DAST 在 CI/CD 的运行环境问题
• DAST 扫描时间长的优化
• 增量扫描与缓存

DAST 在 CI/CD 集成面临"运行环境"与"扫描耗时"两大难题。运行环境：DAST 需被测系统运行，应在测试/预发环境启动被测应用（容器化、临时部署），或用独立测试环境定时扫描，避免影响生产；也可在合并前用临时环境做快速扫描。扫描时长：采用增量扫描（只扫描变更相关的路径/接口，全量扫描定频执行）、扫描缓存（复用未变接口结果）、以及只扫描变更的 API 端点。API 感知扫描：对 REST/GraphQL 等，用 OWASP ZAP API scan 直接基于 OpenAPI 规范生成请求并扫描，无需大量爬虫，速度快、覆盖接口全，适合 CI 快速反馈；配合导入 API 定义、配置认证与并发控制。工程上把快速 DAST 作为 PR 门禁、全量 DAST 作为夜间/发布前扫描，形成分层。

DAST 集成的关键是"快"与"可运行"。用临时环境、增量扫描与 API 感知扫描解决耗时与覆盖，PR 门禁做快扫、定时做全量，兼顾反馈速度与覆盖深度。

• IAST Agent 的部署方式
• 测试环境中的部署要求
• 性能影响的评估

IAST Agent（如 Contrast Security）部署于被测应用运行时：对 Java 用 JVM 代理、.NET 用 CLR 代理、对容器/服务可通过环境变量或 sidecar 注入 Agent，随应用启动加载，监测请求处理过程中的数据流与漏洞。部署要求：需在测试环境（非生产）运行，且应用需有真实流量覆盖（自动化测试、回归测试）才能触发检测；Agent 需与平台（IAST 控制端）通信上传分析结果。性能影响评估：对比有无 Agent 的响应时间、吞吐量、CPU/内存占用，通常有轻微开销（毫秒级到低百分比），需在非关键路径验证。控制措施：仅对关键接口启用、设置采样率、调整 Agent 的检测线程与日志级别、选择低开销的检测模式，并监控资源占用，确保不影响测试结果可信度。

IAST 把检测"织进"运行时，需真实流量触发。部署与性能控制是落地关键，测试者应评估开销、控制影响，并确保测试流量覆盖充分。

• 数据流分析（前向/后向）
• 污点分析（source/sink）
• 污点传播与净化

SAST 的核心是静态分析，其中数据流分析追踪程序运行时数据在语句间的流动：前向数据流分析从变量赋值出发追踪其流向，后向分析从使用点回溯其来源，用于判断某个值是否被波及。污点分析（Taint Analysis）是数据流分析的特殊应用，用于检测注入类漏洞：定义 source（污点源，如用户请求参数、外部输入）与 sink（敏感落点，如 SQL 执行、命令执行、HTML 输出），分析污点是否从 source 传播到 sink 且未经过净化（sanitization）。若污点未经净化即到达 sink，则判定为潜在漏洞（如 SQL 注入）。分析会根据语言语义处理赋值、函数调用、条件分支与跨函数传播，并通过净化函数终止污点传播。局限在于：静态无法完全确定运行时行为，可能误报（有净化但分析不到）或漏报（动态构造的污点）。

污点分析是 SAST 识别注入类漏洞的核心机制。测试者理解 source/sink/净化模型，能正确解读扫描结果并评估其可信度。

• 假阴性（漏报）的风险与来源
• 单一工具的覆盖盲区
• 多层检测与纵深防御

假阴性（漏报）指存在漏洞却未被工具发现，其风险比误报更隐蔽，会导致真实漏洞被放行进入生产。来源包括：单一工具规则覆盖有限、语言/框架不支持、动态行为无法静态判断、复杂业务逻辑超出工具能力、以及工具配置不全。为弥补盲区，需采用多层检测（纵深防御）：一是工具互补，组合 SAST + DAST + IAST + SCA，用不同检测原理覆盖源码、运行时、依赖各层；二是规则互补，多工具交叉验证，同一漏洞被多个工具命中更可信；三是人工补位，对工具难覆盖的业务逻辑、设计缺陷用渗透测试与代码评审；四是环境补位，动态测试覆盖真实运行与配置。通过"多工具 + 多技术 + 人工 + 环境"的纵深防御，把单一工具漏报的盲区用其他层兜底，降低整体漏报风险。

假阴性是"看不见的敌人"。纵深防御的本质是"用多种独立检测层互相兜底"，降低对单一工具的依赖，测试者应构建多层检测体系并评估覆盖。

• 扫描器登录配置方式
• 录制脚本与认证插件
• 会话保持与失效处理

DAST 需登录才能覆盖受保护页面，配置方式多样：一是录制脚本，用浏览器代理录制登录流程（输入账号密码、提交），回放时让扫描器携带会话凭据访问；二是认证插件，如 ZAP 的 Authentication 插件、Burp 的宏（Macro）与凭据管理，通过配置登录路径、表单字段与凭据实现自动登录；三是手动设置会话 Cookie/Token，将有效会话注入扫描器。会话管理上，需配置会话保持（定期刷新 Cookie/Token）与失效处理（检测会话过期后重新登录），避免扫描中途因会话失效而漏扫。配置后应验证扫描器确实以登录态访问受保护页面，覆盖登录后功能，并防止凭据泄露在报告中。关键在确保"登录态真实有效"且"会话生命周期受控"。

登录态配置决定 DAST 能否覆盖受保护功能。测试者需用录制/插件/手动注入等方式建立会话，并管理会话生命周期，避免漏扫与凭据泄露。

• SCA 与 SAST 的职责分工
• 开源依赖漏洞治理
• 自研代码漏洞治理

SCA 与 SAST 职责不同：SCA 聚焦开源组件与依赖，通过比对组件版本与 CVE 漏洞库识别已知漏洞、许可证风险与组件更新，治理对象是"第三方依赖"；SAST 聚焦自研代码，通过静态分析发现自研代码中的逻辑与实现漏洞（注入、XSS、越权等），治理对象是"自有代码"。二者互补：SCA 解决"用了什么、是否含已知漏洞"，SAST 解决"自己写的代码是否有缺陷"。治理上，开源依赖漏洞用 SCA 扫描 + 版本升级/补丁 + SBOM 管理，并评估传递依赖；自研代码漏洞用 SAST 扫描 + 人工评审 + 修复验证，并持续优化规则。两者结果合并成统一漏洞清单，按风险定级排期，避免重复与遗漏。职责边界清晰，才能分别治理、协同闭环。

分清"第三方依赖"与"自有代码"两类漏洞来源，是有效治理的前提。SCA 管依赖、SAST 管自研，二者合并统一管理，覆盖完整。

• 多工具结果的归一化
• 按弱点类型去重合并
• 结果排序与优先级

多工具（SAST/DAST/SCA）结果需合并成单一可信漏洞清单，避免重复与混乱。流程：一是归一化，将各工具的输出统一为规范字段（漏洞类型、CWE、位置、严重度、证据、工具、时间），便于比较；二是去重，同一漏洞被多工具命中时，按 CWE/位置/接口匹配合并为一条，保留完整证据与最高可信度，避免重复计数；三是合并，将不同工具发现的互补漏洞汇入同一清单，并补充工具来源与交叉验证信息；四是排序，结合严重度（CVSS）、可利用性、暴露面、业务影响综合排序，确定修复优先级。最终形成"单一可信漏洞清单"，作为修复与门禁的依据，并跟踪状态直至闭环。去重与合并的关键是"匹配口径统一"，避免误合并或漏合并。

多工具结果治理的核心是"归一化—去重—合并—排序"。测试者应统一口径、交叉验证，输出可信、可排序、可跟踪的单一漏洞清单。

• 主动扫描的机制与风险
• 被动扫描的机制与局限
• 二者的适用场景

DAST 主动扫描主动构造并发送恶意请求（注入 payload、篡改参数）探测漏洞，能主动发现漏洞，覆盖被测系统暴露的所有可达接口；但风险高，可能触发破坏性操作（删除、写入、DOS）、影响业务数据或生产环境，且扫描时间长、需谨慎配置。被动扫描只被动观察正常的请求/响应流量，不主动发送恶意请求，通过分析流量中的风险信号（如敏感信息泄露、异常响应、缺失安全头）发现隐患，风险极低、无破坏性，适合生产或对实时流量做持续监控；但局限是只能发现"正常流量中暴露"的问题，无法主动验证未触发的漏洞。适用场景：主动扫描用于测试环境上线前深度评估，被动扫描用于生产监控与持续风险评估。工程上常组合：测试环境主动扫描、生产被动监控，兼顾深度与安全。

主动"进攻"与被动"观察"是两种策略，风险与覆盖不同。测试者应根据环境（测试/生产）与目标选择，主动扫描放测试环境、被动监控放生产。

• 安全测试工具的 CI 集成
• 安全门禁的阶段与策略
• 门禁的阻断与告警

DevSecOps 将安全测试集成到 CI/CD 各阶段并设门禁：提交阶段用 pre-commit 钩子做密钥检测与增量 SAST；构建阶段生成 SBOM、做 SCA 依赖扫描与产物签名；测试阶段运行 SAST/DAST/IAST 并对结果设门禁；发布阶段做全量安全扫描与人工审批，并保留产物溯源。安全门禁设计：按严重度分级阻断——高危漏洞阻断发布（fail），中危告警或限期修复，低危记录；门禁需可配置（按环境/风险调整），并有旁路（override）机制但需审批留痕。关键设计原则：门禁要"不可轻易绕过"（如强制扫描、阻断逻辑在平台层而非脚本层）、结果可审计、阈值可演进。门禁把安全要求固化为"强制动作"，使每次发布都经过安全校验。

安全门禁是 DevSecOps 的"强制闸门"，把安全左移并制度化。设计要点是分级阻断、可配置旁路、防绕过与可审计，确保安全校验真实生效。

• pre-commit 层密钥拦截
• CI 层密钥扫描
• 仓库历史扫描

密钥检测（Secret Detection）在三个层面防泄露：pre-commit 层，用 GitLeaks/TruffleHog 的 pre-commit 钩子在提交前拦截含密钥的变更，阻止密钥进入仓库，是第一道防线；CI 层，在 CI 中运行密钥扫描，扫描 PR 的变更内容，对新增密钥阻断合并，作为第二道防线（兜底 pre-commit 的遗漏）；仓库历史扫描，用 TruffleHog/GitLeaks 扫描整个仓库历史，找出历史上已提交的密钥（含已删除提交中的密钥），作为第三道防线发现问题。GitHub Secret Scanning 提供平台级扫描，自动检测仓库中的密钥并通知所有者。处置流程：发现已泄露密钥后，立即轮换/吊销密钥、清理历史、评估泄露影响。三层防线+平台检测构成"防新增、扫历史、快处置"的完整机制。

密钥泄露危害大且难以察觉，三层防线与平台扫描缺一不可。测试者应推动 pre-commit 拦截、CI 阻断、历史清理与轮换处置的闭环。

• 大型代码库扫描的性能瓶颈
• 增量扫描（只扫变更代码）
• 并行扫描与分布式

大型代码库上 SAST 全量扫描耗时长、资源占用高，需优化：一是增量扫描，只对变更的文件/模块及其依赖分析（基于调用图或文件变更），避免每次全量重扫，是降低成本最有效手段；二是并行扫描，将代码库按模块/目录切分，多节点/多进程并行扫描再合并结果，缩短总耗时；三是结果缓存，缓存未变更文件的扫描结果，仅对变更部分重新分析，大幅减少重复计算；四是基于调用图的影响分析，只扫描变更波及的代码。同时限制每文件分析深度、按规则分级扫描（先高危规则）。工程上结合增量+并行+缓存，把全量扫描设为低频率（夜间/发布前），增量扫描设为高频率（PR 门禁），平衡成本与覆盖。

扫描成本是大型代码库落地 SAST 的障碍。增量、并行、缓存、分级扫描多管齐下，快扫高频、全量低频，兼顾反馈速度与覆盖深度。

• IAST 的检测原理与定位
• RASP 的检测原理与定位
• 部署方式差异

IAST（交互式应用安全测试）是"测试"技术，在运行时通过 Agent 监测请求处理中的数据流，发现漏洞并定位到代码，处于测试环境，用于"发现漏洞"；RASP（运行时应用自保护）是"防护"技术，在运行时拦截并阻断攻击请求，需部署在生产环境，用于"阻止攻击"。原理上，IAST 侧重"分析"（监测数据流、标记漏洞），RASP 侧重"防御"（识别攻击模式、阻断恶意请求）；部署上，IAST 部署于测试/预发环境并依赖被测流量，RASP 部署于生产环境实时拦截。二者互补：IAST 在开发测试期发现漏洞，RASP 在生产期兜底阻断，形成"测试发现 + 运行防护"的纵深。注意 RASP 不替代补丁修复，只是临时缓解。

一句话区分：IAST 找漏洞（测试期），RASP 挡攻击（生产期）。理解二者"检测与防护"的定位差异，合理部署才能发挥各自价值。

• CVSS 评分的含义与局限
• 可利用性评估
• 业务影响评估

安全扫描结果排序需综合多维度，不能只看 CVSS：CVSS 评分提供基准严重度（0-10），反映漏洞本质特征，但它是通用打分，未考虑组织的具体环境；可利用性反映漏洞能否被实际利用，需结合是否已有公开 exploit、是否需认证、攻击复杂度、是否在攻击面（暴露的公网接口）等；业务影响反映漏洞对组织资产、数据与业务可用性的损失，需结合资产价值、数据敏感度、合规要求。组合排序时，将三者加权：高 CVSS + 高可利用性 + 高业务影响 => 最高优先级立即修复；反之则降低。修复排期按优先级分档（严重立即、高危限期、中危计划、低危记录），并考虑修复成本与资源。同时跟踪修复后复测验证，形成闭环。

排序的本质是"把漏洞放到业务语境中评估"。CVSS 是起点，结合可利用性与业务影响才能定出真实优先级，避免机械按 CVSS 排期。

• 自定义规则的评审流程
• 规则自身的测试（正/负样本）
• 误报回退机制

SAST 规则库需持续维护，防止"腐化"（规则过时、误报膨胀、覆盖失效）。一是规则评审：新规则需经评审，确认命中率、误报率与业务适配性，避免低质量规则污染库；二是规则测试：用正样本（确认存在的漏洞）与负样本（正常代码）验证规则，确保能命中真实漏洞且不误报，并建立回归测试集，规则变更时自动回归；三是误报回退机制：当规则在真实项目误报过多时，能定位、修正或回退该规则，并记录误报反馈，形成"识别—修正—回退—验证"闭环；四是定期复审：定期评估规则的命中率、误报率、覆盖率，清理过期/低效规则，并随语言框架与漏洞趋势更新。通过评审、测试、回退与复审，规则库保持"准确、新鲜、可维护"。

规则库是 SAST 的"大脑"，需像代码一样被测试、评审与维护。关键在建立规则自身的测试与回退机制，用数据驱动规则改进，防止腐化。