OPSWAT的Secure SDLC 架構：致力於彈性與深度防禦的安全性

惡意行為者以系統獲利或破壞為目標，導致組織的成本、業務風險和聲譽受損。 

根據最近的一項調查，在生產階段發現的安全漏洞，其修復成本比分析與需求階段高出 30 倍。

OPSWAT的Secure SDLC Framework 定義了引導安全軟體開發的結構化方法與安全原則。 

OPSWAT 遵循敏捷Software 開發生命週期。為了完全符合我們客戶的要求，我們根據法規要求和國際標準採用了Secure SDLC 框架。此方法強化了我們在不斷演進的網路安全環境中，持續改善與適應力的承諾。

OPSWAT的Secure SDLC 架構建基於NIST SP 800-218SSDFSecure Software 開發架構)，可確保在軟體開發流程的所有階段中，安全都是結構化、可衡量且一致應用的。  

藉由整合 SSDF 最佳實務，OPSWAT 可維持主動的安全勢態，將安全嵌入軟體開發的每個階段 - 從規劃與設計到執行、驗證與持續監控。 

個別產品的合規性證明可按需提供給我們的美國聯邦政府客戶。請參閱下面的詳細聯繫方式。

隨著網路安全法規的持續演進，OPSWAT 始終致力於使其Secure SDLC 架構與全球法規要求保持一致，首先是歐盟網路復原法案和 NIS2 指令。透過主動適應新興標準，OPSWAT 可確保其Secure SDLC 在日益複雜的法規環境中保持全面性、合規性和彈性。

維持穩健的資訊安全對於營運完整性與法規遵循皆至關重要。OPSWAT 的Secure SDLC Framework 結合 ISO 27001 ISMS (資訊安全管理系統) 原則，可確保安全控制、風險管理策略與法規遵循措施能完美整合至雲端產品的運作中。 

OPSWAT 既是我們安全解決方案的提供者，也是消費者，我們會應用公司內部強制執行的安全政策，確保我們的認證產品在部署前符合企業級的安全期望。  

請參閱合規與認證的詳細資訊。

為了確保最高標準的軟體品質，OPSWAT的Secure SDLC Framework 已整合至 ISO 9001 QMS (品質管理系統)。品質管理系統針對治理、變更管理和跨功能流程建立經審核的品質控制，支援產品和支援產品的定義、設計、開發、生產和維護，從研發延伸至銷售、客戶支援、資訊技術和人力資源等領域。  

此方法強化了我們對結構化、以風險為基礎的品質管理方法的承諾，確保應用程式安全仍是所有業務功能中不可或缺的考量。

請參閱合規與認證的詳細資訊。

OWASPSoftware Assurance Maturity Model (SAMM)是一套全面的架構，可協助組織在現有的 SDLC 中評估、擬定並實施有效的軟體安全策略。

作為一個開放原始碼架構，SAMM 受惠於全球的貢獻，可確保應用程式安全的協作、持續演進的方法。其結構化的方法可讓組織以有效且可衡量的方式分析並改善其開發生命週期。SAMM 支援完整的開發生命週期。SAMM 與技術和流程無關。SAMM 具有演進性和風險驅動性。透過利用 SAMM，團隊可針對安全漏洞獲得可行的洞察力，並在整個開發生命週期中有系統地強化其安全勢態。

OWASP 應用程式安全驗證標準 (ASVS)是全球公認的架構，旨在建立結構化、可衡量且可行的 Web 應用程式安全方法。它為開發人員和安全團隊提供了一套全面的安全需求和驗證準則，以確保應用程式符合業界最佳實務。 

作為一個開放原始碼架構，ASVS 得益於全球安全社群的廣泛貢獻，確保它能與新興威脅和演進中的安全標準保持同步。

OPSWAT 的Secure SDLC Program 將Secure SDLC Framework 轉換為結構化的治理，確保安全需求被記錄、維護、測量及持續改善，同時也確保所有參與方接受足夠的訓練。它為開發、測試和生產環境建立角色、責任和安全措施，以及管道安全，定義Secure 開發環境，並強制在Secure SDLC 流程中應用安全政策。

高階管理人員 - 首席產品官 (CPO)

首席產品官（CPO）負責所有產品團隊以及其他研發（R&D）計畫（如品質保證（QA）計畫和使用者體驗（UX）計畫）中Secure SDLC 計畫的策略性監督和執行，確保安全、高品質和以使用者為中心的軟體開發的連貫性。

