安全編碼－資訊安全面臨的挑戰

程式碼中的安全漏洞

作業系統軟體、應用軟體或嵌入式系統中的韌體是任何數位基礎設施的基本組成部分。然而，數位化專案日益加快的步伐和緊迫的截止日期往往導致對至關重要的資訊安全問題的忽視。軟體開發需求通常以功能為中心，強調建構性方面，因此，對潛在安全漏洞的破壞性考慮與實際開發目標大多背道而馳：許多程式設計師也缺乏系統化且深入的網路安全意識。

在這種情況下，開發團隊很難持續審查並一致地保護其軟體程式碼的安全，非營利組織MITRE公司每年發布的眾多漏洞就證明了這一點。 CVE常見漏洞和風險清單。即使是知名軟體廠商定期發布的安全性修補程式也表明，修復安全漏洞是一項永無止境的艱鉅任務，更遑論在產品上市前就識別出這些漏洞。

開源程式碼——一個特例

在編寫自主開發的軟體時，程式設計師通常喜歡使用開源程式庫和模組。其實際優勢顯而易見：無需反覆重複造輪子，就能享受到技術進步帶來的便利，例如加快開發速度、降低開發成本、透過開源程式碼提高透明度，以及透過開放標準和介面實現更高的互通性。

人們也常說，開源程式碼具有很高的安全性，因為程式碼已經過許多用戶的驗證，而且開源社群的群體智慧能夠快速有效地修復錯誤。

實際上，這種信任現在必須以差異化和批判性的方式進行評估。最嚴重的例子是廣泛使用的 Java 應用程式日誌庫 Log4J 中的零日安全漏洞 Log4Shell，該漏洞於 2021 年 11 月被發現。您可能聽說過德國聯邦資訊安全辦公室 (BSI) 針對 Log4Shell 發布了紅色警報。 Log4J 函式庫由 Apache 基金會發布，作為一種可靠運作的準標準，自 2013 年以來已在許多系統中廣泛應用，包括 Amazon AWS 等知名 Web 服務。

這些開發完善且維護良好的庫的複雜性隱含地提供了強大的功能，而導入這些庫的開發人員在自己的新開發中往往意識不到這些功能，但攻擊者可以利用這些功能。

開源元件的另一個不安全因素是所謂的供應鏈攻擊，即惡意行為者偽裝成開源社群成員，參與程式碼開發，故意植入漏洞。這種漏洞為駭客攻擊大量下游用戶組織提供了極其有效的途徑。因此，這種攻擊途徑迅速增長也就不足為奇了。 聲型研究與 2020 年相比，2021 年的診斷結果顯示成長了 650%。

資訊安全控制 8.28 安全編碼

為了及時保障軟體開發過程，國際標準化組織（ISO - ISO/IEC JTC 1/SC 27 委員會）已將「安全編碼」納入新的 ISO/IEC 27002 標準 8.28 中。 ISO/IEC 27001:2022附件A標準。安全編碼技術措施的目的是對軟體進行預防性保護。

在編寫階段就根據程式規格建立最低安全級別，從而最大限度地減少軟體中潛在的安全漏洞。安全代碼產生的監管框架應全面應用於公司本身的程式碼以及來自第三方和開源軟體。值得注意的實施原則包括：安全設計最小權限原則也是編碼時必須考慮的因素。

安全編碼原則

措施 8.28 多次提及所謂的安全編碼原則。許多組織和機構定期發布安全編碼指南和最佳實踐，為這些原則的闡述提供了指導。例如，其中包括： 安全編碼實踐OWASP基金會， 安全編碼標準軟體工程研究所 (SEI) 的電腦緊急應變小組 (CERT) 以及德國聯邦資訊安全局 (BSI) 的網路應用安全措施目錄。儘管來源不同，但這些闡述方式有許多相似之處，例如在以下幾點：

• 資料輸入驗證
• 確保身份驗證和密碼管理安全
• 安全存取控制
• 簡潔透明的程式碼
• 經過可持續測試的加密措施和組件
• 錯誤處理和日誌記錄
• 資料保護
• 威脅建模

在 ISO/ISO 27002:2022 標準中，控制 8.28 的建議措施分為三個部分：“規劃和預編碼”、“編碼期間”和“驗證和維護”，其核心內容概述如下。

規劃和預編碼

