程式漏洞? 為什麼需要源碼檢測?

程式漏洞都是怎麼造成的?為什麼企業需要源碼檢測? 漏洞是指因為產品開發人員無意間製造了產品弱點而導致的安全性風險。根據國際資安標準 SANS / CWE TOP25 ( 前 25 大最危險的程式設計錯誤 )、OWASP TOP 10前十大漏洞。

2023 SANS / CWE TOP 25 ( 前 25 大最危險的程式設計錯誤 ) 根據名次排名且標註出漏洞編號

第 01 名 CWE-787 Out-of-bounds Write 記憶體越界寫入

第 02 名 CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') 跨網站腳本攻擊

第 03 名 CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') 不當摧毀SQL指令中使用的特殊元素（SQL 注入）

第 04 名 CWE-416 Use After Free 使用已釋放記憶體

第 05 名 CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') 不當摧毀作業系統指令中使用的特殊元素（作業系統指令注入）

第 06 名 CWE-20 Improper Input Validation 不正確的輸入驗證

第 07 名 CWE-125 Out-of-bounds Read 記憶體越界讀取

第 08 名 CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')不當限制受限目錄的路徑名稱（路徑遍訪）

第 09 名 CWE-352 Cross-Site Request Forgery ( CSRF ) 偽造跨網站要求 ( CSRF )

第 10 名 CWE-434 Unrestricted Upload of File with Dangerous Type 未限定上傳危險類型的檔案

第 11 名 CWE-862 Missing Authorization 缺少授權檢查

第 12 名 CWE-476 NULL Pointer Dereference 引用空指標

第 13 名 CWE-287 Improper Authentication 不當的身分驗證

第 14 名 CWE-190 Integer Overflow or Wraparound 整數溢位或負數

第 15 名 CWE-502 Deserialization of Untrusted Data 對不受信任資料進行反序列化

第 16 名 CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection') 命令指令注入攻擊

第 17 名 CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer 記憶體緩衝區內不當的操作限制

第 18 名 CWE-798 Use of Hard-coded Credentials 使用寫死固定的憑證

第 19 名 CWE-918 Server-Side Request Forgery (SSRF) Server 請求偽冒

第 20 名 CWE-306 Missing Authentication for Critical Function重要功能缺少身分驗證

第 21 名 CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') 資源競爭

第 22 名 CWE-269 Improper Privilege Management 未妥善指定、修改、追蹤及檢查操作者的權限

第 23 名 CWE-94 Improper Control of Generation of Code ('Code Injection') 程式碼注入攻擊

第 24 名 CWE-863 Incorrect Authorization 不正確的授權

第 25 名 CWE-276 Incorrect Default Permissions 不正確的預設權限

數據來源 : https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html

OWASP Top 10 公布的 2021 年前 10 大漏洞

第 01 名 2021-Broken Access Control 權限控制失效

第 02 名 2021-Cryptogrphic Failures 加密機制失效

第 03 名 2021- Injection 注入式攻擊

第 04 名 2021-Insecure Design 不安全設計

第 05 名 2021- Security Misconfiguration 安全設定缺陷

第 06 名 2021-Vulnerable and Outdated Components 危險或過舊的元件

第 07 名 2021-Identification and Authentication Failures 認證及驗證機制失效

第 08 名 2021-Software and Data Integrity Failures 軟體及資料完整性失效

第 09 名 2021-Security Logging and Monitoring Failures 資安記錄及監控失效

第 10 名 2021-Server-Side Request Forgery ( SSRF ) 伺服端請求偽造

SSDLC 如何解決安全問題？

傳統在軟體開發時，安全測試是獨立於軟體開發生命週期 ( SDLC )的一個流程。在建置軟體後才發現安全漏洞。導致有很多隱藏的錯誤，出現更多的安全問題。

SSDLC 指的是 ( Secure Software Development Life Cycle )，SSDLC 強調如何將安全納入軟體開發生命週期各階段，軟體開發過程的每個階段安全測試，進行各項必要的安全防護措施。SSDLC 成為軟體專案開發主流，讓開發人員在開發時每一階段增加資安防護力。
而源碼檢測工具在軟體開發週期的每一個階段提供完整的軟體安全測試及管理，著重的防護在安全開發、安全測試、持續監控。

另外，第三方開源檢測（Software Bill of Materials，SBOM）也稱為軟體元件清單。SBOM 是一份清單，包含軟體元件的來源、版本、許可證資訊、漏洞資訊等。用來追蹤檢視開源套件安全問題，確保該軟體的安全性、合規性和風險。以 SBOM 管理軟體安全，並落實 SSDLC 軟體開發生命週期。

圖片出處:https://statusneo.com/tag/5-phases-of-secure-sdlc/

用安全檢測貫穿軟體開發之 CI / CD 流程

如何實現企業 CI/CD 自動化，並將 CI/CD 導入資安，用安全檢測，這一章節將詳細說明。首先，先了解什麼是 CI/CD ，指的是 CI ( Continuous integration ) 即是「持續整合」；CD ( Continuous Deployment )，即是「持續佈署」。

CI/CD 通常遵循著以下流程

CI 流程包含:功能設計（Design）→開發→CI 測試 ( CI tests )→程式碼審查（Code Review）→最後合併（Merge）程式碼。則 CD 流程包含在測試環境中部署、進行測試、最後才會 release 將產品上線。

將資安部分融入 CI/CD

Fortify 源碼檢測 Fortify Static Code Analyzer 弱點掃描檢測，SAST 實現企業 CI/CD。以下流程圖為將資安部分融入 CI/CD。

參考資料來源 : 白帽觀點 https://secview.io/posts/9-ci-cd/
( 內容已取得文章原作同意使用 )

CI 部分

如何在 CI 導入資安，主要著重於「系統設計」和「程式碼檢測」兩個部分

資安系統架構設計（Security Architechture Design）:比如說當開發軟體前的功能設計和系統設計，需要被考慮「存取控制（Access Control）」和「機密資訊管理（Secret Management）」
運行時自我保護（RASP，Runtime Application Self Protection）:RASP用於軟體開發正式上線之後，在執行時期提供即時保護。
靜態應用程式安全測試（靜態測試，SAST，Static Application Security Testing）
資安程式碼審查（Security Code Review）