应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载导读本指南围绕examples/azure-pipelines/中的完整示例讲解如何将 OpenAI Codex Security CLIopenai/codex-security接入 Azure DevOps Services通过一份集中托管的 Azure Pipelines YAML 对指定的 Azure Repos Git 仓库执行全量基线扫描与提交级差异扫描。方案使用 AWS OIDC 换取短期凭证调用 Amazon Bedrock 模型推理产出result.json、report.md、coverage.json、findings.json与results.sarif等报告工件并可选将 SARIF 发布到目标仓库的 GitHub Advanced Security 原生视图。读完本文你将掌握该示例的完整部署步骤、YAML 管线结构、每个运行参数的语义、退出码与产物处理策略以及这套集中式方案的信任边界与安全注意事项。方案概览与适用边界该示例的核心设计是集中式工具仓库 被动目标仓库管线定义存放在受信任的工具tooling仓库中目标仓库本身不需要携带任何管线文件也不发生任何 Codex Security 运行时改动或自定义扩展安装。一次扫描的完整链路如下Azure Pipelines 从工具仓库检出 YAML按参数解析出目标仓库引用与扫描模式在 Microsoft 托管的 Linux 代理ubuntu-24.04上通过 AWS Toolkit 的 OIDC 服务连接换取 1 小时的短期 AWS 凭证Codex Security CLI 以amazon-bedrock为推理提供方对目标仓库目录执行scan产出结构化 JSON 结果若扫描成功或仅因严重性策略失败export命令将结果导出为 SARIF可选地由AdvancedSecurity-Publish1任务把 SARIF 发布到目标仓库的 Advanced Security 视图最终由PublishPipelineArtifact1保留选中的报告工件。需要明确该示例的适用边界它面向Azure DevOps Services 与 Microsoft 托管 Linux 代理不自动注册仓库、不创建分支策略、也不自动校验 PR。若希望成为 Azure Repos 的 PR 门禁需要自行设计目标分支的 build validation 策略与 PR 感知的检出逻辑——详见后文信任与推广边界一节的讨论。一、部署前的准备工作原文档给出了 5 步设置流程这里结合 YAML 与仓库源码逐条展开。第 1 步复制管线文件并固定目标仓库将examples/azure-pipelines/azure-pipelines.yml复制进工具仓库并把resources.repositories.target.name修改为已获批准的项目/仓库名称例如ExampleProject/example-app同时调整默认的targetRef。安全要点在于仓库名应当固定在被评审过的 YAML 中而不是在排队时接受任意扫描目标否则任何能触发管线的人都能把扫描指向任意仓库。第 2 步配置 AWS Toolkit 与 OIDC 服务连接在组织内安装 AWS Toolkit for Azure DevOps 扩展并创建名为codex-security-bedrock的 AWS 服务连接认证方式选择Use OIDC填写 AWS 角色 ARN不要设置访问密钥按 AWS 的 OIDC 联邦接入指南完成 Azure DevOps 到 AWS 的联邦配置将角色的信任策略严格限定为该服务连接实际的 issuer、audience 与 subject并且只授权这条管线使用该连接。示例 YAML 中通过变量awsServiceConnection: codex-security-bedrock引用该连接扫描任务AWSShellScript1的awsCredentials输入即取自此变量。第 3 步选定 Bedrock 模型并约束角色权限设置awsRegion与bedrockModelId为可用的、已获批准的 Bedrock 模型或推理配置inference profile。角色仅需具备针对这些资源的最小 Bedrock 调用权限。注意 YAML 中设置了aws.rolecredential.maxduration: 3600即请求的 AWS 会话时长为1 小时与任务timeoutInMinutes: 60相匹配——角色的MaxSessionDuration必须允许该时长否则换取凭证会失败。第 4 步创建管线并授权跨项目检出创建指向该 YAML 的管线后授予管线所在项目的构建服务身份build service identity对目标仓库的读取权限在目标项目中对target仓库资源执行显式授权跨项目检出需要在目标项目中单独授权不要通过关闭 project-scoped job authorization 来绕过缺失的授权——这会引入不必要的权限放大。第 5 步SARIF 发布的开关策略默认保持publishToAdvancedSecurity: false仅做纯工件运行。要启用原生 findings 视图需先在目标仓库上启用所需的 GitHub Code Security / Advanced Security 许可并授予管线身份发布结果的权限之后在排队运行时再显式开启该开关。YAML 还固定了 CLI、Node 与 Python 的版本并采用当前的任务主版本号UseNode1、UsePythonVersion0、Bash3、AWSShellScript1、AdvancedSecurity-Publish1、PublishPipelineArtifact1。Azure Pipelines 会在这些主版本内解析兼容的任务更新因此在采用或升级示例时应复核固定的版本号。当前示例固定的版本为CLI0.1.27、Node24.21.0、Python3.14.7对应codexSecurityVersion、UseNode1的version与UsePythonVersion0的versionSpec。二、YAML 管线逐段解析完整文件位于examples/azure-pipelines/azure-pipelines.yml仓库测试sdk/typescript/tests-ts/azure-pipelines-example.test.ts对它的结构做了逐项断言可作为期望行为的权威参照。2.1 触发器与运行时参数trigger: none parameters: - name: targetRef type: string default: refs/heads/main - name: scanMode type: string default: full values: [full, diff] - name: baseRevision type: string default: HEAD^ - name: failOnSeverity type: string default: none values: [none, low, medium, high, critical] - name: publishToAdvancedSecurity type: boolean default: falsetrigger: none意味着管线不会因目标仓库的推送或 PR 自动触发只能手动运行——这正是受控的集中式扫描的体现。测试断言pipeline.trigger为none且目标仓库资源的trigger同样为none。2.2 目标仓库资源resources: repositories: - repository: target type: git name: ExampleProject/example-app # Replace with the approved project/repository. ref: ${{ parameters.targetRef }} trigger: nonetarget是显式的仓库资源其name应在评审过的 YAML 中固定。稍后 SARIF 发布使用的advancedsecurity.publish.repository变量也直接来自这个资源元数据见 2.4确保告警归属到被扫描的仓库而非管线所在的工具仓库。2.3 变量与任务级配置variables: codexSecurityVersion: 0.1.27 awsServiceConnection: codex-security-bedrock awsRegion: us-east-1 bedrockModelId: REPLACE_WITH_APPROVED_MODEL_ID aws.rolecredential.maxduration: 3600 targetDirectory: $(Pipeline.Workspace)/s/scan-target scanDirectory: $(Agent.TempDirectory)/codex-security/scan reportDirectory: $(Agent.TempDirectory)/codex-security/reports scanExitCode: not-started sarifReady: false目录设计值得注意targetDirectory检出目录在Pipeline.Workspace下而scanDirectory扫描产物与reportDirectory最终报告都在Agent.TempDirectory下远离检出目录——扫描命令本身位于仓库之外CLI 安装目录同样位于Agent.TempDirectory/codex-security-cli。scanExitCode与sarifReady是任务间通信的状态变量初始值分别代表未开始与未就绪。2.4 任务编排jobs单个任务scan的核心步骤如下准备运行时UseNode1Node 24.21.0UsePythonVersion0Python 3.14.7。安装 CLIinstallCli在检出之前执行因此不会读取目标仓库的 npm 配置使用--ignore-scripts禁用 npm 生命周期脚本、--no-audit --no-fund并显式指定 npm registry然后把node_modules/.bin通过task.prependpath注入 PATH。测试专门断言了installCli步骤必须排在checkout之前。检出目标仓库checkout: targetpath: s/scan-targetfetchDepth: 0拉取完整历史保证差异计算可用persistCredentials: false不持久化凭据。执行扫描runScanAWSShellScript1使用 OIDC 服务连接disableAutoCwd: true并显式指定工作目录为$(targetDirectory)。导出 SARIFexportSarif条件为and(succeededOrFailed(), in(variables[scanExitCode], 0, 1))——只有扫描完成退出码 0 或 1才导出。发布 SARIF可选AdvancedSecurity-Publish1条件为and(succeededOrFailed(), eq(variables[sarifReady], true))Category: codex-security/${{ parameters.scanMode }}使全量与差异结果使用不同类别。收集报告stageReports只复制report.md、coverage.json、findings.json不复制原始扫描状态、transcript 或认证文件测试stageReports步骤时专门放入了auth.json、transcript.jsonl、workbench.sqlite3等文件并断言它们不会被收集。发布工件PublishPipelineArtifact1工件名为codex-security路径为$(reportDirectory)。任务级变量中有一条关键设置variables: # Attribute alerts to the scanned repository, not the pipelines repository. advancedsecurity.publish.repository: $[ convertToJson(resources.repositories[target]) ]SARIF 发布使用的是target仓库资源元数据而非工具仓库的构建元数据——这是 Microsoft 显式的多仓库发布机制。适配 YAML 时务必保持target的别名与advancedsecurity.publish.repository同步否则告警会落到错误的仓库。三、运行一次扫描参数语义详解从受信任的工具分支上选择Run pipeline然后设置以下参数参数含义targetRef目标分支或标签默认refs/heads/main。scanModefull表示基线全量扫描diff表示相对某个基准版本的变更扫描。baseRevision仅diff模式使用默认HEAD^上一个提交。可复现性要求下建议改用确切的基准提交 SHA。failOnSeveritynone表示仅出报告不失败选择某个严重级别后达到或超过该级别的发现会让任务以退出码 1 结束。publishToAdvancedSecurity完成前置配置后选择是否开启原生 SARIF 发布。建议的起步路径是先跑一次全量扫描建立基线之后的差异扫描选择目标分支与仓库历史中存在的基准修订。由于fetchDepth: 0拉取完整历史Codex Security 会在检出的提交上解析差异——注意这里扫描的是已提交的变更而不是自动发现的 PR。3.1 扫描命令与 CLI 参数映射runScan步骤的核心命令如下环境变量由 YAML 的env注入codex-security scan $TARGET_DIRECTORY --provider amazon-bedrock \ --model $BEDROCK_MODEL_ID --mode standard --effort high \ --output-dir $SCAN_DIRECTORY --json if [[ $SCAN_MODE diff ]]; then args(--diff $BASE_REVISION) fi if [[ $FAIL_ON_SEVERITY ! none ]]; then args(--fail-on-severity $FAIL_ON_SEVERITY) fi这些参数在sdk/typescript/src/cli.ts的scan命令 schema 中都有对应定义--provider推理提供方枚举[openai, openrouter, fireworks, amazon-bedrock]默认openai本示例固定为amazon-bedrock。--model模型 ID不能为空字符串使用--provider时必须显式提供。--mode扫描模式默认standarddeep模式支持仓库与路径目标并支持多 worker 并行本示例使用standard以保持简单与可控。--effort模型推理努力程度合法值为minimal, low, medium, high, xhigh, max本示例取high。--output-dir扫描产物目录必须位于仓库之外默认是 Codex Security 状态目录可由CODEX_SECURITY_STATE_DIR控制示例落在Agent.TempDirectory。--json以非交互 JSON 输出。--diffScan committed Git changes from BASE to --head即扫描从基准提交到HEAD之间的已提交Git 变更--head默认HEAD。示例把baseRevision直接作为 BASE 传入。--fail-on-severity严重性级别枚举none/low/medium/high/critical当存在达到或超过该级别的发现时以退出码 1 结束。该枚举在源码中由sdk/typescript/src/scan-settings.ts的FailureSeveritySchema约束同时被项目配置 schema 复用。测试azure-pipelines-example.test.ts对这段脚本做了三项关键断言可作为行为契约全量扫描时参数列表严格等于scan 目录 --provider amazon-bedrock --model id --mode standard --effort high --output-dir 目录 --json差异基准修订被字面量传递revision with spaces; $(exit 99)会原样出现在--diff之后不做 shell 求值避免注入任务退出码被完整保留并通过##vso[task.setvariable variablescanExitCode]status记录给后续任务使用。3.2 导出命令codex-security export $SCAN_DIRECTORY --export-format sarif \ --source-root $TARGET_DIRECTORY --output $REPORT_DIRECTORY/results.sarif对应源码中export命令的定义sdk/typescript/src/cli.ts--export-formatcsv | json | sarif默认sarif--output输出文件或-stdout默认results.sarif对应EXPORT_DEFAULT_OUTPUTS--source-root用于 SARIF 源码行指纹的仓库检出目录仅在--export-format sarif时允许否则报--source-root is only supported with --export-format sarif。测试断言导出成功后才会打印##vso[task.setvariable variablesarifReady]true若导出失败如退出码 2sarifReady不会被置位发布任务因此不会执行。四、结果与失败处理4.1 工件内容codex-security管道工件包含result.json扫描命令的原始 JSON 输出始终存在report.md、coverage.json、findings.json如果存在则被stageReports收集覆盖率为空或不完整不算干净的扫描需要在报告中核查results.sarif仅当导出成功后才出现。4.2 退出码语义与管线行为扫描退出码管线行为0扫描完成导出 SARIF 并保留报告。1严重性策略失败仍然导出 SARIF 并保留报告但任务保持失败状态。其他非零扫描失败或不完整仅保留已有报告不导出、不发布 SARIF。需要强调的细节导出或发布失败也会使任务失败取消运行会跳过扫描后步骤因此被取消的运行不保证产出工件原生发布会等待处理完成WaitForProcessing: true首次真实运行务必核对目标仓库与提交是否正确——本地验证无法证明组织内的 OIDC 信任关系、权限、模型访问或 SARIF 摄取是否真正生效。scanExitCode与sarifReady两个状态变量的组合正是这套按退出码分流逻辑的实现基础exportSarif只响应0/1AdvancedSecurity-Publish1只响应sarifReadytruestageReports与工件发布只要求scanExitCode ! not-started。五、信任与推广边界5.1 特权管线的信任模型严格限制谁能编辑或排队这条特权管线以及谁有权使用它的 AWS 服务连接。被扫描的代码与模型输出都应视为不可信输入。OIDC 消除了长期密钥但并不会让携带凭据运行不可信代码变得安全——它只是把风险窗口从长期压缩到单次会话。CLI 在目标仓库检出之前、仓库之外安装且--ignore-scripts禁用了 npm 生命周期脚本检出不持久化凭据persistCredentials: falseAWS 任务只向扫描步骤供应临时凭证没有 PAT 或 Azure 访问令牌被显式传给 CLI测试断言各步骤 env 中不存在SYSTEM_ACCESSTOKEN。5.2 报告与工件的保密性报告可能包含源码片段与漏洞细节。应限制工件访问范围并配置项目级管线运行保留策略。示例只保留选中的报告文件不保留原始扫描状态、transcript 或认证文件如auth.json。5.3 走向自动 PR 校验若要让扫描自动校验 Azure Repos 的 PR需要配置目标分支的build validation 策略并设计 PR 感知的检出/管线逻辑。两点误区需要避免YAML 中的pr:触发器并不会启用 Azure Repos 的 PR 校验把这条手动管线原封不动地挂到策略上它扫描的仍是指定的目标引用refs/heads/main不一定是 PR 的合并结果。因此从手动集中式扫描走向自动 PR 门禁必须在策略设计与检出方式上单独投入。六、延伸其他推理提供方与本示例的定位本示例把提供方锁定为amazon-bedrock以复用 Azure DevOps 中已有的 AWS OIDC 通道。若要在其他 CI 场景复用它核心可迁移的资产是先于检出安装 CLI、仓库外扫描、--json结果落盘、按退出码分流的后续步骤、只保留选中报告这套模式。仓库根README.md的 Other providers 一节展示了同样的scan --provider ... --model ...形态如何扩展到 OpenAI、OpenRouter、Fireworks 等提供方例如--provider openrouter --model anthropic/claude-sonnet-4.5或--provider fireworks --model accounts/fireworks/models/qwen3-235b-a22b配合相应的环境变量即可。此外CLI 还支持--path限定仓库内路径、--knowledge-base注入安全上下文文件、--effort全档位minimal到max等扫描控制以及--export-format csv/json/sarif的多种导出均可按需并入类似管线。结语这份 Azure Pipelines 示例的价值在于把可审计的集中式入口与最小化信任面结合在了一起固定且被评审的目标仓库、OIDC 短期凭证、仓库外安装与扫描、按退出码分流的产物策略以及可选的 Advanced Security 原生视图。以azure-pipelines-example.test.ts中的断言为行为契约你可以在自己的 Azure DevOps 组织中复刻这套流程并基于它继续演进为 PR 构建校验等自动化门禁。赞分享应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载相关推荐Codex Security GitHub Actions 集成实战基于 Amazon Bedrock 的 PR 差异扫描与 SARIF 上报Codex Security GitHub Actions 集成实战基于 Amazon Bedrock 的 PR 差异扫描与 SARIF 上报 导读 本文围绕应用安全漏洞扫描AI 应用Kubescape 接入 Azure Pipelines在 Azure DevOps CI/CD 中自动执行 Kubernetes 安全扫描Kubescape 接入 Azure Pipelines在 Azure DevOps CI/CD 中自动执行 Kubernetes 安全扫描 导读 本文以 d网络安全云原生应用安全运维Codex Security Deep Scan 语义归并Semantic Reducer实战基于 remediation-subsumption 的跨扫描去重与聚合指南Codex Security Deep Scan 语义归并Semantic Reducer实战基于 remediation subsumption 的跨扫应用安全漏洞扫描AI 应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Codex Security 接入 Azure Pipelines：基于 Amazon Bedrock 与 OIDC 的集中式安全扫描管线实战指南
应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载导读本指南围绕examples/azure-pipelines/中的完整示例讲解如何将 OpenAI Codex Security CLIopenai/codex-security接入 Azure DevOps Services通过一份集中托管的 Azure Pipelines YAML 对指定的 Azure Repos Git 仓库执行全量基线扫描与提交级差异扫描。方案使用 AWS OIDC 换取短期凭证调用 Amazon Bedrock 模型推理产出result.json、report.md、coverage.json、findings.json与results.sarif等报告工件并可选将 SARIF 发布到目标仓库的 GitHub Advanced Security 原生视图。读完本文你将掌握该示例的完整部署步骤、YAML 管线结构、每个运行参数的语义、退出码与产物处理策略以及这套集中式方案的信任边界与安全注意事项。方案概览与适用边界该示例的核心设计是集中式工具仓库 被动目标仓库管线定义存放在受信任的工具tooling仓库中目标仓库本身不需要携带任何管线文件也不发生任何 Codex Security 运行时改动或自定义扩展安装。一次扫描的完整链路如下Azure Pipelines 从工具仓库检出 YAML按参数解析出目标仓库引用与扫描模式在 Microsoft 托管的 Linux 代理ubuntu-24.04上通过 AWS Toolkit 的 OIDC 服务连接换取 1 小时的短期 AWS 凭证Codex Security CLI 以amazon-bedrock为推理提供方对目标仓库目录执行scan产出结构化 JSON 结果若扫描成功或仅因严重性策略失败export命令将结果导出为 SARIF可选地由AdvancedSecurity-Publish1任务把 SARIF 发布到目标仓库的 Advanced Security 视图最终由PublishPipelineArtifact1保留选中的报告工件。需要明确该示例的适用边界它面向Azure DevOps Services 与 Microsoft 托管 Linux 代理不自动注册仓库、不创建分支策略、也不自动校验 PR。若希望成为 Azure Repos 的 PR 门禁需要自行设计目标分支的 build validation 策略与 PR 感知的检出逻辑——详见后文信任与推广边界一节的讨论。一、部署前的准备工作原文档给出了 5 步设置流程这里结合 YAML 与仓库源码逐条展开。第 1 步复制管线文件并固定目标仓库将examples/azure-pipelines/azure-pipelines.yml复制进工具仓库并把resources.repositories.target.name修改为已获批准的项目/仓库名称例如ExampleProject/example-app同时调整默认的targetRef。安全要点在于仓库名应当固定在被评审过的 YAML 中而不是在排队时接受任意扫描目标否则任何能触发管线的人都能把扫描指向任意仓库。第 2 步配置 AWS Toolkit 与 OIDC 服务连接在组织内安装 AWS Toolkit for Azure DevOps 扩展并创建名为codex-security-bedrock的 AWS 服务连接认证方式选择Use OIDC填写 AWS 角色 ARN不要设置访问密钥按 AWS 的 OIDC 联邦接入指南完成 Azure DevOps 到 AWS 的联邦配置将角色的信任策略严格限定为该服务连接实际的 issuer、audience 与 subject并且只授权这条管线使用该连接。示例 YAML 中通过变量awsServiceConnection: codex-security-bedrock引用该连接扫描任务AWSShellScript1的awsCredentials输入即取自此变量。第 3 步选定 Bedrock 模型并约束角色权限设置awsRegion与bedrockModelId为可用的、已获批准的 Bedrock 模型或推理配置inference profile。角色仅需具备针对这些资源的最小 Bedrock 调用权限。注意 YAML 中设置了aws.rolecredential.maxduration: 3600即请求的 AWS 会话时长为1 小时与任务timeoutInMinutes: 60相匹配——角色的MaxSessionDuration必须允许该时长否则换取凭证会失败。第 4 步创建管线并授权跨项目检出创建指向该 YAML 的管线后授予管线所在项目的构建服务身份build service identity对目标仓库的读取权限在目标项目中对target仓库资源执行显式授权跨项目检出需要在目标项目中单独授权不要通过关闭 project-scoped job authorization 来绕过缺失的授权——这会引入不必要的权限放大。第 5 步SARIF 发布的开关策略默认保持publishToAdvancedSecurity: false仅做纯工件运行。要启用原生 findings 视图需先在目标仓库上启用所需的 GitHub Code Security / Advanced Security 许可并授予管线身份发布结果的权限之后在排队运行时再显式开启该开关。YAML 还固定了 CLI、Node 与 Python 的版本并采用当前的任务主版本号UseNode1、UsePythonVersion0、Bash3、AWSShellScript1、AdvancedSecurity-Publish1、PublishPipelineArtifact1。Azure Pipelines 会在这些主版本内解析兼容的任务更新因此在采用或升级示例时应复核固定的版本号。当前示例固定的版本为CLI0.1.27、Node24.21.0、Python3.14.7对应codexSecurityVersion、UseNode1的version与UsePythonVersion0的versionSpec。二、YAML 管线逐段解析完整文件位于examples/azure-pipelines/azure-pipelines.yml仓库测试sdk/typescript/tests-ts/azure-pipelines-example.test.ts对它的结构做了逐项断言可作为期望行为的权威参照。2.1 触发器与运行时参数trigger: none parameters: - name: targetRef type: string default: refs/heads/main - name: scanMode type: string default: full values: [full, diff] - name: baseRevision type: string default: HEAD^ - name: failOnSeverity type: string default: none values: [none, low, medium, high, critical] - name: publishToAdvancedSecurity type: boolean default: falsetrigger: none意味着管线不会因目标仓库的推送或 PR 自动触发只能手动运行——这正是受控的集中式扫描的体现。测试断言pipeline.trigger为none且目标仓库资源的trigger同样为none。2.2 目标仓库资源resources: repositories: - repository: target type: git name: ExampleProject/example-app # Replace with the approved project/repository. ref: ${{ parameters.targetRef }} trigger: nonetarget是显式的仓库资源其name应在评审过的 YAML 中固定。稍后 SARIF 发布使用的advancedsecurity.publish.repository变量也直接来自这个资源元数据见 2.4确保告警归属到被扫描的仓库而非管线所在的工具仓库。2.3 变量与任务级配置variables: codexSecurityVersion: 0.1.27 awsServiceConnection: codex-security-bedrock awsRegion: us-east-1 bedrockModelId: REPLACE_WITH_APPROVED_MODEL_ID aws.rolecredential.maxduration: 3600 targetDirectory: $(Pipeline.Workspace)/s/scan-target scanDirectory: $(Agent.TempDirectory)/codex-security/scan reportDirectory: $(Agent.TempDirectory)/codex-security/reports scanExitCode: not-started sarifReady: false目录设计值得注意targetDirectory检出目录在Pipeline.Workspace下而scanDirectory扫描产物与reportDirectory最终报告都在Agent.TempDirectory下远离检出目录——扫描命令本身位于仓库之外CLI 安装目录同样位于Agent.TempDirectory/codex-security-cli。scanExitCode与sarifReady是任务间通信的状态变量初始值分别代表未开始与未就绪。2.4 任务编排jobs单个任务scan的核心步骤如下准备运行时UseNode1Node 24.21.0UsePythonVersion0Python 3.14.7。安装 CLIinstallCli在检出之前执行因此不会读取目标仓库的 npm 配置使用--ignore-scripts禁用 npm 生命周期脚本、--no-audit --no-fund并显式指定 npm registry然后把node_modules/.bin通过task.prependpath注入 PATH。测试专门断言了installCli步骤必须排在checkout之前。检出目标仓库checkout: targetpath: s/scan-targetfetchDepth: 0拉取完整历史保证差异计算可用persistCredentials: false不持久化凭据。执行扫描runScanAWSShellScript1使用 OIDC 服务连接disableAutoCwd: true并显式指定工作目录为$(targetDirectory)。导出 SARIFexportSarif条件为and(succeededOrFailed(), in(variables[scanExitCode], 0, 1))——只有扫描完成退出码 0 或 1才导出。发布 SARIF可选AdvancedSecurity-Publish1条件为and(succeededOrFailed(), eq(variables[sarifReady], true))Category: codex-security/${{ parameters.scanMode }}使全量与差异结果使用不同类别。收集报告stageReports只复制report.md、coverage.json、findings.json不复制原始扫描状态、transcript 或认证文件测试stageReports步骤时专门放入了auth.json、transcript.jsonl、workbench.sqlite3等文件并断言它们不会被收集。发布工件PublishPipelineArtifact1工件名为codex-security路径为$(reportDirectory)。任务级变量中有一条关键设置variables: # Attribute alerts to the scanned repository, not the pipelines repository. advancedsecurity.publish.repository: $[ convertToJson(resources.repositories[target]) ]SARIF 发布使用的是target仓库资源元数据而非工具仓库的构建元数据——这是 Microsoft 显式的多仓库发布机制。适配 YAML 时务必保持target的别名与advancedsecurity.publish.repository同步否则告警会落到错误的仓库。三、运行一次扫描参数语义详解从受信任的工具分支上选择Run pipeline然后设置以下参数参数含义targetRef目标分支或标签默认refs/heads/main。scanModefull表示基线全量扫描diff表示相对某个基准版本的变更扫描。baseRevision仅diff模式使用默认HEAD^上一个提交。可复现性要求下建议改用确切的基准提交 SHA。failOnSeveritynone表示仅出报告不失败选择某个严重级别后达到或超过该级别的发现会让任务以退出码 1 结束。publishToAdvancedSecurity完成前置配置后选择是否开启原生 SARIF 发布。建议的起步路径是先跑一次全量扫描建立基线之后的差异扫描选择目标分支与仓库历史中存在的基准修订。由于fetchDepth: 0拉取完整历史Codex Security 会在检出的提交上解析差异——注意这里扫描的是已提交的变更而不是自动发现的 PR。3.1 扫描命令与 CLI 参数映射runScan步骤的核心命令如下环境变量由 YAML 的env注入codex-security scan $TARGET_DIRECTORY --provider amazon-bedrock \ --model $BEDROCK_MODEL_ID --mode standard --effort high \ --output-dir $SCAN_DIRECTORY --json if [[ $SCAN_MODE diff ]]; then args(--diff $BASE_REVISION) fi if [[ $FAIL_ON_SEVERITY ! none ]]; then args(--fail-on-severity $FAIL_ON_SEVERITY) fi这些参数在sdk/typescript/src/cli.ts的scan命令 schema 中都有对应定义--provider推理提供方枚举[openai, openrouter, fireworks, amazon-bedrock]默认openai本示例固定为amazon-bedrock。--model模型 ID不能为空字符串使用--provider时必须显式提供。--mode扫描模式默认standarddeep模式支持仓库与路径目标并支持多 worker 并行本示例使用standard以保持简单与可控。--effort模型推理努力程度合法值为minimal, low, medium, high, xhigh, max本示例取high。--output-dir扫描产物目录必须位于仓库之外默认是 Codex Security 状态目录可由CODEX_SECURITY_STATE_DIR控制示例落在Agent.TempDirectory。--json以非交互 JSON 输出。--diffScan committed Git changes from BASE to --head即扫描从基准提交到HEAD之间的已提交Git 变更--head默认HEAD。示例把baseRevision直接作为 BASE 传入。--fail-on-severity严重性级别枚举none/low/medium/high/critical当存在达到或超过该级别的发现时以退出码 1 结束。该枚举在源码中由sdk/typescript/src/scan-settings.ts的FailureSeveritySchema约束同时被项目配置 schema 复用。测试azure-pipelines-example.test.ts对这段脚本做了三项关键断言可作为行为契约全量扫描时参数列表严格等于scan 目录 --provider amazon-bedrock --model id --mode standard --effort high --output-dir 目录 --json差异基准修订被字面量传递revision with spaces; $(exit 99)会原样出现在--diff之后不做 shell 求值避免注入任务退出码被完整保留并通过##vso[task.setvariable variablescanExitCode]status记录给后续任务使用。3.2 导出命令codex-security export $SCAN_DIRECTORY --export-format sarif \ --source-root $TARGET_DIRECTORY --output $REPORT_DIRECTORY/results.sarif对应源码中export命令的定义sdk/typescript/src/cli.ts--export-formatcsv | json | sarif默认sarif--output输出文件或-stdout默认results.sarif对应EXPORT_DEFAULT_OUTPUTS--source-root用于 SARIF 源码行指纹的仓库检出目录仅在--export-format sarif时允许否则报--source-root is only supported with --export-format sarif。测试断言导出成功后才会打印##vso[task.setvariable variablesarifReady]true若导出失败如退出码 2sarifReady不会被置位发布任务因此不会执行。四、结果与失败处理4.1 工件内容codex-security管道工件包含result.json扫描命令的原始 JSON 输出始终存在report.md、coverage.json、findings.json如果存在则被stageReports收集覆盖率为空或不完整不算干净的扫描需要在报告中核查results.sarif仅当导出成功后才出现。4.2 退出码语义与管线行为扫描退出码管线行为0扫描完成导出 SARIF 并保留报告。1严重性策略失败仍然导出 SARIF 并保留报告但任务保持失败状态。其他非零扫描失败或不完整仅保留已有报告不导出、不发布 SARIF。需要强调的细节导出或发布失败也会使任务失败取消运行会跳过扫描后步骤因此被取消的运行不保证产出工件原生发布会等待处理完成WaitForProcessing: true首次真实运行务必核对目标仓库与提交是否正确——本地验证无法证明组织内的 OIDC 信任关系、权限、模型访问或 SARIF 摄取是否真正生效。scanExitCode与sarifReady两个状态变量的组合正是这套按退出码分流逻辑的实现基础exportSarif只响应0/1AdvancedSecurity-Publish1只响应sarifReadytruestageReports与工件发布只要求scanExitCode ! not-started。五、信任与推广边界5.1 特权管线的信任模型严格限制谁能编辑或排队这条特权管线以及谁有权使用它的 AWS 服务连接。被扫描的代码与模型输出都应视为不可信输入。OIDC 消除了长期密钥但并不会让携带凭据运行不可信代码变得安全——它只是把风险窗口从长期压缩到单次会话。CLI 在目标仓库检出之前、仓库之外安装且--ignore-scripts禁用了 npm 生命周期脚本检出不持久化凭据persistCredentials: falseAWS 任务只向扫描步骤供应临时凭证没有 PAT 或 Azure 访问令牌被显式传给 CLI测试断言各步骤 env 中不存在SYSTEM_ACCESSTOKEN。5.2 报告与工件的保密性报告可能包含源码片段与漏洞细节。应限制工件访问范围并配置项目级管线运行保留策略。示例只保留选中的报告文件不保留原始扫描状态、transcript 或认证文件如auth.json。5.3 走向自动 PR 校验若要让扫描自动校验 Azure Repos 的 PR需要配置目标分支的build validation 策略并设计 PR 感知的检出/管线逻辑。两点误区需要避免YAML 中的pr:触发器并不会启用 Azure Repos 的 PR 校验把这条手动管线原封不动地挂到策略上它扫描的仍是指定的目标引用refs/heads/main不一定是 PR 的合并结果。因此从手动集中式扫描走向自动 PR 门禁必须在策略设计与检出方式上单独投入。六、延伸其他推理提供方与本示例的定位本示例把提供方锁定为amazon-bedrock以复用 Azure DevOps 中已有的 AWS OIDC 通道。若要在其他 CI 场景复用它核心可迁移的资产是先于检出安装 CLI、仓库外扫描、--json结果落盘、按退出码分流的后续步骤、只保留选中报告这套模式。仓库根README.md的 Other providers 一节展示了同样的scan --provider ... --model ...形态如何扩展到 OpenAI、OpenRouter、Fireworks 等提供方例如--provider openrouter --model anthropic/claude-sonnet-4.5或--provider fireworks --model accounts/fireworks/models/qwen3-235b-a22b配合相应的环境变量即可。此外CLI 还支持--path限定仓库内路径、--knowledge-base注入安全上下文文件、--effort全档位minimal到max等扫描控制以及--export-format csv/json/sarif的多种导出均可按需并入类似管线。结语这份 Azure Pipelines 示例的价值在于把可审计的集中式入口与最小化信任面结合在了一起固定且被评审的目标仓库、OIDC 短期凭证、仓库外安装与扫描、按退出码分流的产物策略以及可选的 Advanced Security 原生视图。以azure-pipelines-example.test.ts中的断言为行为契约你可以在自己的 Azure DevOps 组织中复刻这套流程并基于它继续演进为 PR 构建校验等自动化门禁。赞分享应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载相关推荐Codex Security GitHub Actions 集成实战基于 Amazon Bedrock 的 PR 差异扫描与 SARIF 上报Codex Security GitHub Actions 集成实战基于 Amazon Bedrock 的 PR 差异扫描与 SARIF 上报 导读 本文围绕应用安全漏洞扫描AI 应用Kubescape 接入 Azure Pipelines在 Azure DevOps CI/CD 中自动执行 Kubernetes 安全扫描Kubescape 接入 Azure Pipelines在 Azure DevOps CI/CD 中自动执行 Kubernetes 安全扫描 导读 本文以 d网络安全云原生应用安全运维Codex Security Deep Scan 语义归并Semantic Reducer实战基于 remediation-subsumption 的跨扫描去重与聚合指南Codex Security Deep Scan 语义归并Semantic Reducer实战基于 remediation subsumption 的跨扫应用安全漏洞扫描AI 应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考