top of page
debow discovery_工作區域 1_edited.png
熱門文章
搜尋

【案例分享】AI 寫程式缺獨立驗證？技術主管如何用 SonarQube 控管資安風險

  • 作家相片: Devops Tec.
    Devops Tec.
  • 2天前
  • 讀畢需時 7 分鐘
SonarQube

在過去一年裡，我們的顧問團隊走訪了超過十多家台灣企業——製造業、金融科技、生技、電商——幾乎每一場評估會議，都會有一位工程師或技術主管說出同一句話：

「我們有在用 AI 寫程式，但我都有提醒它注意 OWASP TOP 10，叫它自己檢查漏洞，應該沒問題吧？」


我們的回答從來不是「你做得不對」。因為你說的是真的——有提示，確實比沒提示更安全。

但在我們正式進行 SonarQube 初次掃描之後，這句話通常會變成：

「怎麼會有這麼多問題……」


以下是三個真實導入場景，每一個客戶在導入前都認為自己的提示詞已經足夠嚴謹。



案例一：Claude 照規則做了，但做錯了方向

｜金融科技業客戶｜150 人工程團隊｜


事件描述

這家客戶的技術主管非常重視資安。他們的 Claude 提示模板明確要求：

「請實作支付 API，遵守 OWASP TOP 10，特別注意 A03 注入風險，禁止把任何外部輸入直接拼成可執行邏輯如 :eval，避免未知第三方套件。」


Claude 完全照做——沒有 eval、套件選擇正確、邏輯清晰，產出了這段javascript程式碼：

const stripe = require('stripe')(process.env.STRIPE_KEY);

app.post('/pay', async (req, res) => {
  try {
    const charge = await stripe.charges.create({
      amount: req.body.amount,
      currency: 'twd',
      source: req.body.token,
    });
    res.json({ success: true, id: charge.id });
  } catch (err) {
    res.status(500).json({ error: err.message }); // ← 問題在這裡
  }
});

你看出問題了嗎？他們的技術主管沒看出來，Claude 也沒有。


err.message 在 Stripe SDK 中，包含了卡號後四碼、交易金額、部分客戶 ID。 這直接違反了 PCI DSS 合規要求——任何人只要刻意讓一筆交易失敗，就能從回應中收集到敏感金融資訊。


為什麼強提示詞沒攔查到這裡？

提示詞說的是「注意 OWASP A03 注入」，Claude 確實做到了。但它不知道：

  • 這家公司需要符合 PCI DSS Level 1

  • Stripe SDK 的 err.message 欄位有特殊的資料洩漏特性

  • 台灣金管會對金融 API 錯誤回應的規範要求

你沒說的、Claude 不知道貴司的業務脈絡，提示詞永遠覆蓋不完。


SonarQube 實際攔截方式

我們為這家客戶載入 PCI DSS 合規規則集（SonarQube 內建合規框架，支援 PCI DSS、ISO 27001、OWASP ASVS）。從第一次 commit 開始，任何在錯誤回應中暴露敏感欄位的程式碼，都會被自動標記為 Security Hotspot，強制資安人員審查後才能合併。

這套規則不需要任何工程師記得下提示詞，它是平台層級的永久標準。


📊 導入成效：初次全專案掃描發現 47 個安全相關問題，其中 12 個為 Critical 等級，全部在進入 production 前修復完畢。



案例二：Claude 自主審查了——但它審查的是它自己寫的東西

｜電商平台業客戶｜雲端基礎建設團隊｜


事件描述

這位技術負責人更進一步，設計了「雙重保險」提示：

「請實作 AWS S3 上傳功能。完成後，請自主審查你的程式碼，確認沒有 OWASP TOP 10 漏洞，特別注意 A01 存取控制與 A05 安全設定錯誤。」


Claude 盡職地進行了自主審查，並回覆：

「我已完成安全審查，存取控制使用 IAM Role，符合最小權限原則，未發現 OWASP TOP 10 漏洞。」


產出的Python程式碼如下：

import boto3

