[AppSec] How to start an AppSec Program with the OWASP Top 10 translation

https://owasp.org/Top10/zh_TW/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10/

如何用OWASP前十大開始應用程式安全計畫

過去，OWASP前十大從未被設計成應用程式安全（AppSec）計畫的基礎。然而，對於剛開始應用程式安全旅程的許多組織來說，總得有個起點。2021年版的OWASP前十大是一個不錯的起點，可以作為基線或檢查表，但它本身並不足夠。

階段1：識別AppSec計畫的差距和目標

許多應用程式安全（AppSec）計畫在學會爬行或行走之前就試圖奔跑，這些努力注定會失敗。我們強烈建議CISO（首席資訊安全官）和AppSec領導者使用OWASP軟體保證成熟度模型（SAMM）來在1到3年期間識別弱點和改善區域。第一步是評估當前狀況，識別在治理、設計、實施、驗證和運營中的差距，確定哪些需要立即解決，哪些可以延後處理，並優先實施或改善OWASP SAMM的15個安全實踐。OWASP SAMM可以幫助您在軟體保證工作中建立和衡量改進。

階段2：計畫安全開發生命週期的鋪設之路

傳統上，"鋪設之路"概念是所謂“獨角獸”企業的專有領域，但它是最容易產生影響且能隨開發團隊速度擴展AppSec資源的方式，而開發速度每年都在增加。

鋪設之路的概念是“最簡單的方式也是最安全的方式”，應包括開發團隊與安全團隊之間的深度合作文化，最好是開發和安全團隊融為一體。鋪設之路旨在不斷改進、衡量、檢測並替換不安全的選擇，通過建立企業級的安全替代方案庫，並提供工具幫助確定可以採用鋪設之路改進的地方。這讓現有的開發工具能夠報告不安全的構建，並幫助開發團隊自我糾正不安全的選擇。

鋪設之路看似繁瑣，但應該隨時間逐步建設。還有其他形式的AppSec計畫，例如Microsoft Agile Secure Development Lifecycle。並非每種AppSec計畫方法都適合所有企業。

階段3：與開發團隊共同實施鋪設之路

鋪設之路的建設需要相關的開發和運營團隊的同意和直接參與。鋪設之路應與業務戰略保持一致，並幫助更快速地交付更安全的應用程式。開發鋪設之路應該是一個涵蓋整個企業或應用生態系統的全面工作，而不是像以往那樣的每個應用的權宜之計。

階段4：將所有即將推出和現有的應用程式遷移到鋪設之路

在開發鋪設之路檢測工具時，提供給開發團隊的資訊應該能夠改善他們的應用程式安全性，並指導他們如何直接採用鋪設之路的元素。一旦鋪設之路的某個方面被採用，組織應該實施持續整合檢查，檢測現有代碼和提交是否使用了禁用選項，並警告或拒絕構建或提交。這可防止隨著時間的推移不安全選項悄悄進入代碼，從而避免技術債務和不安全應用程式的產生。這些警告應該鏈接到安全的替代方案，以便開發團隊立即獲得正確的答案，並且可以快速重構並採用鋪設之路的組件。

階段5：測試鋪設之路是否解決了OWASP前十大中的問題

鋪設之路的組件應該解決OWASP前十大中的重大問題，例如如何自動檢測或修復易受攻擊的組件，或靜態代碼分析IDE插件檢測注入，或者更好的解決方案是已知的安全庫（如React或Vue）。提供給團隊的這些安全替代方案越多越好。AppSec團隊的一項重要任務是確保這些組件的安全性得到持續評估和改進。一旦它們得到改進，應該有某種與組件使用者的溝通途徑，指出應該進行升級，最好是自動完成，如果無法自動完成，至少應在儀表板或類似平台上突出顯示。

階段6：將您的計畫構建成成熟的AppSec計畫

您不能止步於OWASP前十大。它只涵蓋10個風險類別。我們強烈建議組織採用應用程式安全驗證標準（Application Security Verification Standard），並根據所開發應用程式的風險級別，逐步添加鋪設之路的組件和測試，涵蓋1級、2級和3級。

• 超越最低要求
  所有優秀的AppSec計畫都超越了最低要求。如果我們要真正解決應用程式安全漏洞，大家都必須持續努力。

• 概念完整性：
  成熟的AppSec計畫必須包含某種形式的安全架構概念，無論是正式的雲端或企業安全架構，還是威脅建模。

• 自動化與擴展：
  成熟的AppSec計畫會盡可能自動化其可交付成果，使用腳本模擬複雜的滲透測試步驟，將靜態代碼分析工具直接提供給開發團隊，幫助開發團隊構建AppSec單元和整合測試等等。

• 文化：
  成熟的AppSec計畫會努力消除不安全設計，並通過與開發團隊融合，消除現有代碼的技術債務。AppSec團隊如果把開發團隊視為“我們”和“他們”是不會成功的。

• 持續改進：
  成熟的AppSec計畫會不斷尋求改進。如果某些東西不起作用，就停止使用。如果某些東西笨重或無法擴展，就努力改進。如果某些東西沒有被開發團隊使用且影響有限，那就做點不一樣的事情。只是因為我們從1970年代就開始做桌面檢查測試，並不意味著這是個好主意。測量、評估，然後構建或改進。