作為所有產品和研發流程的主要風險所有人，CPO 授權研發營運部門擁有Secure SDLC 計畫，並確保產品領導人執行Secure SDLC 計畫的應用，以及在產品團隊中有效實施Secure SDLC 流程。CPO 負責批准Secure SDLC 計畫的修改，以及偏離Secure SDLC 流程的情況。

CPO 還會監控Secure SDLC 計劃的成果，追蹤安全成熟度、弱點、合規性和開發活動，以維持產品的穩固安全勢態。

此外，CPO 還負責研發安全預算的分配與核准，確保Secure SDLC 計畫有足夠的專用資源。

策略優先

OPSWAT的應用程式安全策略計畫符合其業務優先順序與風險承受度，並考慮到每項產品的成熟度及其所曝露的安全威脅。主要重點是保護高風險產品，特別是那些擁有龐大客戶群、面向公眾部署或整合至關鍵基礎架構的產品。

作為Secure SDLC 計劃的一部分，除了公司的一般安全意識訓練外，還強制規定所有參與安全開發的員工必須接受特定角色的安全訓練。公司的訓練工具會追蹤所有訓練。訓練與意識計畫會定期檢討，以納入新的安全趨勢，並確保持續符合安全標準。

OPSWAT 致力於透過結構化的效能衡量、成熟度評估及定期更新，持續強化其Secure SDLC 計畫，以確保持續的安全效能。  

為了維持強大的安全勢態，OPSWAT 採用有系統的方法來追蹤並改善安全績效。這包括每季的產品安全成熟度評估、內部安全檢閱以驗證是否符合最佳實務，以及定義年度關鍵績效指標 (KPI)，並每季進行衡量。  

為了有效衡量應用程式安全勢態，OPSWAT 使用結構化指標來評估團隊。根據 SAMM 架構評估每個團隊的產品安全成熟度，提供可量化的安全進度測量。此外，產品還要接受 ASVS 合規性評估，以確保符合安全驗證要求。Secure SDLC 流程的合規性會受到密切監控、評估，而 KPI 目標的達成也會以證據為基礎，確保安全勢態和安全改進都是可衡量且可行的。所有產品團隊都必須達到安全成熟度目標，作為其年度績效評估的一部分。 

作為持續改善工作的一部分，OPSWAT 定期推出新的產品安全計畫，以提高成熟度並加強應用程式安全。這些計畫包括更新安全政策以因應新興威脅、整合新的安全工具以加強偵測與預防，以及擴大 KPI 目標以推動持續進步。 

為了進一步強化安全治理，OPSWAT 對Secure SDLC 架構進行年度審查，將過去安全事件的根本原因分析、弱點趨勢評估，以及現有流程與政策的改進所獲得的洞察力納入其中。  

這種持續改善的結構化方法可確保OPSWAT 維持主動、彈性的產品安全勢態，有效適應不斷演進的網路安全挑戰，同時滿足法規與作業安全目標。

Secure SDLC 流程透過定義團隊必須遵循的安全控制，進一步實作Secure SDLC 計畫，包括特定活動，例如每個開發階段的自動化安全檢查與驗證機制。此流程與其他重要的研發計畫（如品質保證計畫和使用者體驗計畫）相結合，以確保安全、高品質和以客戶為導向的軟體開發方法具有連貫性。 

Secure SDLC 流程詳述於以下各節：

• Secure 設計與風險評估
• Secure 實施、建置與部署
• 應用程式安全測試與驗證
• Secure 釋放
• Secure 操作與維護

Secure SDLC 流程是一個高層級的流程，團隊可以在流程的安全性必須維持在最低等級的條件下，以延伸的客製化方式實施。偏離Secure SDLC 流程必須記錄在案並經核准。

Secure SDLC 計畫包含各種政策，這些政策必須由產品團隊正式核准與確認，以確保符合其要求。遵守這些政策在內部是強制性的，每個團隊都有責任檢閱、簽署和執行這些政策，並將其視為開發流程的一部分。 

以下列出了主要政策及其各自的目的。對於對外重要的政策，本文件中會包含其他詳細資訊。

作為Secure SDLC 流程的一部分，安全需求會在整個開發生命週期中進行追蹤、記錄與維護。協力廠商必須認可並符合 ASVS，以確保所有軟體元件的安全期望一致，並遵守產品隱私權規範政策。 

安全融入開發生命週期的每個階段。安全領導者有責任牢記Secure SDLC 流程的期望，並在其團隊中代表這些期望。 