s3 = boto3.client('s3')

def upload_file(file, filename):
    s3.upload_fileobj(
        file,
        'company-prod-bucket',            # ← Bucket 名稱 hardcoded
        filename,                         # ← 使用者輸入直接作為 key
        ExtraArgs={'ACL': 'public-read'}  # ← 所有上傳檔案公開可讀
    )

ACL: public-read 代表任何人都能用 URL 直接存取公司 S3 bucket 的所有上傳檔案。 使用者輸入的 filename 未經清洗，攻擊者可使用路徑穿越（../../etc/passwd）存取不該存取的路徑。

Claude 說它審查過了，但它找不到這個問題。


為什麼「請它自主審查」不夠？

這裡有一個根本性的邏輯困境，我們在每一場客戶說明會都會直接點出：

Claude 的盲點，在生成時就存在；在它自己審查時，同樣存在。

Claude 認為 public-read 是合法的 AWS ACL 選項（它確實是）。但它不知道你們公司的 AWS 安全政策規定所有物件必須為 Private，不知道你的資料分類標準，不知道這個 bucket 裡存的是什麼等級的資料。

自主審查能找到的，是「它已經知道是錯的東西」。但企業環境中最危險的漏洞，往往是在你們的業務脈絡下才是錯的。


SonarQube 實際攔截方式

SonarQube 的 IaC（基礎設施即程式碼）掃描同步執行三條規則：

規則

對應問題

嚴重程度

python:S6249

S3 bucket 設定 public-read

🔴 Critical

python:S2083

使用者輸入直接作為路徑

🔴 Critical

secrets:S6290

Bucket 名稱 hardcoded

🟠 Major


三個問題在第一次 push 即全數標記，Quality Gate 自動阻擋 PR 合併，不需要任何人記得要審查這段程式碼。


📊 導入成效：這家客戶在導入後三個月，S3 相關設定錯誤事件歸零，並順利通過年度 ISO 27001 複評。



案例三：提示詞有效——但只對今天、這位工程師有效

｜製造業客戶｜跨國研發中心｜台灣 + 越南雙據點｜


事件描述

這個案例最具代表性。資深工程師 Alex 是公司裡最嚴謹的人，他花了兩週設計出一份公認最完整的資安提示詞模板：

你是一位資深資安工程師，請在生成程式碼時遵守：
1. OWASP TOP 10 (2021)
2. 特別注意 CWE-79 (XSS)、CWE-89 (SQL Injection)、CWE-798 (Hardcoded Credentials)
3. 完成後執行完整資安審查清單
4. 如有任何安全疑慮，主動說明

這份模板效果顯著，Alex 負責的模組確實更安全了。


但六個月後，我們進場評估時發現：

🔴 越南據點的外包工程師完全不知道這份模板存在

🔴 三位新進工程師沒有人交接提示詞使用習慣

🟠 有兩位工程師知道要用，但在趕版本時忘記貼上

🔴 Alex 三個月前離職了


這個問題的正式名稱是：「資安品質依賴個人習慣，而非系統保障」——這是台灣中型企業最普遍、也最難用管理手段解決的問題。


SonarQube 實際攔截方式

SonarQube 的保護機制與任何人的習慣、記憶、提示詞完全無關：

情境

強提示詞方案

SonarQube Enterprise

新進工程師

❌ 需要有人交接提示詞文化

✅ 入職第一天自動掃描

趕版本忘記貼提示

❌ 這次沒有資安保護

✅ 每次 commit 強制執行

越南外包團隊

❌ 無法控制他們的提示詞

✅ 他們的 PR 一樣要過 Quality Gate

核心人員離職

❌ 資安文化隨人消失

✅ 規則永久存在於平台

年度合規稽核

❌ 無法提供量化掃描證據

✅ 每次掃描均有完整報告可匯出


📊 導入成效：這家客戶導入後，跨團隊程式碼品質一致性評分從 43 分提升至 89 分（滿分 100），越南據點與台灣本部的漏洞密度差距從 3.2 倍縮小至 1.1 倍。


