第 10 章 知識域：軟體開發安全

CISP 考試教材《第 1 章 知識域：資訊安全保障》知識整理

CISP 考試教材《第 2 章 知識域：網路安全監管》知識整理

CISP 考試教材《第 3 章 知識域：資訊安全管理》知識整理

CISP 考試教材《第 4 章 知識域：業務連續性》知識整理

CISP 考試教材《第 5 章 知識域：安全工程與運營》知識整理

CISP 考試教材《第 6 章 知識域：資訊安全評估》知識整理

CISP 考試教材《第 7 章 知識域：資訊安全支撐技術》知識整理

CISP 考試教材《第 8 章 知識域：物理與網路通信安全》知識整理

CISP 考試教材《第 9 章 知識域：計算環境安全》知識整理

CISP 考試教材《第 10 章 知識域：軟體開發安全》知識整理

目錄

10.1 知識子域：軟體安全開發生命周期

10.1.1 軟體生命周期模型

1.瀑布模型

2.迭代模型

3.增量模型

4.快速原型模型

5.螺旋模型

6.凈室模型

7.各軟體程序模型的特點

10.1.2 軟體危機與安全問題

1.軟體危機

2.軟體安全問題

3.軟體安全保障

10.1.3 軟體安全開發生命周期模型

1.SDL（安全開發生命周期）

2.CLASP（綜合的輕量級應用安全程序）

3.CMMI（軟體能力成熟度集成模型）

4.SAMM（軟體保證成熟度模型）

5.BSIMM（BSI成熟度模型）

6.各軟體安全開發模型的特點

10.2 知識子域：軟體安全需求及設計

10.2.1 威脅建模

1.威脅建模作用

2.威脅建模流程

3.STRIDE 模型

10.2.2 軟體安全需求分析

1.系統調查

2.定性分析系統的弱點和可能遭受的安全威脅

3.脆弱點和安全威脅的定量分析

4.需求的確定

10.2.3 軟體安全設計

1.作業內容與活動

2.安全設計原則

10.3 知識子域：軟體安全實作

10.3.1 安全編碼原則

1.驗證輸入

2.避免快取溢位

3.程式內部安全

4.安全呼叫組件

5.禁止使用不安全函式

10.3.2 軟體安全編譯

10.3.3 代碼安全審核

1.源代碼審核的概念和原理

2.源代碼審核工具

10.4 知識子域：軟體安全測驗

10.4.1 軟體測驗

1.軟體測驗基本概念

2.軟體測驗方法

10.4.2 軟體安全測驗

1.軟體安全測驗基本概念

2.軟體安全測驗方法

3.安全測驗思路

10.5 知識子域：軟體安全交付

10.5.1 軟體供應鏈安全

1.軟體供應鏈安全的概念

2.軟體供應鏈安全應對措施

10.5.2 軟體安全驗收

10.5.3 軟體安全部署

1.軟體安全部署的重要性

2.軟體安全加固

3.軟體安全配置

---

10.1 知識子域：軟體安全開發生命周期

10.1.1 軟體生命周期模型

軟體開發生命周期（Software Development Life Cycle，SDLC）又稱為軟體生存周期或軟體生命周期

每個階段都要有定義、作業、審查，并形成程序檔案，按部就班、逐步推進，以提高軟體的質量

按照軟體生命周期思想，軟體開發不再單單強調“編碼”，而是概括了軟體開發的全程序

生命周期模型（Life Cycle Model）

1.瀑布模型

瀑布模型（Waterfall Model）

核心思想是按工序將問題簡化，將功能的實作與設計分開，便于分工協作，即采用結構化的分析和設計方法將邏輯實作與物理實作分開

2.迭代模型

迭代模型是統一軟體開發程序（Rational Unified Process，RUP）推薦的周期模型

迭代模型可以理解為多個小型的瀑布模型的組合，所有的階段都可以細分為迭代，每一次迭代都會產生一個可以發布的產品，這個產生是始終產品的一個子集

3.增量模型

增量模型融合了瀑布模型和迭代模型的特征，該模型采用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟體的一個可發布的“增量”

4.快速原型模型

快速原型模型又稱為原型模型，它是增量模型的另一種形式；它是在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發作業

