靜態程式碼分析在安全性的應用：SAST 如何應對 OWASP Top 10 漏洞

內部網路 2026 年 7 月 14 日代碼審查, 資料管理, 影響分析軟體, 技術專欄

安全漏洞的預防遠比修復容易。在程式碼審查中發現的 SQL 注入漏洞只需幾分鐘即可修復。而同樣的漏洞，如果是在安全漏洞發生後才發現，則需要數週的事件回應、監管調查和補救工作，再加上在此期間被竊取的資料。靜態程式碼分析的精髓在於，透過檢查原始碼結構、資料流和模式，並比對已知的漏洞特徵，在程式碼運行之前發現這些問題。有系統地應用靜態程式碼分析，可以將安全性從被動應對轉變為開發流程的內建屬性。

OWASP Top 10 是權威的 Web 應用程式安全風險目錄，由開放式 Web 應用程式安全專案 (OWASP) 基於數千個應用程式的真實漏洞資料進行更新。清單中的每一項都可以被靜態分析工具偵測到，只是偵測程度有所不同。本指南將每個 OWASP 類別與靜態分析可以發現的內容進行對應，顯示易受攻擊的程式碼模式及其安全等效程式碼，並解釋哪些工具應用了每種技術。

在攻擊者之前找到註入漏洞

SMART TS XL 追蹤從 JavaScript API 到 Java 服務再到 COBOL 後端的漏洞。

更多資訊

什麼是靜態應用程式安全測試 (SAST)？

靜態應用程式安全測試 (SAST) 無需執行程式即可分析原始程式碼、字節碼或二進位檔案。此分析會檢查資料在應用程式中的流動方式、資料到達的安全敏感操作，以及是否有任何來自外部輸入（使用者輸入、HTTP 參數、檔案內容、環境變數）的路徑，在未經適當驗證或清理的情況下，會導致危險操作（資料庫查詢、系統指令、HTML 輸出、加密函數）。

SAST 是完整應用程式安全方案中的一層。要了解它在安全方案中的作用，需要將其與其它方案進行比較：

途徑	當它運行時	它發現了什麼	它缺少什麼
SAST（靜態）	執行前，對原始程式碼進行處理	代碼級漏洞、注入模式、加密濫用、硬編碼金鑰	運行時漏洞、部署中的設定問題
DAST（動態）	針對正在運行的應用程式	運行時行為、身份驗證缺陷、伺服器配置問題	測試期間未觸發程式碼級模式
軟體成分分析 (SCA)	關於依賴清單	第三方函式庫中已知的 CVE 漏洞	自訂程式碼漏洞
IAST（互動式）	在測試執行期間使用儀器	運行時資料流具有高精度	需要運行應用程序，反饋速度較慢。

SAST 提供最早的回饋，它在漏洞到達測試環境之前，即可在尚未部署的程式碼上運行，無論是在 CI/CD 管線還是 IDE 中。這種早期性是其主要的安全價值所在。

靜態程式碼分析可以緩解哪些類型的威脅？

這是關於SAST（安全應用程式安全測試）搜尋量最高的問題之一。直接答案如下：

靜態程式碼分析可以緩解原始程式碼模式中存在的威脅，例如注入漏洞（SQL、命令、XSS）、加密濫用、硬編碼憑證、不安全的身份驗證實作、程式碼邏輯中失效的存取控制以及資料完整性故障。但它無法緩解運行時配置、網路拓撲或基礎設施設定中產生的威脅，這些威脅需要使用動態應用安全測試 (DAST)、滲透測試或基礎設施安全掃描。

OWASP覆蓋率的靜態分析與動態分析

動態測試 (DAST) 和靜態測試 (SAST) 分別針對 OWASP 漏洞的不同子集進行分析，兩者都無法涵蓋所有漏洞。 OWASP Web 安全測試指南 (WSTG) 是動態測試的方法論框架；而 CodeQL、Semgrep 和 SonarQube 等 SAST 工具則專注於原始碼層。