Secure 設計需求集包括以 ASVS 為基礎的功能性與非功能性安全需求。研發營運部會提供參考模型，以支援設計決策，並在需要時對 ASVS 要求進行有記錄的調整 (例如更強的加密要求)。

威脅建模是在開發生命週期最早期階段識別威脅與弱點的結構化程序。它是Secure SDLC 流程中不可或缺的一環，定期進行 - 至少每年一次或每當引入新功能或架構變更時。產品團隊透過定義安全目標、識別資產與相依性、分析潛在攻擊情境，以及降低已識別的威脅，來執行威脅建模。  

強化的方法結合資料流程分析與既有的威脅建模實務 (例如 STRIDE 模型)，以確保跨產品的全面評估。必要時，會啟動安全檢閱以驗證是否符合安全需求，並主動處理潛在風險。我們會仔細記錄設計決策，並在整個產品生命週期中持續追蹤任何剩餘風險。

應用程式安全風險使用多種來源進行評估，包括在威脅建模過程中發現的殘留威脅、廣泛認可的安全弱點 (例如 OWASP Top 10 和 SANS Top 25 中的弱點)，以及根據 ASVS 準則缺失的安全控制。其他風險因素包括整個建置、部署及發行流程中的機密管理弱點，以及開放原始碼與第三方元件中的弱點。 

在進行風險評估後，會制定減輕風險計劃，以降低已識別風險的嚴重性，並同時考慮影響和可能性。這些計劃以及相應的風險和緩解步驟都會徹底記錄在案。 

餘留風險會在整個產品生命週期中進行追蹤，並定期進行檢閱，而且必須由風險所有者正式確認。這些風險也會納入內部發行報告中，以維持能見度和責任。 

必要時會啟動安全審查，以確保符合安全需求，並主動處理潛在風險，強化產品的整體安全勢態。

作為Secure SDLC 流程的一部分，包括實作、建置與部署，其目的在於根據Secure 設計與風險評估，預防漏洞與瑕疵。需求集包含基於 ASVS 的功能性與非功能性安全需求、安全開發以及依賴Secure 開發環境的測試方法。  

在實施過程中，必須應用Secure 編碼最佳實務、Secure 程式碼檢閱和早期偵測安全漏洞。團隊必須遵守Supply Chain 安全政策 (包括供應商入職與開放原始碼軟體主題)、AI 使用政策與惡意軟體樣本處理政策。在建置與部署過程中，必須使用集中式 CI/CD 管道使用Secure 建置與部署以及職責分工。

產品團隊必須在實施過程中遵循與語言無關的安全編碼最佳實務。他們必須驗證輸入資料、淨化傳送至其他系統的資料、消除編譯器警告、設定安全的錯誤訊息、在適用的情況下應用輸出編碼、在不暴露敏感資料的情況下執行安全記錄，以及遵循適當的錯誤處理和異常管理準則。團隊也必須確保加密（如果使用）依賴核准的演算法和安全的隨機數生成，並透過安全處理記憶體、防止競賽條件，以及透過適當的同步化避免死鎖，來安全管理系統資源。 

我們也建議產品團隊遵循 SAST 工具所強制執行的特定語言安全編碼準則，如下所示： 

對於Java，團隊應確保比較作業中使用的金鑰是不可變的、使用 SecureRandom 而非 Random，並透過驗證或限制輸入類別來避免不安全的反序列化。

在C++ 中，建議偵測並處理記憶體分配錯誤，透過邊界檢查和使用智慧指標 (例如 std::unique_ptr())，防止緩衝區溢出，並避免使用不安全的函數 (例如 strcpy() 和 sprintf())。 

對於Python，開發人員應避免使用 eval() 或 exec() 等函數，以降低程式碼注入風險，並在處理不信任的資料時，寧可使用 json 模組等安全序列化格式，而非 pickle。

作為應用程式安全驗證政策所要求的安全檢閱的一部分，安全程式碼檢閱非常重要，並依據開發技術執行，根據OWASP Cheatsheet系列應用各種Secure 程式碼檢閱檢查清單。

根據應用程式安全驗證政策的要求，及早偵測安全漏洞是開發流程的重要組成部分。為了將潛在的安全問題減至最低，強制採用「建立失敗」的方法，以確保不安全的程式碼不會繼續通過管道。此外，也強制執行「合併失敗」方法，要求團隊在整合變更之前，先修復任何偵測到的問題。解決偵測到的瑕疵對於達成發行標準至關重要。

作為Secure SDLC 流程的一部分，必須使用集中化、協調的 CI/CD 管道，以強制執行安全建置並避免供應鏈攻擊。稽核、建置與部署日誌會依照公司安全政策的定義產生、保存與檢閱。 