快速原型是利用原型輔助軟體開發的一種思想

5.螺旋模型

螺旋模型是一種演化軟體開發程序模型，它兼顧了快速原型的迭代以及瀑布模型的系統化與嚴格監控的特征

螺旋模型更適合大型的、昂貴的系統級軟體應用

6.凈室模型

凈室是一種應用數學與統計學理論以經濟的方式生產高質量軟體的工程技術

凈室技術“防患于未然”的主導思想

7.各軟體程序模型的特點

10.1.2 軟體危機與安全問題

1.軟體危機

（1）第一次軟體危機

這個時代的程式一個典型的特征就是依賴特定的機器，程式員必須根據所使用的計算機的硬體特征撰寫特定的程式

迫切需要改變軟體的生產方式，提高軟體的生產效率，第一次軟體危機開始爆發

• 軟體開發費用和進度失控

• 軟體的可靠性差

• 生產出來的軟體難以維護

（2）第二次軟體危機

當軟體規模不斷擴大到需要大量的開發人員共同協作時，第二次軟體危機就誕生了

• 軟體成本在總成本中所占的比例不斷升高

• 軟體開發生產率提高的速度遠跟不上硬體的發展速度，使得人類不能充分利用現代計算機硬體所能提供的巨大潛力

為了解決這次危機，面向物件的編程語言誕生了

更好的軟體工程方法誕生了，而程式員也越來越不知道硬體時怎么作業的了

（3）第三次軟體危機

代碼行越多，缺陷也就越多

軟體存在漏洞和缺陷不可避免，這使得應用系統面臨極大的安全風險，從而導致了第三次軟體危機

• 由于軟體安全問題導致的損失越來越多，軟體安全性已經成為不得不認真考慮的問題

• 軟體開發需求中被加入安全相關的需求，安全性測驗成為軟體驗收的依據之一

為了更好地應對第三次軟體危機，在軟體開發的生命周期中開始引入安全相關作業，軟體安全開發生命周期誕生了

2.軟體安全問題

軟體安全（即設計、構造和測驗安全的軟體的方法）

軟體安全問題不僅僅是編碼問題，資料顯示，有超過 50% 的問題實際上屬于軟體設計方面的問題

軟體安全問題的根本原因在于兩個方面：一是內因，軟體本身存在安全漏洞；二是外因，軟體應用存在外部威脅

軟體的缺陷的增長速度趨向于與代碼行數的平方而變化

軟體安全問題產生根源的外因是在目前的軟體開發管理中，更多地重視軟體功能而不關注對安全風險的管理

3.軟體安全保障

軟體安全保障是對“軟體可以規避安全漏洞而按照預期的方式執行其功能”的資訊

軟體安全保障是指確保軟體能夠按照開發者預期、正常地執行任務，提供與威脅相適應的安全能力，從而避免存在可以被利用的安全漏洞，并且能從被入侵和失敗的狀態中恢復

軟體安全保障的目的是在軟體開發生命周期中提升軟體的安全性，主要目的如下

（1）可信賴性

（2）可預見性

（3）遵循性

10.1.3 軟體安全開發生命周期模型

軟體安全開發涵蓋軟體的整個生命周期

安全軟體開發生命周期（Secure Software Development Lifecycle，SSDL）是一種強調具有安全設計和安全措施的軟體生命周期，即通過軟體開發的各個步驟來確保軟體的安全性，其目標是最大限度地確保軟體的安全

據資料表明，在軟體發布后對安全漏洞的修復所需的成本至少是在軟體設計和編碼階段就進行修復的 30 倍

1.SDL（安全開發生命周期）

SDL 基于 3 個核心概念：教育、持續程序改進和責任

SDL 將軟體開發生命周期劃分為 7 個階段，并提出了 17 項重要的安全活動

棄用不安全的函式，屬于實作（實施）階段

（1）培訓

（2）需求

（3）設計

（4）實作

（5）驗證

（6）發布

（7）回應

2.CLASP（綜合的輕量級應用安全程序）

由安全軟體公司（Secure Software，Inc）提出，后來由開放 Web 應用安全專案（The Open Web Application Security Project，OWASP）完善、維護并推廣

