安全代碼開發：敏捷的犧牲者？
作者 Vikas Hazrati 譯者 晁曉娟
敏捷團隊以快速產生可靠和高質量的代碼而著稱。然而，快速交付的壓力可能會導致走捷徑的評審，縮減測試并缺乏對安全代碼的重視。安全開發與敏捷共存是否只是一廂情愿的想法呢？
根據一項中小型企業的研究表明，敏捷團隊并沒有把安全當回事，即使是開發通過 Web 訪問的系統。該研究引用說，
采訪表明，小型和中型的敏捷軟件開發組織不使用任何特定的方法來實現安全目標，即使當他們的軟件是面向 Web 的，是潛在的攻擊目標。這種情況下，研究證實即使在某些案例中安全是被明確要求的，安全設計作為實施團隊的輸入要求之一，最終的結果是否滿足安全目標也沒有保證。
Adrian Lane，也關注 敏捷方法開發軟件風險的安全方面。 Adrian
關注功能的高效交付、以犧牲軟件開發的安全為代價基于書本式的敏捷實施問題，并推動軟件之外的安全確認與服務。
Rocky Heckman 認為，像 TDD 和結對編程這樣的技術， 主要還是聚焦在功能上。
測試的重點放在高質量代碼與可靠的可重復性操作。很少或根本沒有提及滲透式測試或威脅模型。
敏捷開發是否意味著完全無視安全？看起來也許有一些解決方法。
Jim Bird 提出，通過一點點地提醒可能是一種漸進地解決這些風險的方法.
據 Jim 的觀點，就像其他的質量提升實踐那樣，安全實踐是要融入團隊的意識中。 團隊可以使用增量受攻擊面分析來監控系統的安全風險狀況的變化，這可能是由于接口架構的改變導致的。
對于逐步構建軟件并對代碼非常熟悉的團隊來說， 威脅模型并沒有想象的那么嚴重。大部分可在 1 周或 2 周的 Sprint 做完的變更并不大，而且可以增量的修改，不用花太多時間來評審，即使受攻擊面被改變了。
Jim 還提到了利用安全 Sprint，微軟稱之為安全突擊或“迷你安全推進”，在該 sprint 中，團隊尋找現有代碼的安全漏洞，然后再作出進一步的重大變更。Jim 引用 Adrian Lane 的話，他提到，開發團隊比客戶更關注安全性。開發團隊在其開發過程中應給予足夠的重視并擔負起責任。
即使一個強大的和善意的客戶也不能被指望了解應用程序的安全問題，或如何構建安全的軟件。他們 自己的事情已經很多了。
因此，正確的措施和心態有可能把安全作為開發過程的一部分。
Jim 說，
沒有理由認為敏捷開發=安全故障。技術工作，對于質量和細節與構建安全軟件的承諾是相同的，而不論團隊采用什么樣的開發方式。
本文由用戶 fmms 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！