直接回應「強提示詞派」的三個核心質疑

在每一場企業說明會，我們都會主動提出這三個問題，並當場回答：


Q1：「我的提示詞已經涵蓋了完整的 OWASP TOP 10，這樣還不夠嗎？」

OWASP TOP 10 是框架性的風險分類，而您的企業有特定的業務合規要求——台灣金管會法規、PCI DSS、ISO 27001、個資法——這些不在 OWASP 範圍內，Claude 不知道，你的提示詞也很難全部覆蓋。

SonarQube 的合規規則集是由 Sonar 法務與資安團隊持續維護的，涵蓋超過 10 種國際合規標準，且每季更新以對應最新法規變動。


Q2：「我請Claude 自主審查，它自己說沒問題，這樣我能信任嗎？」

我們的回答是一個反問：你會讓同一個人既寫報告、又審查自己的報告嗎？

Claude 的認知框架在生成時就決定了，審查時用的是同一套框架。SonarQube 是一個完全獨立的靜態分析引擎，它不理解你的提示詞、不受 AI 信心影響、不會因為程式碼「看起來合理」就放行。它只看規則。


Q3：「我們團隊紀律很好，每次都會用提示詞，真的需要額外投資 SonarQube 嗎？」

「紀律」是人的狀態，它會受疲勞、時間壓力、人員流動影響。「系統機制」是平台的設計，它不會疲勞、不會忘記、不會因為趕 deadline 就跳過。

我們在台灣服務過的客戶中，沒有一家在初次導入掃描時零發現。即使是最嚴謹的團隊，平均也發現 20–40 個以上的安全相關問題。



建議的導入路線圖（60 天快速啟動）

根據我們在台灣的實際導入經驗，以下是最有效的三階段方案：


第一週｜建立現況基礎

SonarQube 安裝 → 接入 GitLab / GitHub / Bitbucket
→ 執行第一次全專案掃描 → 產出「技術債現況報告」

這份報告是推動內部資源核准最有力的工具。我們協助客戶在第一週內完成這個步驟。


第二至四週｜啟動 CI/CD 守門機制

  • 設定 Quality Gate：新程式碼覆蓋率 ≥ 80%、Critical 漏洞 = 0

  • 啟用 PR Decoration：在 PR 頁面直接標示問題行，開發者不需離開平台

  • 部署 SonarQube IDE Plugin：每位工程師於本機即時掃描，在 commit 前就發現問題


第五至八週｜制度化與 AI 整合

  • 建立企業 Quality Profile：把公司合規要求、內部架構規範轉化為自訂規則集

  • 啟用 AI Code Assurance：針對 Claude / GitHub Copilot 生成的程式碼啟用專屬標記與追蹤

  • 整合 SonarQube MCP Server（2025 新功能）：讓 Claude 在生成程式碼時即時查詢 SonarQube 規則，實現 AI 生成 → 自動掃描 → 回饋修正的完整循環步驟

企業60天的SonarQube建議導入藍圖
企業60天的SonarQube建議導入藍圖

顧問結語

在這一年裡，我們見過太多台灣工程團隊因為相信「我有提示詞就夠了」而付出代價——有的是上線前夕被稽核打回票，有的是資安事件發生後才緊急導入，有的是因為核心人員離職而讓好不容易建立的資安文化瞬間歸零。


我們不是要說提示詞沒有價值，提示詞讓 Claude 更努力往對的方向走，但 SonarQube 確保它真的走到了。


一個沒有獨立驗證機制的 AI 開發流程，就像一間食品工廠只告訴廚師「要注意衛生」，但省掉了出貨前的品管檢驗。廚師再用心，出貨標準依然是不穩定的——因為標準存在於人心，而不是系統之中。

真正的企業級品質保證，是把標準寫進系統，而不是寫進提示詞。


如需安排 SonarQube 免費初次掃描評估，或取得台灣在地導入案例參考，歡迎與我們的顧問團隊聯繫！








留言

bottom of page