3.CMMI（軟體能力成熟度集成模型）

CMMI 的 5 個級別

（1）CMMI Level 1，初始級

（2）CMMI Level 2，可管理級

（3）CMMI Level 3，已定義級

（4）CMMI Level 4，量化管理級

（5）CMMI Level 5，優化管理級

CMMI 的每個等級都由幾個程序域組成，這幾個程序域共同形成一種軟體程序能力

每個程序域都由一些特殊目標和通用目標

當一個程序域的所有特殊實踐和通用實踐都按要求得到實施，就能實作該程序域的目標

4.SAMM（軟體保證成熟度模型）

軟體保證成熟度模型（Software Assurance Maturity Mode，SAMM）

SAMM 規定了 4 個軟體開發程序中的核心業務功能，包括治理、構造、驗證以及部署

4 個業務功能各包括了 3 個安全實踐

（1）治理：策略與指標、教育與指導、政策與遵守

（2）構造：安全需求、威脅評估、安全架構

（3）驗證：設計審核、安全測驗、代碼審核

（4）部署：環境強化、漏洞管理、操作啟用

5.BSIMM（BSI成熟度模型）

BSI 成熟度模型（Building Security In Maturity Model，BSIMM）

6.各軟體安全開發模型的特點

BSI 認為軟體安全有 3 根支柱：風險管理、軟體安全接觸點和安全知識

Gary McGraw

10.2 知識子域：軟體安全需求及設計

安全需求分析應當以風險管理為基礎

安全設計內容一般包括系統安全框架、訪問控制機制、主體權力和權限、加密方法和演算法、資料完整性機制、敏感資料處理機制、內部通信機制等

10.2.1 威脅建模

1.威脅建模作用

威脅建模活動可幫助識別安全目標、相關威脅、相關漏洞和對策

威脅建模也是一種風險管理模型，可以適用于所有的軟體產品和系統的開發

2.威脅建模流程

威脅建模主要流程包括四步：確定建模物件、識別威脅、評估威脅和消減威脅

（1）確定建模物件

（2）識別威脅

威脅并不等于漏洞

（3）評估威脅

（4）消減威脅

3.STRIDE 模型

微軟提出使用 STRIDE 模型來進行威脅建模的實踐，STRIDE 由 Spoofing（假冒）、Tampering（篡改）、Repudiation（否認）、Information Disclosure（資訊泄露）、Denial of Service（拒絕服務） 和 Elevation of Privilege（提升權限）的第一個字母組合而成

10.2.2 軟體安全需求分析

1.系統調查

了解資訊系統所處的安全環境及其他與安全相關的資訊

在此基礎上確定需要保護的資產

評價各個資產的相對價值

2.定性分析系統的弱點和可能遭受的安全威脅

預測資產可能受到的損害及損害來自何方

系統脆弱點和安全威脅是兩個互相依存的概念：沒有威脅，就無所謂脆弱點；沒有脆弱點，威脅也就不稱其為“威脅”

3.脆弱點和安全威脅的定量分析

確定系統暴露各種脆弱點及面臨安全威脅的可能性

4.需求的確定

將定性分析和定量分析的結果結合起來以定義資訊系統的安全需求

開發人員確定相應的安全措施，達到為資訊系統提供有效且合理的安全保障的目的

10.2.3 軟體安全設計

1.作業內容與活動

概要設計階段確定應用系統的安全整體架構

軟體安全設計的活動包括以下方面

（1）詳細風險評估

（2）控制措施選擇

（3）安全技術實作

技術實作分為三步：結構設計、模塊設計、詳細設計

（4）審計審查

檢查安全設計是否符合安全需求

2.安全設計原則

（1）最小特權原則

只應該分配最少的必要權限

（2）權限分離原則

把權限分離成不同的權限許可和認證條件，把用戶分離成不同的權限角色

（3）最少共享機制原則

避免多個主體共享同一個資源

避免資源爭用

（4）完全中立原則

（5）心理可接受度原則

（6）默認故障處理保護原則

即使喪失了可用性，也應該保障系統的機密性和完整性

（7）經濟機制原則

（8）不信任原則

開發者應該假定系統環境是不安全的