OWASP Top 10 類別	SAST覆蓋範圍	DAST覆蓋範圍
訪問控制損壞	部分程式碼邏輯漏洞	良好的運行時行為測試
加密失敗	強大的演算法檢測	虛弱，難以從外部觀察
注射	強烈的污染分析	強效、主動酬載測試
不安全的設計	部分模式檢測	較弱，需要設計知識
安全配置錯誤	部分，程式碼中的配置	強大的實戰環境測試
易受攻擊的組件	弱，SCA更好	弱，SCA更好
身份驗證失敗	部分硬編碼的信用，弱模式	強大的會話和身份驗證測試
資料完整性故障	部分反序列化模式	強度弱，難以從外部檢測
記錄失敗	部分或缺少的日誌語句	微弱、難以察覺的缺失
SSRF	強烈的、污染 HTTP 呼叫	強而有力的、主動的請求測試

結論：SAST 和 DAST 是互補的。為了獲得最大的 OWASP 覆蓋率，建議同時運行兩者。對於預算有限且從零開始的團隊，建議先運行 SAST，因為它能提供最快的開發人員回饋和最廣泛的注入攻擊覆蓋。

OWASP Top 10：靜態分析發現了什麼以及如何發現

A01，門禁控制故障

存取控制失效是 OWASP 風險清單中的首要風險。靜態分析主要針對程式碼層面的問題：例如函數和端點缺少授權檢查、物件引用未經驗證就暴露內部 ID，以及繞過預期權限結構的硬編碼角色分配。

靜態分析偵測到：處理敏感操作而沒有對應授權檢查的方法；物件 ID 來自使用者輸入而沒有存取驗證的直接物件參考；檢查了已驗證狀態但未檢查物件所有權的強制瀏覽模式。

Java的

// Vulnerable: no ownership check -- any authenticated user can access any order
@GetMapping("/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId) {
    return orderRepository.findById(orderId).orElseThrow();
}

// Secure: verify the order belongs to the requesting user
@GetMapping("/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId,
                      @AuthenticationPrincipal UserDetails user) {
    Order order = orderRepository.findById(orderId).orElseThrow();
    if (!order.getOwnerId().equals(user.getUserId())) {
        throw new AccessDeniedException("Order does not belong to requesting user");
    }
    return order;
}

靜態分析無法發現的問題：執行時間存取控制失效，即邏輯本身正確，但用於做出決策的資料已被洩露。這些問題需要透過動態存取控制測試 (DAST) 和滲透測試來解決。

A02，加密故障

弱加密可以透過靜態分析可靠地偵測出來，因為易受攻擊的模式（MD5、SHA-1、DES、ECB 模式、硬編碼金鑰）在原始碼中是詞法上可識別的。

蟒蛇

# Vulnerable: MD5 for password hashing (broken algorithm)
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()

# Vulnerable: hardcoded encryption key
KEY = b"mysecretkey12345"
cipher = AES.new(KEY, AES.MODE_ECB)  # ECB mode also vulnerable

# Secure: bcrypt for passwords, environment-sourced keys
import bcrypt, os
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

# Secure: AES-GCM with environment-sourced key
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
key = os.environ["ENCRYPTION_KEY"].encode()
aesgcm = AESGCM(key)

靜態分析規則標誌：出於安全敏感目的使用 MD5/SHA-1，DES/3DES/RC4/ECB 模式，硬編碼加密金鑰和秘密，敏感資料傳輸使用 HTTP 而不是 HTTPS，以及停用憑證驗證（verify=False 在 Python requests 中， setHostnameVerifier(ALLOW_ALL_HOSTNAME_VERIFIER) （在 Java 中）。

A03，注射

注入攻擊，包括 SQL 注入、作業系統指令注入、LDAP 注入、XSS 注入和範本注入，是過程間污點分析能夠發揮最直接價值的攻擊類別。這類漏洞需要追蹤不受信任的輸入，從其源頭到函數調用，最終到達危險的目標。

JavaScript的

// Vulnerable: direct string interpolation in SQL (SQL injection)
app.get('/users', async (req, res) => {
    const name = req.query.name;
    const result = await db.query(`SELECT * FROM users WHERE name = '${name}'`);
    res.json(result.rows);
});

