SAST (Static Application Security Testing) 就是靜態應用程式安全測試。
想像一下，你寫了一個程式，但還沒有實際執行它。
SAST 工具就像是一個很厲害的「程式碼檢查員」，
它會先讀你的程式碼,然後幫你找出可能有安全問題的地方。
舉個生活例子:
- 這就像是請一個建築檢查員在房子蓋好之前，先看你的設計圖
- 他會說:「喂!這個地方的樑太細了可能會塌」或「這扇窗戶設計得不夠安全，小偷很容易爬進來」
SAST 工具也是這樣:
- 它會找出像是「這裡的密碼存法不夠安全」
- 或是「這段程式碼可能會被壞人利用來攻擊」
- 甚至「這裡可能會洩漏使用者的個人資料」
最棒的是:
- 不用真的執行程式就能找到問題
- 很早就能發現並修正問題，省時又省錢
- 電腦自動檢查，不會漏掉細節
現在做雲端開發，應用程式的安全性絕對是首要考量。
SAST 工具可以幫助開發人員在程式碼撰寫階段就檢查出安全漏洞。
但目前 Google Cloud Platform（GCP）並沒有原生的 SAST 工具可用。
這篇文章會帶您了解 SAST 工具的需求，分析 GCP 上的現有選擇，
並介紹幾款受歡迎的第三方 SAST 工具，幫助您在 GCP 上維護應用程式的高安全性。
原生 SAST 工具的意義與需求
SAST 工具的重要性
SAST 工具的重點就是，它能夠在開發階段就找出程式碼中的安全漏洞。
可以降低修復成本和風險，讓程式碼在上線之前就經過嚴格檢查，這樣就更放心了。
如何區分 SAST、DAST 及其他安全工具
SAST（靜態應用安全測試）跟 DAST（動態應用安全測試）不同。
SAST 是針對靜態程式碼的分析，檢查程式碼本身的安全性；
DAST 則是針對執行中的應用程式進行檢測，也就是測試已經在運行的環境中的漏洞。
兩者通常搭配使用，可以提供更全面的保護。
GCP 中的原生靜態應用安全測試現狀
GCP 有提供原生 SAST 工具嗎？
目前 GCP 並沒有真正的原生 SAST 工具。
雖然 GCP 提供了 Web Security Scanner，
但這主要是針對線上運行中的網頁應用程式進行掃描，
並非針對程式碼進行靜態分析。
簡單說，Web Security Scanner 無法檢查程式碼本身的問題，
只能掃描已經上線的應用程式。
所以，想要進行靜態安全測試的話，這個工具不太適合。
所以，如果想在 GCP 上進行 SAST，還是得考慮第三方工具。
常用的第三方 SAST 工具推薦
SonarQube：企業級的程式碼安全解決方案
SonarQube 是一款開源的程式碼檢查工具，支援多種程式語言。
它可以自動掃描程式碼中的潛在問題，並產生詳細的報告。
SonarQube 特別適合需要長期進行靜態檢查的企業，
可以透過 Docker 容器版本與 GCP 整合，輕鬆加入 CI/CD 流程。
詳細教學可以參考這篇文章。
Snyk 與 GitHub Code Scanning：專業與整合的選擇
Snyk 是一款注重檢查開源程式庫與容器安全的工具，詳細教學可以參考這篇文章。
而 GitHub Code Scanning 支援 SAST 功能，特別適合與 GitHub Actions 整合。
這兩個工具對於那些已經在 GitHub 上開發的團隊特別實用。
NeuVector：補充 Docker Image 漏洞的工具
NeuVector 專門針對 Docker Image 中的漏洞進行檢查。
對於需要更細緻的 Docker Image 分析需求，NeuVector 能彌補 SonarQube 等傳統 SAST 工具在這方面的不足。
如何在 GCP 上整合第三方 SAST 工具
使用 Cloud Build 搭配 SAST 工具
GCP 的 Cloud Build 支持許多第三方工具的整合，包括 SAST 工具。
可以在 Cloud Build 配置檔案中加入 SonarQube 或 Snyk 的步驟，
讓每次提交程式碼後自動進行靜態分析，確保程式碼的品質和安全性。
網上有篇很棒的文章可以參考《Cloud Build- 使用 private connect 進行 Sonarqube 原始碼檢測》。
設定排程掃描與自動化安全檢查
每次 CI 觸發的掃描流程
在 CI/CD 流程中，建議在每次程式碼提交時自動執行 SAST 工具。這樣一來，每段新程式碼的安全性都能即時得到保障，減少安全風險。
每日或每月的排程掃描建議
對於那些已經不再頻繁更新的應用程式，建議可以設定每日或每月的定期掃描，以檢查是否有新的安全漏洞。
這樣就不怕遺漏更新時會有風險。
雲端環境下程式碼安全的未來發展方向
AI 驅動的安全檢測技術
隨著 AI 技術的發展，未來的 SAST 工具可能會更加智能化，具備自我學習和預測潛在漏洞的功能。
這將使得程式碼的分析更精準，有助於提早發現問題。
自動化與持續整合安全掃描的趨勢
隨著 DevOps 的推廣，未來安全掃描將無縫整合至開發流程中，成為每次程式碼提交時的基本步驟。
這種自動化的安全檢測方式將能顯著提升應用程式的整體安全水準。
結論
雖然 GCP 沒有內建的 SAST 工具，但通過搭配第三方工具（如 SonarQube、Snyk 等），
並與 GCP 的 Cloud Build 整合，可以實現高效的程式碼安全檢查。
隨著技術進步，未來的 SAST 工具將更加自動化和智能化。
我們建議依據團隊需求選擇合適的工具，並設定自動化安全檢查流程，以因應不斷變化的安全需求。
常見問題解答（FAQ）
- GCP 有原生的 SAST 工具嗎？ 目前 GCP 沒有提供原生 SAST 工具，但可以整合第三方工具來實現靜態安全檢查。
- GCP 的 Web Security Scanner 可以當作 SAST 工具使用嗎？ 不行，Web Security Scanner 屬於 DAST 工具，僅能檢查運行中的應用程式，而不是程式碼本身的安全性。
- 哪些 SAST 工具適合在 GCP 上使用？ 推薦 SonarQube、Snyk 和 GitHub Code Scanning 等，都可以方便地整合至 GCP。
- 應該多久進行一次 SAST 掃描？ 針對頻繁更新的專案，建議每次 CI/CD 執行時觸發 SAST；而不常更新的應用程式則可設定每日或每月掃描。
- SAST 與 DAST 可以同時使用嗎？ 可以，SAST 和 DAST 的搭配使用可以提供更全面的安全保障，適合對安全性要求較高的項目。
以上文章感謝各位網友參與討論，才能整理成上述完整的內容！