無論是新程式碼開發還是程式碼重複使用，都需要應用安全編碼原則——無論程式碼是為內部軟體編寫，還是為外部產品和服務編寫。這就要求事先評估組織的具體需求，並定義公認的原則。此外，建議的規劃和預編碼措施應考慮已知的常見和歷史編碼實踐以及可能導致漏洞的錯誤。

開發工具的配置，例如整合開發環境 (IDE) 中的基於規則的配置，應確保編寫出安全的程式碼。開發人員的資格及其對安全架構和程式設計標準的熟悉程度至關重要。在開發團隊中配備資訊安全專家是理所當然的。

在編碼過程中

在編碼過程中，編碼規格和結構化程式設計技術至關重要，必須充分考慮具體的用例及其安全需求。應始終禁止使用不安全的設計技術，例如硬編碼密碼。程式碼應進行充分的文件記錄和審查，以最大程度地消除安全漏洞。程式碼審查應在開發過程中和開發完成後進行，可透過靜態應用程式安全測試 (SAST) 或類似方法實現。靜態測試方法支援「左移」策略（「儘早且頻繁地測試」），透過在生命週期早期對可見程式碼進行規則符合性測試來實現。

這有助於及早識別受污染的程式碼、與檔案或特定物件類別的關聯，以及可能被利用來與第三方程式進行隱藏互動的應用程式層級漏洞。在軟體投入運作之前，Control 8.28 要求評估攻擊面並實施最小權限原則。此外，還應評估最常見程式錯誤的分析以及相應的修正記錄。

驗證和維護

即使軟體上線運行後，安全編碼仍然至關重要。這包括安全性更新以及對程式碼中已知漏洞的檢查。此外，必須記錄錯誤和疑似攻擊，以便及時進行必要的調整。無論如何，必須使用合適的工具可靠地防止未經授權存取原始程式碼。

開源程式碼

在驗證和維護方面，措施 8.28 也列出了使用外部工具和程式庫（例如開源軟體）的明確說明。這些程式碼元件應在清單中管理、更新和維護。例如，可以透過軟體物料清單 (SBOM) 來實現。 SBOM 是軟體的軟體包和庫及其相互關係以及在供應鏈中的關係的正式、結構化記錄，尤其用於追蹤重複使用程式碼和開源元件。 SBOM 支援軟體的可維護性和有針對性的安全性更新。

結論

安全代碼是阻止潛在攻擊的基本基礎。新的 Control 8.28 指南充分認識到這一點，並提升了安全代碼在資訊安全中的關鍵作用。然而，由於該指南包含大量詳細的行動建議，且技術要求較高，因此實施起來需要投入相對較大的精力——這一點應在規劃階段就予以考慮。

憑藉我們經驗豐富的審核員的專業視角，我們將協助您合規地實施相關措施。我們擁有超過35年的審核和認證經驗，是您理想的合作夥伴，並樂於根據ISO/IEC 27001:2022標準，為您提供資訊安全和認證方面的協助。

ISO 27001 修訂：此次更新對您的認證意味著什麼？

ISO/IEC 27001:2022 標準於 2022 年 10 月 25 日發布。因此，使用者需要遵守以下過渡期限和時間安排：

根據「舊版」ISO 27001:2013標準，首次/重新認證審核的最後日期

• 自2024年4月30日起，DQS將僅依據新標準ISO/IEC 27001:2022進行初審和再認證審核。

所有現有證書均依照「舊」ISO/IEC 27001:2013標準過渡到新的ISO/IEC 27001:2022標準。

• 自2022年10月31日起，設有3年的過渡期。
• 根據 ISO/IEC 27001:2013 或 DIN EN ISO/IEC 27001:2017 頒發的憑證最遲有效期至 2025 年 10 月 31 日，否則必須在此日期撤銷。

DQS：簡單利用安全。

由於存在過渡期，企業有充足的時間根據新要求調整其資訊安全管理系統 (ISMS) 並獲得認證。然而，整個變更過程所需的時間和精力不容小覷——尤其是在缺乏足夠專業人員的情況下。為了確保萬無一失，您應該儘早處理這個問題，並在必要時尋求經驗豐富的專家的幫助。

作為擁有超過35年經驗的審計和認證專家，我們樂於協助您評估當前狀況，例如進行增量審計。我們經驗豐富的審計師團隊將為您說明最重要的變更及其對貴組織的影響。我們將與您共同探討改善潛力，並全程支持您直到獲得新的認證。充分利用我們在資訊安全領域的專業能力！期待您的垂詢。