// Secure: parameterized query
app.get('/users', async (req, res) => {
    const name = req.query.name;
    const result = await db.query('SELECT * FROM users WHERE name = $1', [name]);
    res.json(result.rows);
});

PHP

// Vulnerable: unescaped output (XSS)
echo "Welcome, " . $_GET['username'];

// Secure: context-appropriate escaping
echo "Welcome, " . htmlspecialchars($_GET['username'], ENT_QUOTES, 'UTF-8');

尖銳的

// Vulnerable: command injection in C#
var process = new Process();
process.StartInfo.FileName = "cmd.exe";
process.StartInfo.Arguments = "/c " + userInput;
process.Start();

// Secure: avoid shell interpretation, validate and whitelist inputs
var allowedCommands = new HashSet<string> { "report", "export" };
if (!allowedCommands.Contains(userInput))
    throw new ArgumentException("Invalid command");

用於執行過程間污點分析以偵測注入的工具：CodeQL（最精確）、帶有污點模式的 Semgrep、Snyk Code、帶有安全規則的 SonarQube。

A04，不安全設計

不安全設計是OWASP靜態分析中最難解決的類別，因為它涉及架構決策而非程式碼模式。靜態分析可以標示以下症狀：

驗證端點缺少速率限制邏輯、失敗嘗試後未鎖定帳戶、業務邏輯跳過驗證步驟，以及執行特權操作但未記錄稽核日誌的函數。這些問題可以透過缺失模式偵測出來，靜態分析報告的是缺少的內容，而不是已存在的內容。

某些 SAST 工具支援自訂規則，這些規則可以編碼組織的安全設計要求：例如，每個控制器方法都必須呼叫授權函數，每次資料庫寫入都必須先進行輸入驗證，每次外部 API 呼叫都必須設定逾時。這些自訂規則將設計要求轉換為可強制執行的程式碼約束。

A05，安全設定錯誤

程式碼中的安全配置錯誤包括：停用安全功能、寬鬆的 CORS 標頭、缺少安全回應標頭、在生產環境中啟用偵錯模式以及顯示堆疊追蹤的詳細錯誤訊息。

蟒蛇

# Vulnerable: Flask debug mode enables interactive debugger in production
app = Flask(__name__)
app.run(debug=True)  # exposes console access if error occurs

# Vulnerable: overly permissive CORS
from flask_cors import CORS
CORS(app, origins="*")  # allows any origin

# Secure: environment-controlled debug, restricted CORS
import os
debug_mode = os.environ.get("FLASK_DEBUG", "false").lower() == "true"
CORS(app, origins=os.environ.get("ALLOWED_ORIGINS", "").split(","))
app.run(debug=debug_mode)

靜態分析規則標誌：調試模式已設定為 True 來源設定存在通配符 CORS 來源、HTTP 回應設定中缺少安全標頭、SSL 憑證驗證已停用以及設定檔中使用了預設憑證等問題。

A06，易受攻擊和過時的組件

此類別主要透過軟體成分分析 (SCA) 而非傳統的軟體安全測試工具 (SAST) 來解決。 SCA 掃描 package.json, pom.xml, requirements.txt以及針對漏洞資料庫（國家漏洞資料庫、GitHub 安全漏洞資料庫）的類似清單。

SAST 透過識別已棄用的 API 用法、因安全缺陷而被取代的函式庫函數調用，或直接使用即使是最新函式庫也不再推薦的易受攻擊的模式來做出貢獻。

A06專用工具： npm audit, pip-audit, snyk test, OWASP Dependency-CheckGitHub Dependabot 和 Mend（原名 WhiteSource）。

A07，身分識別和認證失敗

靜態分析發現了代碼層級的身份驗證反模式：硬編碼密碼、弱密碼驗證、使用非加密隨機性產生的會話令牌、註銷時缺少會話失效機制，以及接受以下情況的 JWT 實現： none 算法。

JavaScript的

// Vulnerable: JWT accepting 'none' algorithm -- allows signature bypass
const decoded = jwt.verify(token, secret, { algorithms: ['HS256', 'none'] });

// Vulnerable: hardcoded admin credentials
if (username === 'admin' && password === 'admin123') {
    grantAccess();
}

// Secure: algorithm whitelist, no hardcoded credentials
const decoded = jwt.verify(token, process.env.JWT_SECRET, {
    algorithms: ['HS256']  // explicit allowlist only
});

尖銳的

// Vulnerable: weak random for session token generation in C#
var sessionToken = new Random().Next().ToString();

// Secure: cryptographically secure random
using var rng = RandomNumberGenerator.Create();
var bytes = new byte[32];
rng.GetBytes(bytes);
var sessionToken = Convert.ToBase64String(bytes);

A08，軟體和資料完整性故障

此類別涵蓋不安全的反序列化和未經驗證的軟體更新。靜態分析偵測到：Java ObjectInputStream 從不受信任的來源反序列化數據，Python pickle.loads() 關於外部數據，PHP unserialize() 使用使用者控制的輸入，以及使用不安全載入器的 YAML 解析器。

蟒蛇

# Vulnerable: pickle deserialization of untrusted data
import pickle
data = pickle.loads(request.data)  # arbitrary code execution risk

# Vulnerable: unsafe YAML loader
import yaml
config = yaml.load(user_input)  # yaml.load without Loader is unsafe

# Secure: safe alternatives
import json
data = json.loads(request.data)  # JSON cannot execute code

import yaml
config = yaml.safe_load(user_input)  # safe_load disables arbitrary object creation

A09，安全日誌記錄和監控故障

靜態分析可以透過偵測缺少的模式來識別日誌記錄失敗：敏感操作、驗證事件、存取控制決策、資料修改等事件，如果沒有對應的日誌語句記錄，則無法進行。靜態分析規則可以要求某些函數呼叫必須始終與稽核日誌呼叫同時發生。

靜態分析標記了以下問題：記錄密碼或令牌（記錄敏感資料也是一個漏洞）、靜默吞噬錯誤而不記錄日誌的異常處理程序，以及記錄原始異常訊息（其中可能包含敏感資料）的 catch 區塊。

Java的

// Vulnerable: swallowed exception, no logging
try {
    authenticateUser(username, password);
} catch (Exception e) {
    // silent failure -- no log, no audit trail
}

// Vulnerable: logging sensitive data
log.info("User logged in with password: " + password);

// Secure: log the event, not the credential
try {
    authenticateUser(username, password);
    auditLog.info("Authentication success for user: {}", username);
} catch (AuthenticationException e) {
    auditLog.warn("Authentication failure for user: {}", username);
    throw e;  // do not swallow
}

A10，伺服器端請求偽造（SSRF）

SSRF 是跨過程污點分析的典型案例。此漏洞需要追蹤使用者控制的輸入直至 HTTP 請求，通常需要多次函數呼叫。如果 URL 建置和 HTTP 呼叫位於不同的函數中，則僅分析單一函數的工具將無法偵測到 SSRF。

蟒蛇

# Vulnerable: user-controlled URL in HTTP request (SSRF)
import requests

def fetch_resource(url):
    return requests.get(url).content  # no validation

def api_endpoint(request):
    target = request.json().get("url")    # attacker controls this
    return fetch_resource(target)          # SSRF across function boundary

# Secure: allowlist validation before making the request
from urllib.parse import urlparse

ALLOWED_HOSTS = {"api.internal.example.com", "cdn.example.com"}

def fetch_resource(url: str) -> bytes:
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        raise ValueError(f"URL host not allowed: {parsed.hostname}")
    return requests.get(url, timeout=5).content

OWASP 安全靜態程式碼分析工具

下表將主要的 SAST 工具與其最有效解決的 OWASP 類別進行了對應：

