热门问题
时间线
聊天
视角
軟體系統安全性
来自维基百科，自由的百科全书
Remove ads
軟體系統安全性（software system safety）也稱為軟體安全（Software safety），要確保用在生命攸關系統的軟體，不會讓系統產生危害。 許多不同領域的安全標準，會指導安全相關軟體如何開發和如何測試。大部分會依軟體應用的關鍵程度為軟體分級，並針對不同等級的軟體，說明在開發和驗證過程需要用的技術和量測方式：
- 通用電子安全關鍵系統的軟體：IEC 61508[1]（標準中的第3部份）
- 車用軟體：ISO 26262[2] （標準中的第6部份）
- 鐵路軟體：EN 50716[3]
- 飛航軟體：DO-178C[4]
- 空中交通管理軟體：DO-278A/ED-109A[5]
- 醫療軟體：IEC 62304[6]
- 核電廠：IEC 60880[7]
 |
Remove ads
詞語
系統安全是總體性的要求，目的是要將技術系統中的風險降到可接受的程度，以此實現安全性。根據功能安全標準IEC 61508[1]，安全是「不會有無法接受的風險或傷害」。軟體本身可以視為是單純的資訊，本身不會造成傷害，因此有時會將「軟體安全」一詞改為「軟體系統安全」（例如Joint Software Systems Safety Engineering Handbook[8]和MIL-STD-882E[9]就使用此一詞語）。後者強調軟體只會造成其技術系統的傷害（參考NASA Software Safety Guidebook,[10] chapter 2.1.2），而其傷害會對系統周圍有影響。
軟體安全的目的是確保軟體不會造成所在系統的危害，而且此事可以確認並且證明。這一般是用指定軟體的「安全等級」，並且選擇適當的開發程序以及證認程序來達到。
指定安全等級
創建安全相關軟體時的第一步是依照其安全關鍵程度來分類。不同安全標準有各自的分類：像是DO-178C的軟體等級A-E[4]、IEC 61508的SIL（安全完整性等級，Safety Integrity Level）1-4[1]、ISO 26262的ASIL（車用安全完整性等級、Automotive Safety Integrity Level）A-D[2]。 一般會在系統層級指定安全等級，也會評估軟體失效的最壞後果。例如，車用標準ISO 26262要求在整車等級進行危害分析與風險評估（Hazard Analysis and Risk Assessment，簡稱HARA），以此推導某一元件上軟體的ASIL。
流程遵守與保證
在考慮軟體的安全性時，需要依軟體的安全關鍵程度，使用充足的開發流程以及驗證流程，配合適當的方法或是技術。軟體安全標準可能會建議一些方法或是技術，甚至強制使用特定方法或技術，視安全等級而定。 大部份的標準都會建議生命週期模型（像是EN 50716[3]、IEC 61508的SIL 1-4[1]會要求V模型），並且說明在軟體開發的不同階段需要進行的活動。例如，IEC 61508要求軟體需要有充份的規格說明（可能用型式方法或是半型式方法）、軟體設計需是模組化且可測試的、需使用有充份功能的程式語言、需進行文件化的程式碼評審、需有多層級的測試，以達到充夠的測試覆蓋率。
對軟體開發流程和驗證流程的注重是源自於一個事實：軟體品質（和安全）會高度的受到軟體流程的影響，如IEC 25010所述的一樣[11]。IEC 25010提出流程會影響內在的軟體品質屬性（程式碼品質），因此也會影響外在軟體品質屬性（像是功能性和可靠度）。
以下是一些安全軟體的開發流程中會提到的活動和概念。
在本質上，所有軟體安全標準都會要求針對開發流程和驗證流程全面且完整的文件。通常這些文件需經過第三方的評審和核可，是安全相關軟體核可的前提。文件包括許多的計劃文件、需求規格、軟體架構以及設計文件、不同抽象程度的測試案例、工具鑑定報告、評審證據、驗證和確認（verification and validation）結果等。在EN 50716的圖C.2[3]中列出在開發生命週期中需要創建的32份文件。
需求可追蹤性（Requirements traceability）是建立不同種類的需求之間的關係，需求和設計、實現和測試文件之間關係的實務。依照EN 50716[3]，其目的是「確保所有需求都已妥善滿足，沒有引入任何無法追蹤的東西」。透過建立可追蹤性的文件，並且維護，就可能讓一個安全需求對應到系統設計（以驗證設計時已有充份的考量）、再對應到軟體程式碼（以驗證程式碼符合需求）、以及適當的測試案例以及測試實做（驗證安全需求已被充份的測試）。
未解決的問題
相關條目
腳註
參考資料
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads