應用安全漏洞掃描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 倉庫執(zhí)行全量基線掃描與提交級差異掃描。方案使用 AWS OIDC 換取短期憑證調(diào)用 Amazon Bedrock 模型推理產(chǎn)出result.json、report.md、coverage.json、findings.json與results.sarif等報告工件并可選將 SARIF 發(fā)布到目標倉庫的 GitHub Advanced Security 原生視圖。讀完本文你將掌握該示例的完整部署步驟、YAML 管線結(jié)構(gòu)、每個運行參數(shù)的語義、退出碼與產(chǎn)物處理策略以及這套集中式方案的信任邊界與安全注意事項。方案概覽與適用邊界該示例的核心設計是集中式工具倉庫 被動目標倉庫管線定義存放在受信任的工具tooling倉庫中目標倉庫本身不需要攜帶任何管線文件也不發(fā)生任何 Codex Security 運行時改動或自定義擴展安裝。一次掃描的完整鏈路如下Azure Pipelines 從工具倉庫檢出 YAML按參數(shù)解析出目標倉庫引用與掃描模式在 Microsoft 托管的 Linux 代理ubuntu-24.04上通過 AWS Toolkit 的 OIDC 服務連接換取 1 小時的短期 AWS 憑證Codex Security CLI 以amazon-bedrock為推理提供方對目標倉庫目錄執(zhí)行scan產(chǎn)出結(jié)構(gòu)化 JSON 結(jié)果若掃描成功或僅因嚴重性策略失敗export命令將結(jié)果導出為 SARIF可選地由AdvancedSecurity-Publish1任務把 SARIF 發(fā)布到目標倉庫的 Advanced Security 視圖最終由PublishPipelineArtifact1保留選中的報告工件。需要明確該示例的適用邊界它面向Azure DevOps Services 與 Microsoft 托管 Linux 代理不自動注冊倉庫、不創(chuàng)建分支策略、也不自動校驗 PR。若希望成為 Azure Repos 的 PR 門禁需要自行設計目標分支的 build validation 策略與 PR 感知的檢出邏輯——詳見后文信任與推廣邊界一節(jié)的討論。一、部署前的準備工作原文檔給出了 5 步設置流程這里結(jié)合 YAML 與倉庫源碼逐條展開。第 1 步復制管線文件并固定目標倉庫將examples/azure-pipelines/azure-pipelines.yml復制進工具倉庫并把resources.repositories.target.name修改為已獲批準的項目/倉庫名稱例如ExampleProject/example-app同時調(diào)整默認的targetRef。安全要點在于倉庫名應當固定在被評審過的 YAML 中而不是在排隊時接受任意掃描目標否則任何能觸發(fā)管線的人都能把掃描指向任意倉庫。第 2 步配置 AWS Toolkit 與 OIDC 服務連接在組織內(nèi)安裝 AWS Toolkit for Azure DevOps 擴展并創(chuàng)建名為codex-security-bedrock的 AWS 服務連接認證方式選擇Use OIDC填寫 AWS 角色 ARN不要設置訪問密鑰按 AWS 的 OIDC 聯(lián)邦接入指南完成 Azure DevOps 到 AWS 的聯(lián)邦配置將角色的信任策略嚴格限定為該服務連接實際的 issuer、audience 與 subject并且只授權(quán)這條管線使用該連接。示例 YAML 中通過變量awsServiceConnection: codex-security-bedrock引用該連接掃描任務AWSShellScript1的awsCredentials輸入即取自此變量。第 3 步選定 Bedrock 模型并約束角色權(quán)限設置awsRegion與bedrockModelId為可用的、已獲批準的 Bedrock 模型或推理配置inference profile。角色僅需具備針對這些資源的最小 Bedrock 調(diào)用權(quán)限。注意 YAML 中設置了aws.rolecredential.maxduration: 3600即請求的 AWS 會話時長為1 小時與任務timeoutInMinutes: 60相匹配——角色的MaxSessionDuration必須允許該時長否則換取憑證會失敗。第 4 步創(chuàng)建管線并授權(quán)跨項目檢出創(chuàng)建指向該 YAML 的管線后授予管線所在項目的構(gòu)建服務身份build service identity對目標倉庫的讀取權(quán)限在目標項目中對target倉庫資源執(zhí)行顯式授權(quán)跨項目檢出需要在目標項目中單獨授權(quán)不要通過關閉 project-scoped job authorization 來繞過缺失的授權(quán)——這會引入不必要的權(quán)限放大。第 5 步SARIF 發(fā)布的開關策略默認保持publishToAdvancedSecurity: false僅做純工件運行。要啟用原生 findings 視圖需先在目標倉庫上啟用所需的 GitHub Code Security / Advanced Security 許可并授予管線身份發(fā)布結(jié)果的權(quán)限之后在排隊運行時再顯式開啟該開關。YAML 還固定了 CLI、Node 與 Python 的版本并采用當前的任務主版本號UseNode1、UsePythonVersion0、Bash3、AWSShellScript1、AdvancedSecurity-Publish1、PublishPipelineArtifact1。Azure Pipelines 會在這些主版本內(nèi)解析兼容的任務更新因此在采用或升級示例時應復核固定的版本號。當前示例固定的版本為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對它的結(jié)構(gòu)做了逐項斷言可作為期望行為的權(quán)威參照。2.1 觸發(fā)器與運行時參數(shù)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 自動觸發(fā)只能手動運行——這正是受控的集中式掃描的體現(xiàn)。測試斷言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 發(fā)布使用的advancedsecurity.publish.repository變量也直接來自這個資源元數(shù)據(jù)見 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掃描產(chǎn)物與reportDirectory最終報告都在Agent.TempDirectory下遠離檢出目錄——掃描命令本身位于倉庫之外CLI 安裝目錄同樣位于Agent.TempDirectory/codex-security-cli。scanExitCode與sarifReady是任務間通信的狀態(tài)變量初始值分別代表未開始與未就緒。2.4 任務編排jobs單個任務scan的核心步驟如下準備運行時UseNode1Node 24.21.0UsePythonVersion0Python 3.14.7。安裝 CLIinstallCli在檢出之前執(zhí)行因此不會讀取目標倉庫的 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不持久化憑據(jù)。執(zhí)行掃描runScanAWSShellScript1使用 OIDC 服務連接disableAutoCwd: true并顯式指定工作目錄為$(targetDirectory)。導出 SARIFexportSarif條件為and(succeededOrFailed(), in(variables[scanExitCode], 0, 1))——只有掃描完成退出碼 0 或 1才導出。發(fā)布 SARIF可選AdvancedSecurity-Publish1條件為and(succeededOrFailed(), eq(variables[sarifReady], true))Category: codex-security/${{ parameters.scanMode }}使全量與差異結(jié)果使用不同類別。收集報告stageReports只復制report.md、coverage.json、findings.json不復制原始掃描狀態(tài)、transcript 或認證文件測試stageReports步驟時專門放入了auth.json、transcript.jsonl、workbench.sqlite3等文件并斷言它們不會被收集。發(fā)布工件PublishPipelineArtifact1工件名為codex-security路徑為$(reportDirectory)。任務級變量中有一條關鍵設置variables: # Attribute alerts to the scanned repository, not the pipelines repository. advancedsecurity.publish.repository: $[ convertToJson(resources.repositories[target]) ]SARIF 發(fā)布使用的是target倉庫資源元數(shù)據(jù)而非工具倉庫的構(gòu)建元數(shù)據(jù)——這是 Microsoft 顯式的多倉庫發(fā)布機制。適配 YAML 時務必保持target的別名與advancedsecurity.publish.repository同步否則告警會落到錯誤的倉庫。三、運行一次掃描參數(shù)語義詳解從受信任的工具分支上選擇Run pipeline然后設置以下參數(shù)參數(shù)含義targetRef目標分支或標簽默認refs/heads/main。scanModefull表示基線全量掃描diff表示相對某個基準版本的變更掃描。baseRevision僅diff模式使用默認HEAD^上一個提交?？蓮同F(xiàn)性要求下建議改用確切的基準提交 SHA。failOnSeveritynone表示僅出報告不失敗選擇某個嚴重級別后達到或超過該級別的發(fā)現(xiàn)會讓任務以退出碼 1 結(jié)束。publishToAdvancedSecurity完成前置配置后選擇是否開啟原生 SARIF 發(fā)布。建議的起步路徑是先跑一次全量掃描建立基線之后的差異掃描選擇目標分支與倉庫歷史中存在的基準修訂。由于fetchDepth: 0拉取完整歷史Codex Security 會在檢出的提交上解析差異——注意這里掃描的是已提交的變更而不是自動發(fā)現(xiàn)的 PR。3.1 掃描命令與 CLI 參數(shù)映射runScan步驟的核心命令如下環(huán)境變量由 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這些參數(shù)在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掃描產(chǎn)物目錄必須位于倉庫之外默認是 Codex Security 狀態(tài)目錄可由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當存在達到或超過該級別的發(fā)現(xiàn)時以退出碼 1 結(jié)束。該枚舉在源碼中由sdk/typescript/src/scan-settings.ts的FailureSeveritySchema約束同時被項目配置 schema 復用。測試azure-pipelines-example.test.ts對這段腳本做了三項關鍵斷言可作為行為契約全量掃描時參數(shù)列表嚴格等于scan 目錄 --provider amazon-bedrock --model id --mode standard --effort high --output-dir 目錄 --json差異基準修訂被字面量傳遞revision with spaces; $(exit 99)會原樣出現(xiàn)在--diff之后不做 shell 求值避免注入任務退出碼被完整保留并通過##vso[task.setvariable variablescanExitCode]status記錄給后續(xù)任務使用。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不會被置位發(fā)布任務因此不會執(zhí)行。四、結(jié)果與失敗處理4.1 工件內(nèi)容codex-security管道工件包含result.json掃描命令的原始 JSON 輸出始終存在report.md、coverage.json、findings.json如果存在則被stageReports收集覆蓋率為空或不完整不算干凈的掃描需要在報告中核查results.sarif僅當導出成功后才出現(xiàn)。4.2 退出碼語義與管線行為掃描退出碼管線行為0掃描完成導出 SARIF 并保留報告。1嚴重性策略失敗仍然導出 SARIF 并保留報告但任務保持失敗狀態(tài)。其他非零掃描失敗或不完整僅保留已有報告不導出、不發(fā)布 SARIF。需要強調(diào)的細節(jié)導出或發(fā)布失敗也會使任務失敗取消運行會跳過掃描后步驟因此被取消的運行不保證產(chǎn)出工件原生發(fā)布會等待處理完成WaitForProcessing: true首次真實運行務必核對目標倉庫與提交是否正確——本地驗證無法證明組織內(nèi)的 OIDC 信任關系、權(quán)限、模型訪問或 SARIF 攝取是否真正生效。scanExitCode與sarifReady兩個狀態(tài)變量的組合正是這套按退出碼分流邏輯的實現(xiàn)基礎exportSarif只響應0/1AdvancedSecurity-Publish1只響應sarifReadytruestageReports與工件發(fā)布只要求scanExitCode ! not-started。五、信任與推廣邊界5.1 特權(quán)管線的信任模型嚴格限制誰能編輯或排隊這條特權(quán)管線以及誰有權(quán)使用它的 AWS 服務連接。被掃描的代碼與模型輸出都應視為不可信輸入。OIDC 消除了長期密鑰但并不會讓攜帶憑據(jù)運行不可信代碼變得安全——它只是把風險窗口從長期壓縮到單次會話。CLI 在目標倉庫檢出之前、倉庫之外安裝且--ignore-scripts禁用了 npm 生命周期腳本檢出不持久化憑據(jù)persistCredentials: falseAWS 任務只向掃描步驟供應臨時憑證沒有 PAT 或 Azure 訪問令牌被顯式傳給 CLI測試斷言各步驟 env 中不存在SYSTEM_ACCESSTOKEN。5.2 報告與工件的保密性報告可能包含源碼片段與漏洞細節(jié)。應限制工件訪問范圍并配置項目級管線運行保留策略。示例只保留選中的報告文件不保留原始掃描狀態(tài)、transcript 或認證文件如auth.json。5.3 走向自動 PR 校驗若要讓掃描自動校驗 Azure Repos 的 PR需要配置目標分支的build validation 策略并設計 PR 感知的檢出/管線邏輯。兩點誤區(qū)需要避免YAML 中的pr:觸發(fā)器并不會啟用 Azure Repos 的 PR 校驗把這條手動管線原封不動地掛到策略上它掃描的仍是指定的目標引用refs/heads/main不一定是 PR 的合并結(jié)果。因此從手動集中式掃描走向自動 PR 門禁必須在策略設計與檢出方式上單獨投入。六、延伸其他推理提供方與本示例的定位本示例把提供方鎖定為amazon-bedrock以復用 Azure DevOps 中已有的 AWS OIDC 通道。若要在其他 CI 場景復用它核心可遷移的資產(chǎn)是先于檢出安裝 CLI、倉庫外掃描、--json結(jié)果落盤、按退出碼分流的后續(xù)步驟、只保留選中報告這套模式。倉庫根README.md的 Other providers 一節(jié)展示了同樣的scan --provider ... --model ...形態(tài)如何擴展到 OpenAI、OpenRouter、Fireworks 等提供方例如--provider openrouter --model anthropic/claude-sonnet-4.5或--provider fireworks --model accounts/fireworks/models/qwen3-235b-a22b配合相應的環(huán)境變量即可。此外CLI 還支持--path限定倉庫內(nèi)路徑、--knowledge-base注入安全上下文文件、--effort全檔位minimal到max等掃描控制以及--export-format csv/json/sarif的多種導出均可按需并入類似管線。結(jié)語這份 Azure Pipelines 示例的價值在于把可審計的集中式入口與最小化信任面結(jié)合在了一起固定且被評審的目標倉庫、OIDC 短期憑證、倉庫外安裝與掃描、按退出碼分流的產(chǎn)物策略以及可選的 Advanced Security 原生視圖。以azure-pipelines-example.test.ts中的斷言為行為契約你可以在自己的 Azure DevOps 組織中復刻這套流程并基于它繼續(xù)演進為 PR 構(gòu)建校驗等自動化門禁。贊分享應用安全漏洞掃描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 集成實戰(zhàn)基于 Amazon Bedrock 的 PR 差異掃描與 SARIF 上報Codex Security GitHub Actions 集成實戰(zhàn)基于 Amazon Bedrock 的 PR 差異掃描與 SARIF 上報 導讀 本文圍繞應用安全漏洞掃描AI 應用Kubescape 接入 Azure Pipelines在 Azure DevOps CI/CD 中自動執(zhí)行 Kubernetes 安全掃描Kubescape 接入 Azure Pipelines在 Azure DevOps CI/CD 中自動執(zhí)行 Kubernetes 安全掃描 導讀 本文以 d網(wǎng)絡安全云原生應用安全運維Codex Security Deep Scan 語義歸并Semantic Reducer實戰(zhàn)基于 remediation-subsumption 的跨掃描去重與聚合指南Codex Security Deep Scan 語義歸并Semantic Reducer實戰(zhàn)基于 remediation subsumption 的跨掃應用安全漏洞掃描AI 應用創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考