工具	主要語言	OWASP優勢	途徑
代碼QL	Java、JS/TS、Python、C/C++、Go、Ruby	A03 注射，A10 SSRF（深層污染）	程式間語意分析
塞姆格雷普	超過30種語言	A03、A02、A07（基於模式+污點模式）	模式匹配 + 淺層污漬
Snyk 程式碼	Java、JS/TS、Python、C#	A03，A07，A08	基於機器學習的污點分析
聲納	超過30種語言	A02，A03，A05，A07，A09	基於規則 + 資料流
校驗碼	超過30種語言	OWASP 全面覆蓋	程式間污染
代碼	Java、.NET、JS、PHP	OWASP 全面覆蓋	字節碼 + 污點分析
OWASP ZAP	與語言無關	A01、A05、A07（運行時）	DAST，動態測試
SMART TS XL	COBOL、JCL、Java、Python、RPG、SQL	跨語言污染，依賴風險	跨語言結構 + 污點

SMART TS XL 解決企業程式碼庫中的安全性問題

企業安全程式面臨單語言靜態應用安全測試工具 (SAST) 無法解決的挑戰：攻擊面跨越多種語言。例如，一個 Web 應用程式可能接受 JavaScript 使用者輸入，用 Java 處理輸入，然後透過訊息佇列將其傳遞給 COBOL 程序，最終針對 DB2 資料庫執行 SQL 查詢。注入漏洞跨越了四種語言邊界。任何單一語言的掃描器都無法捕捉完整的污染路徑。

SMART TS XL“ 靜態程式碼分析同時涵蓋此鏈中的所有語言。當不受信任的輸入從 JavaScript API 處理程序經由 Java 服務流入建構動態 SQL 查詢的 COBOL 程式時， SMART TS XL 它會在整個跨語言呼叫圖中追蹤該路徑，這與 CodeQL 在 Java 中應用的跨過程污點追蹤相同，並同時應用於 Java、COBOL 和 SQL。

應用程式依賴關係映射功能提供了與安全相關的視圖，展示了系統中哪些元件與外部輸入互動、哪些元件可以執行特權操作，以及系統的完整攻擊面究竟是什麼樣子。這種架構安全視圖是威脅建模的基礎，您無法對一個您不了解其結構的系統進行威脅建模。

影響分析功能為安全性修復程式提供支援：當某個元件中發現漏洞時，影響分析會識別所有依賴該漏洞元件的其他元件，從而在修改任何程式碼之前準確確定修復範圍。對於大型遺留程式碼庫而言，如果一個存在安全漏洞的 COBOL 程式被數百個其他程式引用，那麼在開始修復之前了解完整的修復範圍，是成功修復和避免安全事件級聯爆發之間的關鍵區別。

對於管理的組織遺產現代化對遺留程式碼庫進行安全分析是前提條件，而非事後考慮。將存在漏洞的 COBOL 程式遷移到 Java 會產生存在漏洞的 Java 程式。 SMART TS XL的安全分析確保漏洞在現代化過程中被識別和修復，而不是在遷移後的系統中發現。

將SAST整合到開發生命週期中

靜態安全分析在決策點（即程式碼編寫和審查階段）運行才能發揮其最大價值，而不是在部署之後運行。

在整合開發環境 (IDE) 中： SonarLint、Snyk 的 IDE 擴充功能和 CodeQL 的 VS Code 擴充功能會在開發者編寫程式碼時直接顯示漏洞資訊。例如，開發者一旦輸入有漏洞的 SQL 注入模式，就會立即顯示相應的警告訊息，而修復這些警告訊息只需幾秒鐘。

在拉取請求中：整合到 GitHub Actions、GitLab CI 或 Jenkins 中的 SAST 會在每個拉取請求上運行，並將發現的問題以內聯程式碼審查註解的形式發布。開發人員可以在上下文中看到發現的問題以及導致問題的程式碼。

作為品質把關： SonarQube 的品質把關模型會在引入新的關鍵安全漏洞時阻止合併。這使得安全性不再是可選項，而是合併流程的結構性要求。

按計畫進行：深度過程間分析、CodeQL、Checkmarx、完整的Semgrep規則集，通常對於每次提交執行來說速度太慢，但會在主分支上每晚或每週運行，以發現需要完整調用圖分析才能檢測到的漏洞。

分層方法，在 IDE 和提交中快速應用基於模式的規則，對拉取請求和夜間版本進行深度污點分析，既滿足了開發人員所需的即時性，又滿足了安全程序所需的徹底性。