采用嵌入式安全編碼標準的第一步

---

有太多以安全性為重點的編碼實踐和標準（即CERT，OWASP，CWE，MISRA，AUTOSAR以及基于IEC 61508的整個標準系列）。您如何確定適用于您的特定項目的一組編碼標準？本指南將帶您開始前進。

軟件在我們的日常生活中越來越重要。日常設備中裝有軟件，例如汽車、電話、冰箱、手表、醫療設備或飛機。從銀行或保險公司到能源工廠或交通控制系統，我們所依賴的組織都依賴可靠的軟件。該軟件的存在為我們提供了很多機會——居住在智能家居中，駕駛智能汽車以及我們的智能手機和智能手表為我們提供所需的一切，隨著越來越多的這些元素相互聯系，我們可以增加更多的收益和效率，讓我們的生活變得更加輕松。

但是，所有這些都有風險?？梢岳密浖踩┒磥慝@得對任何系統的特權訪問。這可能意味著簡單的黑客行為，例如在我們不期望的時候關掉燈，或者發出更多令人震驚的攻擊，例如用攝像機監視我們，或者在我們不知情或未經許可的情況下清空我們的銀行帳戶。即使沒有網絡犯罪分子的參與，導致應用程序出現不良行為的軟件錯誤也會引起類似的問題。由于這些原因，軟件安全對于世界各地的公民而言已成為頭等大事。

安全編碼：從CVE到CWE前25名

1999年，MITRE Corporation（一家由聯邦政府贊助的運營研究與開發中心的美國非營利組織）開始在“常見漏洞和披露（CVE）”列表中記錄已知的軟件安全漏洞。最初的列表包含321個CVE條目，但增長迅速，目前（截至2018年9月），CVE列表包含100,000多個條目，并由92個CVE編號頒發機構（CNA）維護——來自世界各地的不同組織（漏洞研究人員、產品供應商和錯誤賞金計劃），這些漏洞研究人員已被授權將CVE ID分配給檢測到的問題。美國國家標準與技術研究院（NIST）、美國國防信息系統局（DISA）等推薦該清單，使用范圍非常廣泛。

MITRE公司希望使人們更容易理解最常見問題的根源，并采取適當的措施避免以后再出現類似的問題，因此他們根據問題的類型將CVE條目歸類，最后以CVE的發布為準。研究人員漏洞示例初步列表（PLOVER）文件。將此工作與其他研究結合起來，可以定義通用弱點枚舉（CWE）列表，它是軟件弱點類型的正式列表。當前，CWE列表版本3.1包含大約800種弱點類型，分為300個類別和視圖。由于這個數字可能不勝枚舉，因此CWE與SANS Institute共同維護“Top 25最危險的軟件錯誤”列表，以維護可能導致軟件嚴重漏洞的最廣泛和最嚴重的錯誤。例如，當前“Top 25”列表的頂部包括SQL注入、OS命令注入、緩沖區溢出和跨站點腳本。

功能安全標準

對于安全性比其他行業更為重要的行業（例如，機載、汽車或醫療保健系統與電視或其他娛樂系統），國際電工委員會（IEC）開發了IEC 61508：電氣/電子/可編程功能安全性電子安全相關系統。IEC 61508是用于各種行業的通用標準，但以下也是專用于特定行業的標準，例如：

• 機載：DO-178C / ED-12C
• 汽車：ISO 26262
• 鐵路：IEC 62279 / EN 50128
• 核電站：IEC 61513

這些標準考慮了給定領域的細節，但是它們的總體思想（至少從軟件角度而言）非常相似。所有這些都需要（除其他驗證技術之外）對已開發的代碼執行靜態分析，并且它們為需要執行的操作提供了一些高級指導，同時還留有很大的解釋空間。它們通常不命名要使用的任何特定編碼約定或編碼標準，而是例如。ISO 26262提到MISRA C作為C編程語言的編碼指南示例。

（安全）編碼標準

編寫安全代碼意味著編寫不會受到攻擊的代碼，即不包含可能被利用的弱點的代碼。這意味著編寫符合某些“安全”模式的代碼以及避免“不安全”模式的代碼。對于不同的編程語言，這些模式也會有所不同。當然，沒有任何一套可以遵循的規則來保證軟件的安全性。一些廣泛考慮安全性的編碼標準包括：