每個產品團隊都有責任在適用的情況下遵循安全的建立和編譯器組態。他們必須使用安全的編譯器選項、停用除錯代碼、加強解譯語言的執行時間、釘選相依性版本、確保可重複建立，並加強容器影像。所使用的組態必須記錄在案並定期檢閱。 

根據職責分離原則，開發人員和其他擁有程式碼或建置存取權限的團隊成員不能存取生產環境。如果是雲端產品，則僅允許產品的網站可靠性工程師部署到生產環境。

根據我們的應用程式安全驗證政策，我們會針對發現的問題執行正式的文件記錄與追蹤，並指定自動化工具進行持續驗證。作為Secure SDLC 流程的一部分，我們會在 SDLC 的每個階段執行安全檢查並追蹤，以符合法規要求。其目的在於有效率地找出可能的安全漏洞。出現的安全問題會由團隊進行調查，並在時限內解決。時間框架是已定義的安全 KPI 的一部分。

• 架構與設計審查：資深工程師和應用程式安全虛擬團隊成員會評估設計變更中的安全層面，包括加密、驗證、授權、稽核、系統加固、系統和網路架構。 
• 程式碼檢閱： 在同儕與資深工程師定期進行程式碼檢閱的基礎上，應用程式安全虛擬團隊的成員會檢閱變更，以防止常見的缺陷，例如注入、錯誤處理與不安全的組態。

• 秘密掃描以避免秘密外洩，並確保秘密處理的良好設計和安全實作。
• SAST (靜態應用程式安全測試)工具可偵測漏洞 (如 SQL 注入、緩衝區溢出)。
• SCA (Software 組成分析)用於偵測開放原始碼漏洞。
• DAST (動態應用程式安全測試)用於找出執行時 (例如記憶體瑕疵) 和環境問題

早期偵測安全問題」一節中所定義的工具必須在 CI/CD 管道中使用。所有發現的弱點都必須依照「產品Vulnerability Management 政策」進行修復。

自動化與手動安全測試方法都是依照執行安全測試計畫的品質保證計畫來使用。

• DAST 工具 可用於偵測執行時的弱點、測試預設組態，以及測試應用強化建議後的系統復原能力。這些測試同時針對軟體和底層基礎架構。 
• 為了避免安全需求和功能的退步，我們使用自動化測試工具持續驗證安全功能和控制的完整性。 
• 手動測試 適用於自動化工具不足之處，例如驗證資訊洩漏的控制、識別業務邏輯缺陷和上下文漏洞。 
• 在開發生命週期中對工件進行自動惡意軟體掃描，也是專注於預防安全問題的步驟之一。

作為Secure SDLC 流程的一部分，發行流程會根據應用程式安全測試與驗證的結果，強制執行發行標準，以確保符合Secure SDLC 流程和產品的整體安全性。產品版本管理在維持各版本的安全性改善、防止安全性相關的退步，以及維持已達成的安全性勢態方面扮演重要角色，是每個版本的基本要求。 

釋出程序包括產生內部釋出報告，記錄剩餘風險和任何未解決的安全問題。這些報告必須由產品領導人正式核准。此外，外部釋出說明也會傳達安全相關的變更與修正，作為產品正式釋出的一部分。 

對於雲端產品，部署遵循「部署失敗」的自動化方法，確保只釋放安全的建置。應用程式安全測試與驗證已整合至部署管道中，並採用作業拉動策略，而非推進策略，以強化生產部署前的安全驗證。 

根據 SBOM 管理政策，每個版本都包含Software Bill of Materials (SBOM) ，以維持元件來源的可追溯性，支援透明度和供應鏈安全性。所有必要的發行檔案都會安全地歸檔，以確保長期的可存取性。

根據「發行完整性政策」，為了維護產品發行的完整性與安全性，我們採用結構化版本系統 (例如語意版本系統)，以確保變更的清晰可追蹤性，並為所有已發行的產品 (包括文件) 設定明確的保留期限。為了進一步加強安全性，軟體製成品會以公司名稱進行數位簽章，並公佈 SHA 指紋，讓使用者可以驗證真實性，並偵測任何篡改企圖。 

每個版本都附有版本說明文件 ，提供完整性驗證方法、安全安裝程序、組態最佳實作及系統強化措施的詳細指引。這些資源可協助使用者有效實施安全控制，減少潛在的攻擊面。此外，還包括終端使用者授權合約 (EULA)，以建立合規義務並保持法律透明度。 

