系統中日積月累的安全技術債 怎麼才還得清？

軟體開發生命週期（SDLC）中的「Shift Left」是我們談論許久的概念，它強調在軟體開發之初就要考慮安全最佳踐。而 DevSecOps 概念是更大的躍進，它強調 Dev 跟 Ops 兩團隊應該共同承擔安全的責任，並讓開發者具有安全意識，以求開發時能避免寫出常見的漏洞程式。

你我都知道，僅由監管合規來督促的作法，只會教育出少做少錯的思維，技術債也因此債台高築；想要解決這些技術債，您的開發團隊需要具有靈活清晰的資安思維、能理解不同應用場景要套用不同的修補方式、能觀察出各種漏洞的枝微末節，更重要的是視安全為己任。

想培育這樣子的團隊，首先要讓開發人員對安全技能感到認同、感到榮譽及渴望，願意主動積極的提升程式碼安全品質；還要搭配專業的培訓工具，建立全方位的訓練環境，於各種情境中接受最佳實踐的培訓，由淺入深的學習，才能不斷豐富安全技能，防禦神出鬼沒的攻擊者。

只知其然的資安防禦策略走不遠

在程式開發的層面中，資安防範戰略圍繞在開發人員身上，這是無庸置疑的。安全漏洞大多是由糟糕的開發方式撰寫出來（Log4Shell 就是一個近期破壞性極大的案例），而且真正具備安全技能的開發人員，通常能夠用簡單有效的方式來防堵這類常見的安全漏洞。

許多企業都希望能確保軟體系統的安全性，並為此導入一些安全解決方案，期望開發人員能夠從中習得安全技能，但結果可能跟您想的不一樣……。

舉例來說，想像有人教你怎麼烤蛋糕的時候，給你的指示裡只有提到不能做的事，「不要烤過頭」還有「不要忘記加蛋」等等，這樣的指示有著模糊的解釋空間，不知其所以然的結果就是上演婦仇者廚房。

資安預防教育也是如此；「不要做什麼」傳遞的訊息非常有限，並且沒有提供以預防心態行事的實質建議。你當然可以告訴開發人員「API 不要設置錯誤」，但是如果不了解什麼才是正確且安全的設置，就會有很大的機會出錯。

對於漏洞如何運作、為什麼會有危險、哪種開發方式會導致這些漏洞，以及哪種設計或開發方式能夠修補漏洞等等，如果無法在合乎脈絡的前提下有基本了解，開發人員就無法有效積極的避開漏洞。透過鷹架教學法（scaffolded approach）可以分層提供各種知識讓我們能更全面理解安全程式開發的意義、能夠撰寫安全的程式碼，以及成為具有資安意識的開發人員。

當然，堆疊式學習的一部分應投入於 「進攻方」 ，也就是了解攻擊者思維；這是磨練橫向思考技能的關鍵，在威脅建模（threat modeling） 與防禦策略工作中是十分寶貴的能力。

透過鷹架教學法（scaffolded approach）可以分層提供各種知識讓我們能更全面理解安全程式開發的意義、能夠撰寫安全的程式碼，以及成為具有資安意識的開發人員。當然，堆疊式學習的一部分應投入於 「進攻方」 ，也就是了解攻擊者思維；這是磨練橫向思考技能的關鍵，在威脅建模 （threat modeling） 與防禦策略工作中是十分寶貴的能力。

助長糟糕的開發方式是不容忽視的隱患

某些開發人員學習方式實際上十分不妥，因為其中的「防禦」部分（既使是由攻擊技術組建的訓練）可能會讓程式開發的壞習慣變得更嚴重，即使這樣寫出來的程式碼，「技術上」是安全的。

第一個片段是有漏洞的 code，第二個片段是試圖修復「無效身份認證」的 code，第三個片段是最佳實踐的最安全版本。

優質的程式碼是所有軟體開發的基底，但大家對「品質」的定義其實各持己見。事實上，就算是有用又漂亮的程式碼，只要有安全疑慮，就不能視為優質程式碼。而有趣的是，安全的程式碼也不盡然皆為優質。糟糕的程式寫法也許能解決一個安全問題，但可能引發更多其他問題，甚至是破壞整個系統。

第一個片段中，沒有使用任何檢查來驗證使用者是否已通過身份認證，這就十分的不安全。第二個片段中，雖然有執行身份認證檢查，但沒有調查其角色及權限等級是否足以存取其請求的訊息。第三個片段不僅有做身份認證，還有檢查是否具有「管理者」角色。時至今日，大多數系統都將最小權限原則視為規範，關鍵在於角色權限的設定和檢查，以確保僅有需要知道的人才有存取資訊的權限。

開發人員的首要之務為開發功能，即使並非有意暫且將資安擱置一旁，但開發人員也不見得有能力避免寫出安全漏洞，既使是 " 優秀的 " 工程師也是如此，因為當今衡量工程師的指標中，鮮少包括安全交付的能力。如果寫出的功能符合需求，我們便會對這些糟糕的開發方式睜一隻眼閉一隻眼，形同間接鼓勵這種壞習慣的養成。企業需要改變的就是這種心態，問題是該怎麼改？一些學習方式是讓開發人員親自動手修復程式碼，這可能會助長看似安全，但品質欠佳的程式碼。另一種僅以是非題：「是，這很安全 / 否，這不安全」的培訓方式，則難以深入研究該寫法為何是修復漏洞和維護軟體完整性最適宜的方法，也因此會有一些深藏在細節中的問題被忽略了。

如果開發人員沒有從頭到尾了解安全程式開發的整體概念，就只會使安全漏洞一再地出現。想像一下，如果考駕照時，只有測驗我們是否有能力將車輛駕駛到目的地，這樣就能考到駕照，而不在乎過程中是否闖了紅燈、衝進樹籬、還差點撞到過馬路的行人。雖然考照的當下達成了目標，但下一次呢？雖然這次漏洞修掉了，但下一次呢？

需讓開發人員 重視安全程式開發

現在的開發人員同時要兼顧許多責任，沒有立即性影響功能的技術債會被忽略也很正常，更遑論無聊又麻煩的培訓了。開發人員有各種工作安排、不同專案的截止日期要趕、還有許多緊急待辦事項，沒有顧慮到個體需求的情況就不用奢望他們會認真受訓了。而且不能亂用棍子與胡蘿蔔，在尚未給予定期、合適的學習機會與輔助工具建立技能之時，就直接變更開發人員的 KPI，加重其中的安全門檻，這是不公平的，長期甚至會有反效果。但是，安全軟體開發的重要性是企業無論如何都不能忽視的，所以如何讓開發人員本身對安全開發感興趣，這一點至關重要。

作為一名前開發人員，一般來說我們會想要做得更好，而且當我們的產出品質優於其他人，這種「我是專家」的感覺會令我欲罷不能。所以激發開發人員的動力，使他們主動提升安全技能才是明智的選擇。以保持開發人員自主性為基礎，透過獎勵使他們認識安全程式開發的重要性。接著提供好的工具讓開發人員看得到自己的成長，激發「成為安全專家」的自我實現慾望。再搭配安全冠軍計畫、漏洞賞金和駭客松 （hackathons） 建立積極的企業安全文化，最終您會發現系統中日積月累的安全技術債，已經煙消雲散了。