# 1. Bandit（Python）、Brakeman（Ruby）、gosec（Go）的多语言 SAST A 三者都是适用于所有语言的通用工具 B 它们分别针对 Python、Ruby、Go 生态，能深入框架语义给出精准检测 ✓ 正确答案 C gosec 用于检测 Python 代码 D 多语言仓库只需运行一个工具即可
# 2. CodeQL（GitHub）的语义查询语言（QL）与 GitHub Security Advisories 的协同 A CodeQL 基于正则匹配漏洞 B QL 是字节码语言 C CodeQL 将代码编译为数据库，用声明式 QL 查询做语义分析，并与 Security Advisories 联动 ✓ 正确答案 D CodeQL 只能检测单一语言
# 3. OWASP Top 10 的 SAST 检测覆盖中 A01（Broken Access Control）、A03（Injection）、A07（Identification） A 注入类最适合污点分析，访问控制与认证缺陷静态覆盖有限，需配合 DAST 与人工测试 ✓ 正确答案 B SAST 能完全覆盖所有 OWASP Top 10 问题 C SAST 无法检测任何注入 D 访问控制缺陷完全无法由 SAST 检测
# 4. SAST（Static Application Security Testing）的三大支柱中 taint analysis、control flow、data flow A 污点分析只针对跨站脚本 B 三大支柱彼此独立，互不依赖 C 控制流分析完全取代数据流分析 D 污点分析跟踪不可信输入是否传播到危险 sink，依赖控制流与数据流支撑 ✓ 正确答案
# 5. Semgrep 的自定义规则（YAML DSL）与社区规则的工程价值 A Semgrep 规则只能使用内置规则，无法自定义 B Semgrep 规则必须用 C 语言编写 C 用 YAML DSL 可自定义匹配模式，配合社区规则实现可定制、可维护的检查 ✓ 正确答案 D 社区规则无法裁剪
# 6. SonarQube 的污点分析（taint analysis）引擎与 OWASP/SANS 规则 A SonarQube 无法做污点分析 B 污点分析结果不能用于质量门禁 C SonarQube 只有代码风格规则 D SonarQube 污点分析检测 source 到 sink 的路径，规则按 OWASP/SANS 分类并可进入质量门禁 ✓ 正确答案
# 7. 污点分析的 source/sink 扩展中如何为自研框架定义污点源（用户输入、反序列化）与污点汇聚点（SQL、命令执行），提升 SAST 对业务代码的检出率？ A 为自研框架声明 source 与 sink 可让 SAST 识别框架输入到危险操作的完整路径 ✓ 正确答案 B 自研框架无需建模，通用 SAST 天然覆盖 C source 只指 HTTP 参数 D sink 无法自定义
# 8. SAST 的"基线"（baseline）中遗留代码的渐进修复 A 基线要求一次性修复所有历史问题 B 基线机制无法区分新旧代码 C 基线把存量问题记录为基线，只对新问题报警，支持渐进修复 ✓ 正确答案 D 设定基线后新问题也不报警
# 9. SAST 的"误报率"（false positive）治理中标记、抑制、例外 A 误报无需处理，忽略即可 B 抑制应永久生效无需清理 C 通过标记、抑制、例外机制治理，且抑制应可追溯、有原因、有时限 ✓ 正确答案 D 误报率与规则调优无关
# 10. SAST 的"门禁"（gate）中高危漏洞阻断合并 A 门禁应把一切问题都阻断合并 B 高危漏洞设为阻断条件，低危问题设为告警，并配合基线豁免避免误伤 ✓ 正确答案 C 门禁只用于发布环节 D 门禁结果无法自动阻断合并
# 11. Coverity（Synopsys）的跨过程（interprocedural）路径敏感分析，及其在 C/C++ 空指针、资源泄漏检测上的定位 A Coverity 沿调用链进行路径敏感分析，擅长 C/C++ 空指针与资源泄漏检测 ✓ 正确答案 B Coverity 只做单函数匹配 C Coverity 无法分析指针问题 D Coverity 只适用于 JavaScript
# 12. SAST 工具按分析深度分层中模式匹配（Semgrep）→ 数据流（SpotBugs）→ 跨过程符号执行（Coverity/CodeQL）的精度与成本权衡 A 模式匹配→数据流→跨过程符号执行，精度与成本逐步上升 ✓ 正确答案 B 分析越深，成本越低 C 所有层次精度相同 D 深度分析比模式匹配更快
# 13. 多工具编排（orchestration）中 ESLint 本地即时反馈、Semgrep PR 门禁、Coverity 夜间深度扫描的分层职责划分 A ESLint 即时反馈、Semgrep PR 门禁、Coverity 夜间深度扫描，成本与时效分层匹配 ✓ 正确答案 B 所有工具都应在 PR 阶段运行最深的扫描 C 工具越多功能越冗余，应只用一种 D 本地无需使用任何 lint 工具
# 14. SonarQube 与 SpotBugs 在 Java 项目的互补中源码级规则 + 字节码级缺陷检测的叠加价值 A SonarQube 分析源码结构与规范，SpotBugs 分析字节码发现隐藏运行时缺陷，互补叠加 ✓ 正确答案 B 两者分析对象完全相同，无需叠加 C SpotBugs 只能分析源码 D SonarQube 无法集成 SpotBugs
# 15. 将多工具结果聚合到统一格式（SARIF），以便在代码托管平台安全面板单点呈现与去重 A SARIF 是各工具私有格式，无法互通 B SARIF 是开放交换标准，可聚合多工具结果到统一面板并去重 ✓ 正确答案 C SARIF 只能由单一工具产生 D SARIF 与 JSON 无关
# 16. Coverity 的"缺陷密度"（defect density）基线建立与行业对比的使用方式 A 行业对比可直接作为绝对质量标准 B 缺陷密度与代码规模无关 C 缺陷密度 = 缺陷数 / 代码规模，可建立基线并与行业对比 ✓ 正确答案 D 缺陷密度只需计算一次，无需跟踪
# 17. 商业 SAST（Coverity、Checkmarx）与开源（Semgrep、SpotBugs）在规则可定制性、误报支持、成本上的取舍 A 商业工具总是优于开源工具 B 开源工具无法检测任何漏洞 C 商业工具深度分析与支持好但成本高，开源工具可定制且免费但需自行维护 ✓ 正确答案 D 商业工具无法定制规则
# 18. SAST 漏洞的修复闭环中从工单、修复、复扫到豁免的流程如何管理，如何防止同一漏洞在不同模块反复出现？ A 修复完单点即可，无需管理流程 B 豁免应永久有效 C 闭环含工单、修复、复扫、豁免，并通过规则沉淀与根因治理防止复发 ✓ 正确答案 D 复扫无必要
# 19. ESLint 类型感知规则（type-aware，需 parserOptions.project）相较纯语法规则的增量价值与耗时代价 A 类型感知规则只做语法匹配 B 类型感知规则无需任何配置 C 类型感知规则基于跨文件类型信息发现语义问题，但需加载 tsconfig，耗时代价高 ✓ 正确答案 D 类型感知规则比纯语法规则更快
# 20. 工具链版本升级导致规则集变化、历史扫描结果不可比的治理（锁定版本、变更记录） A 升级后新旧结果必然可比 B 升级无需评估规则影响 C 应锁定版本、记录变更、灰度启用，保证结果可比且升级可控 ✓ 正确答案 D 新规则升级后应直接全量阻断
# 21. SAST 增量扫描（仅扫描 diff）与全量扫描在结果一致性上的差异与互补 A 增量扫描结果与全量完全一致 B 全量扫描只能在 PR 阶段运行 C 增量扫描快但可能漏掉跨文件影响，全量扫描完整但耗时，二者互补使用 ✓ 正确答案 D 增量扫描覆盖整个代码库
# 22. 多语言单仓库下用一条 pipeline 驱动多工具的 SAST 编排组织 A 按语言分派不同工具，统一 SARIF 输出并在单一面板聚合、去重 ✓ 正确答案 B 一个工具即可覆盖所有语言，无需编排 C 多语言仓库无法使用 SAST D 同一条 pipeline 只能运行一个工具