• 對于C語言：MISRA C，SEI CERT C編碼標準
• 對于C++語言：MISRA C++，JSF AV C++編碼標準，SEI CERT C++編碼標準，AUTOSAR C++編碼準則

MISRA C和MISRA C++標準是由汽車工業軟件可靠性協會（MISRA）開發的。 AUTOSAR C++編碼準則由AUTOSAR（汽車開放系統架構）開發合作伙伴關系開發。 JSF A V C++編碼標準是由洛克希德·馬丁公司開發的。SEI CERT C和C++編碼標準包含旨在確保以C和C++編程語言開發的軟件系統的安全性、可靠性和安全性的通用規則。

這些標準中的規則通常分為多個類別，以使導航更加容易，因為給定標準中的規則數量可能非常大，例如：

• MISRA C 2012擁有173條指南，156條規則和17條指令
• CERT C有307條指南，121條規則和186條建議
• AUTOSAR有344條指導原則，其中有319條要求和25條“建議”
• CERT C++具有163條準則，其中包含83條C++規則和80條相關C規則

考慮到許多不同的功能安全標準，編碼標準以及每種標準推薦或要求的指導原則的數量，在啟動使代碼安全的計劃時，做出正確的選擇很重要。

如何選擇正確的編碼標準

如果需要根據特定的功能安全標準（例如，汽車的ISO 26262或機載的DO-178C）對軟件進行認證，則已經做出了初步決定。但是無論如何，都需要做出選擇以確定要在開發的軟件上實施的一個或多個編碼標準或標準或該標準的子集。它可以但不一定是上述標準之一。

接下來，由于無法手動驗證是否符合所有這些規則，因此需要選擇適當的靜態代碼分析工具。有開源和商業靜態分析工具。挑選一個好人很重要。應該考慮的一些因素是：

• 該工具是否完全或部分支持所選的編碼標準？
• 如果功能安全標準要求工具合格，那么該工具是否通過認證？是否提供資格鑒定工具？
• 該工具能否以進行合規性分析所需的形式生成分析報告？
• 該工具能否以開發人員易于閱讀的形式生成分析報告？
• 該工具是否與使用過的IDE，構建和CI系統完美集成？
• 該工具是否允許對新代碼，更改的代碼或舊代碼進行選擇性分析？
• 該工具是否支持靈活的分析配置？
• 該工具是否利用風險評分算法來幫助對發現的缺陷進行優先級排序？

此外，CWE社區推動了CWE兼容性和有效性計劃，該計劃是對產品或服務的正式審查和評估過程。“與CWE官方兼容”的產品和服務列表當前包含55個條目。使用此列表中的工具可確保它已達到MITRE正式CWE兼容性計劃的最后階段。

選擇編碼標準和適當的工具后，對于從頭開始的軟件項目，應該容易做更多的工作——只需將工具與CI系統集成在一起，并確保沒有任何缺陷。但是通常，編碼標準需要在已經開發的軟件上執行。

在這種情況下，在整個代碼庫上盲目執行分析可能會報告數百個缺陷，這些缺陷很難一起處理。幸運的是，可以使用多種技術來簡化此過程。例如，您可以首先關注新編寫或修改的代碼，以確保從建立編碼標準的那一刻起至少不引入新的缺陷。

另一個好的做法是對報告的缺陷進行優先級排序，以確保首先處理最嚴重的缺陷。例如，CERT C和C++規則具有與之關聯的風險評估，從而可以輕松區分發現的缺陷的優先級。

完善的靜態分析工具還可以幫助您首先關注具有最高嚴重性的規則，隨著更嚴重的缺陷得到修復，可以增加正在關注的規則的數量。

結論

最重要的部分是確保開發團隊采取適當的措施來進行分析。如果開發人員不使用它們來修復代碼，則靜態分析的報告有多好無關緊要，從而可以提供更安全的軟件產品。花時間選擇正確的靜態分析解決方案和編碼標準將使您踏上成功之路。