AI 生成程式碼的稽核方法論

中級3 分鐘閱讀更新於 2026-03-20

用於評估 AI 生成程式碼安全性的結構化稽核方法論,涵蓋靜態分析、動態測試與組織面評估。

code-gen-security audit-methodology security-assessment code-review

概述

稽核 AI 生成的程式碼需要不同於傳統程式碼審查的作法。AI 生成程式碼具有特有的漏洞模式,缺乏人類開發者帶來的脈絡理解,且產生的量級使得人工審查不切實際。組織需要一套結構化方法論,結合自動化工具與針對性的人工審查,並於開發生命週期的適當環節導入。

本文提出完整的 AI 生成程式碼稽核方法論,涵蓋辨識、靜態分析、動態測試與組織面評估。此方法論旨在可重複、可擴充,並可整合至既有安全計畫。

稽核框架概覽

階段模型

AI 程式碼生成稽核方法論包含五個階段:

辨識 (Identification):目標是找出哪些程式碼為 AI 生成、使用了哪些工具。活動包含訪談開發者的 AI 工具使用模式、分析 git 歷史中的 AI 提交、檢閱 CI/CD 日誌中的 AI 工具整合、盤點 AI 工具設定檔 (.cursorrules、CLAUDE.md、.aiderignore),並識別高風險區域 (認證、加密、輸入處理)。工具:git、自訂腳本、開發者訪談。產出:AI 程式碼生成清單、工具使用地圖、高風險區域辨識。估時約 4 小時。
靜態分析 (Static Analysis):目標是偵測 AI 生成程式碼特有的漏洞模式。活動包含執行帶 AI 專用規則集的 Semgrep、以 CodeQL 做資料流分析、以 Bandit 掃描 Python 安全議題、檢查已知 AI 漏洞模式,以及掃描授權合規問題。工具:Semgrep、CodeQL、Bandit、ScanCode。產出:靜態分析發現報告、帶嚴重性評等的漏洞清單、授權合規報告。估時約 8 小時。
動態測試 (Dynamic Testing):目標是驗證識別出的漏洞是否可被利用。活動包含測試靜態分析指出的 SQL 注入點、以設計過的 payload 測試 XSS 接收點、測試認證與授權邊界、測試 AI 生成的 shell 互動的命令注入,以及對 AI 產出的 API 端點進行 fuzzing。工具:Burp Suite、sqlmap、自訂指令稿、pytest。產出:已確認漏洞清單、PoC 漏洞利用、誤報分析。估時約 12 小時。
組織面評估 (Organizational):目標是評估組織層級對 AI 程式碼生成的管控。活動包含檢閱 AI 工具治理政策、評估開發者 AI 程式碼安全訓練、檢閱針對 AI 生成程式碼的程式碼審查流程、評估 CI/CD 對 AI 程式碼的安全閘道,以及資料分類合規檢查。工具:政策文件、訪談、流程檢閱。產出:組織成熟度評估、政策落差分析、流程改善建議。估時約 6 小時。
報告 (Reporting):目標是產出附優先度建議的可執行發現。活動包含整合技術與組織面發現、依可利用性與衝擊進行風險排序、擬定補救建議、撰寫摘要,並向相關人員簡報。工具:報告範本、風險框架。產出:技術稽核報告、高階摘要、補救路線圖。估時約 4 小時。

階段 1:AI 程式碼辨識

Git 歷史分析

第一個挑戰是辨識哪些程式碼由 AI 生成,下列訊號有所助益:

AI 提交模式:提交訊息或作者中出現 generated by copilot/cursor/claude/aider/gpt/ai、co-authored-by: copilot/claude/aider、Aider 的 aider: 前綴,或 [ai]、[generated]、[copilot] 標記。
AI 程式碼模式:原始碼中出現 # Generated by、// Auto-generated、# TODO: Add error handling、# TODO: Add tests、pass # placeholder 等 AI 常見佔位。
程式撰寫速率:短時間內出現大量新增程式碼且刪除極少,可能代表導入 AI 工具。

