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

---

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

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

但是，所有這些都有風險。可以利用軟件安全漏洞來獲得對任何系統(tǒng)的特權訪問。這可能意味著簡單的黑客行為，例如在我們不期望的時候關掉燈，或者發(fā)出更多令人震驚的攻擊，例如用攝像機監(jiān)視我們，或者在我們不知情或未經(jīng)許可的情況下清空我們的銀行帳戶。即使沒有網(wǎng)絡犯罪分子的參與，導致應用程序出現(xiàn)不良行為的軟件錯誤也會引起類似的問題。由于這些原因，軟件安全對于世界各地的公民而言已成為頭等大事。

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

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

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

功能安全標準

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

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

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

（安全）編碼標準

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

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

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

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

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

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

如何選擇正確的編碼標準

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

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

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

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

選擇編碼標準和適當?shù)墓ぞ吆螅瑢τ趶念^開始的軟件項目，應該容易做更多的工作——只需將工具與CI系統(tǒng)集成在一起，并確保沒有任何缺陷。但是通常，編碼標準需要在已經(jīng)開發(fā)的軟件上執(zhí)行。

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

另一個好的做法是對報告的缺陷進行優(yōu)先級排序，以確保首先處理最嚴重的缺陷。例如，CERT C和C++規(guī)則具有與之關聯(lián)的風險評估，從而可以輕松區(qū)分發(fā)現(xiàn)的缺陷的優(yōu)先級。

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

結論

最重要的部分是確保開發(fā)團隊采取適當?shù)拇胧﹣磉M行分析。如果開發(fā)人員不使用它們來修復代碼，則靜態(tài)分析的報告有多好無關緊要，從而可以提供更安全的軟件產(chǎn)品。花時間選擇正確的靜態(tài)分析解決方案和編碼標準將使您踏上成功之路。