（9）縱深防御原則

軟體應該設定多重安全措施，并充分利用作業系統提供的安全防護機制，形成縱深防御體系，以降低攻擊者成功攻擊的機率和危害

（10）保障最榷訓節原則

（11）公開設計原則

（12）隱私保護原則

系統收集到的用戶資訊都必須實施妥善和安全的保護

（13）攻擊面最小化原則

攻擊面（Attack Surface），通常也稱受攻擊面，是指對一個軟體系統可以采取的攻擊方法集合

攻擊面越大，其安全風險也就越大

10.3 知識子域：軟體安全實作

10.3.1 安全編碼原則

CERT 發布的有關 C、C++、Java 等語言的著名安全編碼標準

OWASP 發布了《OWSAP 安全編碼規范快速參考指南》

1.驗證輸入

常見的輸入源如下：

（1）命令列引數

（2）環境變數

（3）檔案及檔案名

（4）網路資料

（5）其他來源

2.避免快取溢位

避免緩沖區溢位，可以使用很多安全防御措施

（1）精心編程避免緩沖區溢位

（2）使用替代的安全函式或函式庫

（3）基于探測方法方法，使用更新、更具安全性的編譯環境，打開一些具有安全防御機制的選項

Immunix 提供的 StackGuard

OpenBSD 提供的 ProPolice

Microsoft 提供的 /GS 選項

（4）非執行的堆疊防御

為 OpenWall 使用的 non-exec 補丁

Redhat/Fedora 所使用的 exec shield

3.程式內部安全

（1）程式內部介面安全

（2）例外安全處理

（3）最小化反饋

（4）避免競爭條件

（5）安全使用臨時檔案

4.安全呼叫組件

為避免呼叫組件帶來安全問題，建議在組件安全、回傳值安全以及傳遞資料安全等幾個方面加強安全防護

（1）組件安全

（2）回傳值安全

（3）傳遞資料安全

5.禁止使用不安全函式

10.3.2 軟體安全編譯

10.3.3 代碼安全審核

1.源代碼審核的概念和原理

源代碼審核是指無須運行被測驗代碼，僅通過分析或檢查源程式的語法、結構、程序、介面等來檢查程式的正確性，報告源代碼中的可能導致安全弱點的薄弱之處，找出代碼隱藏的錯誤和缺陷

理想的做法是使用源代碼審核工具審核和人工審核結合的方式對代碼進行審核，能極大地減少軟體中的安全問題被帶入隨后的軟體生命周期階段的可能性

2.源代碼審核工具

開源工具：BOON、Cqual、Xg++ 和 FindBugs 等

商業工具：Fortify、Coverity、CheckMax、Ounce Labs 和 SecureSoftware 等

（1）安全性

（2）多平臺性

（3）可擴展性

（4）知識性

（5）集成性

10.4 知識子域：軟體安全測驗

IEEE 軟體測驗定義為：使用人工和自動化的手段來運行或測驗某個系統的程序，其目的在于檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差異

10.4.1 軟體測驗

1.軟體測驗基本概念

（1）測驗用例

測驗用例是為某個特定目的而編制的一組測驗輸入、執行條件以及預期結果，以便測驗某個程式路徑或核實是否滿足某個特定需求

（2）測驗覆寫率度量指標

測驗覆寫率度量指標是測驗完整性的一個手段，是測驗有效性的一個度量

• 陳述句覆寫

• 判定覆寫，又稱分支覆寫

• 條件覆寫

• 判定-條件覆寫

• 條件組合覆寫

• 路徑覆寫

（3）測驗的信條

2.軟體測驗方法

根據軟體測驗作業的測驗策略，一般將軟體測驗程序分為單元測驗、集成測驗、系統測驗和驗收測驗 4 個大階段

根據對軟體內部作業程序了解的程度又分為黑盒測驗、白盒測驗和灰盒測驗

從測驗程序中是否執行軟體又可以將軟體測驗分為靜態測驗和動態測驗

（1）單元測驗、集成測驗、系統測驗

單元測驗是對軟體中的基本組成單元進行測驗

單元測驗的主要方法又控制流測驗、資料流測驗、排錯測驗等