實作流程以 git log --since=... 取得提交資料,再以正規表示式比對上列模式;對程式碼檔案 (.py、.js、.ts、.jsx、.tsx、.java、.go) 逐行掃描 AI 特徵,排除 node_modules、.git、venv 等目錄。

開發者訪談指南

結構化訪談題目可分四類:

工具使用:使用哪些 AI 程式碼工具 (Copilot、Cursor、Claude Code、Aider 等)?未經修改就接受 AI 建議的頻率?是否用 AI 生成安全敏感程式碼 (認證、加密、輸入驗證)?典型使用的模型 (GPT-4、Claude、Codex、地端模型)?使用代理/自主模式,還是僅使用補全/建議模式?
程式碼審查:接受 AI 建議前如何審查?審查時是否區分人類與 AI 撰寫的程式碼?曾否在 AI 生成程式碼中攔下安全問題?AI 產出的變更在 PR 中是否受到差別審查?
設定檔:專案中是否存在 .cursorrules、CLAUDE.md 或 .aiderignore?由誰維護這些檔案?是否存在專案層級的安全指令給 AI 工具?是否使用 .cursorignore 或類似機制排除敏感檔案?
事件:曾否遭遇與 AI 生成程式碼相關的安全問題?AI 生成程式碼是否曾導入難以診斷的 bug?是否見過 AI 建議不存在的相依性?

階段 2:靜態分析

AI 專用的 Semgrep 設定

針對 AI 生成程式碼常見問題,可撰寫以下 Semgrep 規則 (以 Python 為例):

ai-sql-fstring:偵測 CURSOR.execute(f"...{VAR}...") 的 f-string SQL 注入模式;AI 程式助理常產生此樣式,應改用參數化查詢。CWE-89,嚴重性 ERROR。
ai-hardcoded-secret:偵測 KEY = "sk-..."、api_key = "..."、password = "..." 等硬編碼憑證;AI 常產生佔位憑證,開發者容易忘記更換。CWE-798,嚴重性 ERROR。
ai-missing-input-validation:偵測 POST 端點直接將 request.json 寫入資料庫而無 validate(...) 呼叫;AI 產出的端點常省略輸入驗證。CWE-20,嚴重性 WARNING。
ai-pickle-load:偵測對不可信資料呼叫 pickle.load(...),允許任意程式碼執行;AI 助理常建議用 pickle 做序列化。CWE-502,嚴重性 ERROR。
ai-bare-except:偵測 except: pass 會吞掉所有例外,包括安全相關者;AI 工具常以此作為佔位符。CWE-755,嚴重性 WARNING。

執行靜態分析套件

建議以一組 Bash 腳本串接多種工具:

Semgrep:以 p/owasp-top-ten、p/python-sql-injection、p/xss、p/python-security-audit 等規則集執行,排除 node_modules、.git、venv,輸出 JSON 後依嚴重性分類統計。
Bandit (Python 安全 linter):bandit -r PROJECT_DIR -f json -o bandit-results.json -ll,排除 .git、node_modules、venv、__pycache__。
AI 特定模式檢查:以 grep 掃描硬編碼憑證 (api_key\s*=\s*['\"])、eval/exec 使用、以及裸 except: 子句。

階段 3:動態測試

針對性測試策略

動態測試應聚焦於 AI 最容易導入的漏洞類型:

SQL 注入:對清單中的端點 (含參數名) 發送常見 payload,例如 ' OR '1'='1、' OR '1'='1' --、1; DROP TABLE users --、' UNION SELECT NULL, username, password FROM users --、1' AND SLEEP(5) --。在回應中搜尋 syntax error、mysql_fetch、sqlite3.OperationalError、psycopg2.errors、ORA-、SQLSTATE 等錯誤訊息;若 payload 含 SLEEP 且回應時間超過 4 秒或請求逾時,視為時序盲注跡象。
XSS:對相同端點發送 <script>alert("XSS")</script>、<img src=x onerror=alert(1)>、" onmouseover="alert(1)"、javascript:alert(1)、<svg/onload=alert(1)>;若 payload 原樣回映於回應中即視為反射型 XSS。
認證繞過:對受保護端點嘗試多種繞過技巧 (無 Authorization 標頭、空的 Bearer、無效權杖、偽造 X-User-Role: admin 等),若傳回 200 OK 即視為繞過成功。

階段 4:組織面評估

成熟度模型

沿 CMMI 五級模型設定 AI 程式碼安全成熟度的五個面向:

工具治理:L1 無 AI 工具使用政策 → L2 非正式的已核可工具指引 → L3 附已核可工具清單的正式政策 → L4 由技術控制強制執行 → L5 持續評估新工具。
程式碼審查:L1 不區分 AI 與人類程式碼 → L2 意識到 AI 程式碼需額外審查 → L3 已文件化的 AI 程式碼審查清單 → L4 CI/CD 中自動化檢查 AI 模式 → L5 以指標驅動的持續改善。
開發者訓練:L1 無 AI 程式碼安全訓練 → L2 臨時性的意識宣導 → L3 針對 AI 工具使用者的正式訓練 → L4 定期訓練並評估 → L5 結合 AI 情境的威脅建模演練。
靜態分析:L1 無靜態分析 → L2 通用 SAST 但無 AI 專用規則 → L3 SAST 搭配 AI 專用規則集 → L4 依組織 AI 模式自訂規則 → L5 ML 增強的 AI 程式碼問題偵測。
事件回應:L1 無 AI 專用事件程序 → L2 AI 程式碼問題臨時處理 → L3 AI 程式碼事件已文件化手冊 → L4 以桌上演練落地手冊 → L5 自動化偵測與回應。

OWASP Code Review Guide — https://owasp.org/www-project-code-review-guide/
Semgrep Documentation — https://semgrep.dev/docs/
CodeQL Documentation — https://codeql.github.com/docs/
"Do Users Write More Insecure Code with AI Assistants?" — Perry et al., 2023 — https://arxiv.org/abs/2211.03622
OWASP Top 10 for LLM Applications 2025 — https://genai.owasp.org/llmrisk/
NIST AI Risk Management Framework — https://www.nist.gov/artificial-intelligence/ai-risk-management-framework
CWE Top 25 Most Dangerous Software Weaknesses — https://cwe.mitre.org/top25/

AI 生成程式碼的稽核方法論

中級3 分鐘閱讀更新於 2026-03-20

用於評估 AI 生成程式碼安全性的結構化稽核方法論,涵蓋靜態分析、動態測試與組織面評估。

code-gen-security audit-methodology security-assessment code-review

辨識 (Identification):目標是找出哪些程式碼為 AI 生成、使用了哪些工具。活動包含訪談開發者的 AI 工具使用模式、分析 git 歷史中的 AI 提交、檢閱 CI/CD 日誌中的 AI 工具整合、盤點 AI 工具設定檔 (.cursorrules、CLAUDE.md、.aiderignore),並識別高風險區域 (認證、加密、輸入處理)。工具:git、自訂腳本、開發者訪談。產出:AI 程式碼生成清單、工具使用地圖、高風險區域辨識。估時約 4 小時。
靜態分析 (Static Analysis):目標是偵測 AI 生成程式碼特有的漏洞模式。活動包含執行帶 AI 專用規則集的 Semgrep、以 CodeQL 做資料流分析、以 Bandit 掃描 Python 安全議題、檢查已知 AI 漏洞模式,以及掃描授權合規問題。工具:Semgrep、CodeQL、Bandit、ScanCode。產出:靜態分析發現報告、帶嚴重性評等的漏洞清單、授權合規報告。估時約 8 小時。
動態測試 (Dynamic Testing):目標是驗證識別出的漏洞是否可被利用。活動包含測試靜態分析指出的 SQL 注入點、以設計過的 payload 測試 XSS 接收點、測試認證與授權邊界、測試 AI 生成的 shell 互動的命令注入,以及對 AI 產出的 API 端點進行 fuzzing。工具:Burp Suite、sqlmap、自訂指令稿、pytest。產出:已確認漏洞清單、PoC 漏洞利用、誤報分析。估時約 12 小時。
組織面評估 (Organizational):目標是評估組織層級對 AI 程式碼生成的管控。活動包含檢閱 AI 工具治理政策、評估開發者 AI 程式碼安全訓練、檢閱針對 AI 生成程式碼的程式碼審查流程、評估 CI/CD 對 AI 程式碼的安全閘道,以及資料分類合規檢查。工具:政策文件、訪談、流程檢閱。產出:組織成熟度評估、政策落差分析、流程改善建議。估時約 6 小時。
報告 (Reporting):目標是產出附優先度建議的可執行發現。活動包含整合技術與組織面發現、依可利用性與衝擊進行風險排序、擬定補救建議、撰寫摘要,並向相關人員簡報。工具:報告範本、風險框架。產出:技術稽核報告、高階摘要、補救路線圖。估時約 4 小時。

階段 1:AI 程式碼辨識

Git 歷史分析

第一個挑戰是辨識哪些程式碼由 AI 生成,下列訊號有所助益:

AI 提交模式:提交訊息或作者中出現 generated by copilot/cursor/claude/aider/gpt/ai、co-authored-by: copilot/claude/aider、Aider 的 aider: 前綴,或 [ai]、[generated]、[copilot] 標記。
AI 程式碼模式:原始碼中出現 # Generated by、// Auto-generated、# TODO: Add error handling、# TODO: Add tests、pass # placeholder 等 AI 常見佔位。
程式撰寫速率:短時間內出現大量新增程式碼且刪除極少,可能代表導入 AI 工具。

開發者訪談指南

結構化訪談題目可分四類:

工具使用:使用哪些 AI 程式碼工具 (Copilot、Cursor、Claude Code、Aider 等)?未經修改就接受 AI 建議的頻率?是否用 AI 生成安全敏感程式碼 (認證、加密、輸入驗證)?典型使用的模型 (GPT-4、Claude、Codex、地端模型)?使用代理/自主模式,還是僅使用補全/建議模式?
程式碼審查:接受 AI 建議前如何審查?審查時是否區分人類與 AI 撰寫的程式碼?曾否在 AI 生成程式碼中攔下安全問題?AI 產出的變更在 PR 中是否受到差別審查?
設定檔:專案中是否存在 .cursorrules、CLAUDE.md 或 .aiderignore?由誰維護這些檔案?是否存在專案層級的安全指令給 AI 工具?是否使用 .cursorignore 或類似機制排除敏感檔案?
事件:曾否遭遇與 AI 生成程式碼相關的安全問題?AI 生成程式碼是否曾導入難以診斷的 bug?是否見過 AI 建議不存在的相依性?

階段 2:靜態分析

AI 專用的 Semgrep 設定

針對 AI 生成程式碼常見問題,可撰寫以下 Semgrep 規則 (以 Python 為例):

ai-sql-fstring:偵測 CURSOR.execute(f"...{VAR}...") 的 f-string SQL 注入模式;AI 程式助理常產生此樣式,應改用參數化查詢。CWE-89,嚴重性 ERROR。
ai-hardcoded-secret:偵測 KEY = "sk-..."、api_key = "..."、password = "..." 等硬編碼憑證;AI 常產生佔位憑證,開發者容易忘記更換。CWE-798,嚴重性 ERROR。
ai-missing-input-validation:偵測 POST 端點直接將 request.json 寫入資料庫而無 validate(...) 呼叫;AI 產出的端點常省略輸入驗證。CWE-20,嚴重性 WARNING。
ai-pickle-load:偵測對不可信資料呼叫 pickle.load(...),允許任意程式碼執行;AI 助理常建議用 pickle 做序列化。CWE-502,嚴重性 ERROR。
ai-bare-except:偵測 except: pass 會吞掉所有例外,包括安全相關者;AI 工具常以此作為佔位符。CWE-755,嚴重性 WARNING。

執行靜態分析套件

建議以一組 Bash 腳本串接多種工具:

Semgrep:以 p/owasp-top-ten、p/python-sql-injection、p/xss、p/python-security-audit 等規則集執行,排除 node_modules、.git、venv,輸出 JSON 後依嚴重性分類統計。
Bandit (Python 安全 linter):bandit -r PROJECT_DIR -f json -o bandit-results.json -ll,排除 .git、node_modules、venv、__pycache__。
AI 特定模式檢查:以 grep 掃描硬編碼憑證 (api_key\s*=\s*['\"])、eval/exec 使用、以及裸 except: 子句。

階段 3:動態測試

針對性測試策略

動態測試應聚焦於 AI 最容易導入的漏洞類型:

SQL 注入:對清單中的端點 (含參數名) 發送常見 payload,例如 ' OR '1'='1、' OR '1'='1' --、1; DROP TABLE users --、' UNION SELECT NULL, username, password FROM users --、1' AND SLEEP(5) --。在回應中搜尋 syntax error、mysql_fetch、sqlite3.OperationalError、psycopg2.errors、ORA-、SQLSTATE 等錯誤訊息;若 payload 含 SLEEP 且回應時間超過 4 秒或請求逾時,視為時序盲注跡象。
XSS:對相同端點發送 <script>alert("XSS")</script>、<img src=x onerror=alert(1)>、" onmouseover="alert(1)"、javascript:alert(1)、<svg/onload=alert(1)>;若 payload 原樣回映於回應中即視為反射型 XSS。
認證繞過:對受保護端點嘗試多種繞過技巧 (無 Authorization 標頭、空的 Bearer、無效權杖、偽造 X-User-Role: admin 等),若傳回 200 OK 即視為繞過成功。

階段 4:組織面評估

成熟度模型

沿 CMMI 五級模型設定 AI 程式碼安全成熟度的五個面向:

工具治理:L1 無 AI 工具使用政策 → L2 非正式的已核可工具指引 → L3 附已核可工具清單的正式政策 → L4 由技術控制強制執行 → L5 持續評估新工具。
程式碼審查:L1 不區分 AI 與人類程式碼 → L2 意識到 AI 程式碼需額外審查 → L3 已文件化的 AI 程式碼審查清單 → L4 CI/CD 中自動化檢查 AI 模式 → L5 以指標驅動的持續改善。
開發者訓練:L1 無 AI 程式碼安全訓練 → L2 臨時性的意識宣導 → L3 針對 AI 工具使用者的正式訓練 → L4 定期訓練並評估 → L5 結合 AI 情境的威脅建模演練。
靜態分析:L1 無靜態分析 → L2 通用 SAST 但無 AI 專用規則 → L3 SAST 搭配 AI 專用規則集 → L4 依組織 AI 模式自訂規則 → L5 ML 增強的 AI 程式碼問題偵測。
事件回應:L1 無 AI 專用事件程序 → L2 AI 程式碼問題臨時處理 → L3 AI 程式碼事件已文件化手冊 → L4 以桌上演練落地手冊 → L5 自動化偵測與回應。

OWASP Code Review Guide — https://owasp.org/www-project-code-review-guide/
Semgrep Documentation — https://semgrep.dev/docs/
CodeQL Documentation — https://codeql.github.com/docs/
"Do Users Write More Insecure Code with AI Assistants?" — Perry et al., 2023 — https://arxiv.org/abs/2211.03622
OWASP Top 10 for LLM Applications 2025 — https://genai.owasp.org/llmrisk/
NIST AI Risk Management Framework — https://www.nist.gov/artificial-intelligence/ai-risk-management-framework
CWE Top 25 Most Dangerous Software Weaknesses — https://cwe.mitre.org/top25/

AI 生成程式碼的稽核方法論

概述

稽核框架概覽

階段模型

階段 1:AI 程式碼辨識

Git 歷史分析

開發者訪談指南

階段 2:靜態分析

AI 專用的 Semgrep 設定

執行靜態分析套件

階段 3:動態測試

針對性測試策略

階段 4:組織面評估

成熟度模型

階段 5:報告

報告範本

參考資料

AI 生成程式碼的稽核方法論

概述

稽核框架概覽

階段模型

階段 1:AI 程式碼辨識

Git 歷史分析

開發者訪談指南

階段 2:靜態分析

AI 專用的 Semgrep 設定

執行靜態分析套件

階段 3:動態測試

針對性測試策略

階段 4:組織面評估

成熟度模型

階段 5:報告

報告範本

參考資料

AI 生成程式碼的稽核方法論

相關文章

AI 生成程式碼的稽核方法論

相關文章