個別產品的 SBOM 可依客戶需求提供。聯絡我們

開發、測試和生產環境被安全地分開，以防止未經授權的存取。每個環境都遵循嚴格的硬化基線和端點安全協定。開發環境必須符合公司的安全政策。

作為端點防護的一部分，所有OPSWAT 的裝置都會受到監控，以找出漏洞、已安裝的軟體、已安裝的修補程式，以及是否符合公司的安全政策。如果發生不遵守規定的情況，則會採取限制措施來限制對公司資源的存取。 

被歸類為高風險類別的資源，只能透過受控存取路徑 (VPN) 存取。公司網路以外的裝置必須使用安全通道存取研發資源。

CI/CD 管道安全遵循嚴格的安全指令，以減緩不斷演進的威脅。威脅的來源可能是過時的基礎架構元素 (例如作業系統、分析工具等)、因弱權限控制而造成的未授權存取，以及隔離性不佳的環境。保持 CI/CD 基礎架構最新、徹底審查並嚴密控管，是我們安全 SDLC 的基石。 

在區域上，所有集中式服務都使用位於美國的伺服器，包括程式碼儲存、CI/CD 管線、分析和測試工具，以及安全的工件簽署。所有集中式工具的配置均由研發營運部控制。 

我們採用強大的驗證機制 (Multi-Factor Authentication - MFA) 和授權控制 (Role-Based Access Control - RBAC)。我們執行最低特權和定期存取審查。 

我們的管道結合了多種分析和測試自動化工具，包括靜態應用程式安全測試 (SAST)、Software 構成分析 (SCA)、動態應用程式安全測試 (DAST)、秘密掃描和惡意軟體掃描。 

在我們的安全程式碼簽章解決方案中，我們使用Hardware 安全模組 (HSM) 來保護金鑰資料，防止未經授權的存取，並產生簽章。簽章解決方案是 CI/CD 基礎架構的一部分，但也有網路區隔。只有研發營運部門有權短暫存取 HSM。每個簽章動作都會記錄在案，並可在稽核追蹤過程中檢視。 

用於建置、編譯或測試軟體的工具集必須具有來源資訊，並來自經驗證的來源。CI/CD 管道中使用的工具數量有限；只安裝必要的工具。管道中的編譯和建置步驟只允許使用 LTS 軟體。在集中式服務的運作中，定時維護和鑰匙輪換的時期是有規定的。內部開發的工具屬於Secure SDLC 流程。

所有集中式服務的環境強化都是持續進行的，這些安全需求也會定期進行檢閱。硬化指引會傳達給產品團隊，以確保他們已做好準備，並可據此調整他們的開發程序。在發生安全事故時，會進行 RCA 以採取預防措施並更新這些需求。

保護原始碼是軟體開發的關鍵部分，以保證公司內部原始碼的機密性和完整性。 

原始碼的儲存遵循最小權限原則，只允許授權人員和工具存取。原始碼受到版本控制。版本控制管理系統保證程式碼變更的可追蹤性和問責性。原始碼儲存採用符合 FIPS 140-3 的加密技術進行加密，並使用適當的金鑰長度進行保護。

所有內部團隊都必須遵守本政策。本文件從屬於公司政策，這意味著在任何矛盾的情況下，以公司政策為優先，並必須遵循。 

違反Secure SDLC 的上訴程序：任何違反本政策的行為都會在內部處理，從研發營運部門開始，必要時會升級到首席產品官 (CPO)。

為 ISO 27001、SOC2、NIST SSDF 範圍內的產品提供元件或服務的供應商，應遵守下列Secure SDLC Framework 的要求。合規性受定期安全稽核、協力廠商評估，以及各方在已簽訂合約下的義務所規範。 

所有廠商都必須提供來源和完整性資訊，以及支援文件，如釋放完整性部份所定義。 

產品元件與函式庫供應商必須建立與我們的實務一致的開發環境，如Secure 開發環境一節所述。產品元件與函式庫供應商必須對其元件與函式庫進行安全測試，如「應用程式安全測試與驗證」一節所述。 

管道元件供應商也必須建立與我們的實務一致的開發環境，如Secure 開發環境部分所述。此外，他們的開發流程必須符合OPSWAT的Secure SDLC 流程。 

服務供應商應使用基於美國的環境，提供與OPSWAT服務相若的安全勢態。他們的Secure SDLC 必須包括Secure SDLC 計畫和Secure SDLC 流程，以反映OPSWAT的期望。