集成測驗是在軟體集成程序中所進行的測驗，其主要目的是檢查軟體單位之間的介面是否正確

系統測驗是對已集成好的軟體系統進行徹底的測驗

（2）黑盒測驗、白盒測驗、灰盒測驗

黑盒測驗意味著測驗要在軟體的介面處進行（外部人員）

黑盒測驗又稱功能性測驗或資料驅動測驗

白盒測驗也稱結構測驗、透明測驗、邏輯驅動測驗或基于代碼的測驗，是對軟體的程序細節做的細致的檢查（內部人員）

灰盒測驗是一種介于白盒測驗和黑盒測驗之間的一種測驗方法（兩者之間）

（3）靜態測驗、動態測驗

靜態方法是指不運行被測程式本身

靜態測驗又可分為代碼走查、代碼審核和代碼評審

• 代碼走查

• 代碼審查

• 代碼評審

動態方法是指通過運行被測程式，檢查運行結果與預期結果的差異，并分析運行效果和健壯性等

（4）回歸測驗

回歸測驗是指在發生修改之后重新測驗先前的測驗以保證修改的正確性

（5）驗收測驗

驗收測驗旨在向購買者展示該軟體系統滿足其用戶的需求

這是軟體在投入使用之前的最后測驗

10.4.2 軟體安全測驗

1.軟體安全測驗基本概念

2.軟體安全測驗方法

模糊測驗和滲透測驗是常用的軟體安全性測驗方法

（1）模糊測驗

模糊測驗，也稱 Fuzz 測驗

一種通過提供非預期的輸入并監視例外結果來發現軟體故障的方法

模糊測驗的主要步驟

• 生成大量的畸形資料作為測驗用例

• 將這些測驗用例作為輸入應用于被測物件

• 檢測和記錄由輸入導致的任何崩潰或例外現象

• 查看測驗日志，深入分析產生崩潰或例外的原因

影響模糊測驗效果的一些關鍵因素

• 測驗點

• 樣本選擇

• 資料關聯性

• 自動化框架

• 例外監控與例外恢復

• 分析評估

（2）滲透測驗

滲透測驗是一種模擬攻擊者進行攻擊的測驗方法，從攻擊的角度來測驗軟體系統，并評估系統安全性的一種測驗方法

滲透測驗會使用多種網路安全工具，自動化的滲透測驗平臺也逐漸出現，比較著名的包括 IMPACT、CANVAS 和 Metasploit

開展滲透測驗必須注意以下兩點

• 它是非破壞性測驗

• 需要進行測驗風險控制

（3）靜態代碼安全測驗

3.安全測驗思路

做好軟體安全性測驗的必要條件

（1）充分了解軟體安全漏洞

（2）評估軟體安全風險

• 安全性缺陷資料評估

• 采用漏洞植入法來進行評估

（3）擁有高效的軟體安全測驗技術和工具

10.5 知識子域：軟體安全交付

10.5.1 軟體供應鏈安全

1.軟體供應鏈安全的概念

不同于自身的安全漏洞，供應鏈安全問題來自外部的惡意代碼對軟體代碼的污染

這些安全問題設計軟體的代碼撰寫、代碼編譯、軟體分發、軟體更新等各個環節

（1）代碼撰寫

針對共享庫進行攻擊，攻擊者能將惡意代碼植入這些共享庫中，從而隨著軟體的發布進入最終的用戶計算環境中

（2）代碼編譯

實施編譯的軟體如果被攻擊者植入了惡意代碼

（3）軟體分發及更新

攻擊者入侵了軟體開發商的系統，在發布/更新的軟體中嵌入惡意代碼，利用用戶對軟體開發商的信任進入用戶的系統中，從而給用戶帶來安全風險

2.軟體供應鏈安全應對措施

針對供應鏈安全問題的根源采取措施才是有效解決之道

（1）代碼撰寫安全

（2）代碼編譯安全

（3）軟體發布及更新安全

10.5.2 軟體安全驗收

10.5.3 軟體安全部署

由于軟體安全加固和配置上的錯誤導致的安全問題在軟體安全問題中占比非常高

1.軟體安全部署的重要性

2.軟體安全加固

3.軟體安全配置