top of page
搜尋

【SonarQube 顧問實戰分享】我請 Claude 注意資安了，程式碼應該沒問題吧？

  • 作家相片: Linktech
    Linktech
  • 1天前
  • 讀畢需時 4 分鐘

在過去一年走訪超過三十家台灣企業 — 製造業、金融科技、電商、生技，幾乎每一場技術評估會議，都會有一位工程師或技術主管說出同一句話：「我們有在用 AI 寫程式，但我都有提醒它注意 OWASP TOP 10，叫它自己檢查漏洞，應該沒問題吧？」

每次聽到這句話，我們都忍不住在心裡捏一把冷汗，不是因為這句話說錯了。有提示，確實比沒提示更安全，這是事實。 但在我們實際執行 SonarQube 初次掃描之後，這句話通常會變成：「怎麼會有這麼多問題……」以下兩個案例，每一位客戶在導入前都認為自己的提示詞已經足夠嚴謹。


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

📌 場景

這家金融科技客戶的技術主管非常重視資安，他們的 Claude 提示明確要求：

「請實作支付 API，遵守 OWASP TOP 10，特別注意 A03 注入風險，禁止使用 eval，避免未知第三方套件。」

Claude 完全照做，沒有 eval、套件選擇正確、邏輯清晰，產出了這段乍看無懈可擊的程式碼：

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 錯誤回應的規範要求


✅ SonarQube 如何把關

載入 PCI DSS 合規規則集後，任何在錯誤回應中暴露敏感欄位的程式碼，都會被自動標記為 Security Hotspot，強制資安人員審查後才能合併。這套規則不需要任何工程師記得下提示詞，它是平台層級的永久標準，不因人員異動而消失。


📊 導入成效：初次全專案掃描發現 47 個安全問題，其中 12 個 Critical 等級，全數在進入正式環境前修復完畢。

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

📌 場景

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

「請實作 AWS S3 上傳功能，完成後請自主審查，確認沒有 OWASP A01 存取控制與 A05 安全設定錯誤。」

Claude 非常盡職，生成程式碼後真的進行了自主審查，並回覆：

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

但產出的程式碼是這樣：

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 裡的所有上傳檔案。 使用者輸入的 filename 未經過濾，攻擊者可利用路徑穿越手法（../../etc/passwd）存取不該碰的資料。

Claude 說它審查過了，但沒發現這些問題。


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

這裡有一個根本性的邏輯問題：Claude 的盲點在生成時就存在，在它自主審查時用的是同一套認知框架，一樣看不到。

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

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


｜✅ SonarQube 如何把關

三條 IaC 規則同時觸發，第一次 push 即全數標記，Quality Gate 自動擋下 PR 合併：

規則

對應問題

嚴重程度

python:S6249

S3 設定 public-read

🔴 Critical

python:S2083

使用者輸入直接作為路徑

🔴 Critical

secrets:S6290

Bucket 名稱寫死在程式碼中

🟠 Major

📊 導入成效：導入後三個月 S3 安全設定錯誤事件歸零，順利通過年度 ISO 27001 複評。

提示詞與 SonarQube 的正確分工，這兩個案例說明了同一件事：

強提示詞 + OWASP 要求  →  提升 Claude 的努力方向
SonarQube Quality Gate →  驗證實際結果是否達標

就像食品工廠，你告訴廚師要注意衛生法規，廚師會更謹慎，但你還是需要出貨前的品管檢驗，因為謹慎的意圖不等於每批都安全的事實。真正的企業級品質保證，是把標準寫進系統，而不是寫進提示詞。


｜想進一步了解？友環企業提供免費健診評估

SonarQube Quality Gate 才是確保程式碼安全的實質品管；真正的企業級安全，必須把標準寫進系統而非提示詞。想精準掌握專案的風險基線？SonarSource 台灣官方代理商友環企業Linktech 現正提供免費初次健診掃描服務！我們將為您的現有專案執行完整掃描並產出「技術債現況報告」，再由專業顧問進行一對一解說，助您輕鬆落實自動化的 DevSecOps 企業防線。


Linktech 友環企業 團隊洽詢方式：



留言

bottom of page