重用舊程式碼是現實，但是在安全關鍵型軟體專案中重用舊程式碼並實現MISRA C 2012的完全合規性是艱鉅的任務。
最初的MISRA原則是為了在開發程式碼時應用而建立的，即使文件本身也有警告：
“……在專案週期的後期檢查MISRA C符合性的專案可能會花費大量時間進行重新編碼、重新審查和重新測試。因此，預計軟體開發過程將需要儘早應用MISRA C原則。”
由於出於業務原因，許多組織確實需要重用其舊版程式碼庫，因此針對這些挑戰建立了MISRA 2016合規指南檔案。其中，在當前專案範圍內開發的新的本機程式碼與在專案範圍之外開發的“已採用”程式碼之間有明顯的區別。在這篇文章中，我解釋了一種處理遺留程式碼和MISRA C合規性的實用方法。
遵循MISRA準則的灰色陰影
儘管似乎很容易理解要處理的程式碼型別，但在很多情況下情況並非如此。例如，將不遵循MISRA準則開發的初始原型產品化，然後管理層意識到合規性是預期市場的要求。通常，遺留程式碼庫的開發從來沒有考慮任何編碼準則。因此，如果在新專案的上下文中需要更新，則無法將程式碼庫自動分類為“採用的程式碼”。這會變得很複雜。
通常，通過啟用了所有MISRA C 2012規則（包括修訂1）的靜態分析工具對大型程式碼庫進行的初始掃描會產生數以萬計的違規行為。在最初的震驚之後，團隊開始尋找解決衝突的“創造性”方法。重要的是，不要阻止開發團隊——隧道盡頭有陽光。
隨著時間的流逝，我已經收集並確定了開發團隊用來使程式碼合規而又不影響正在進行的開發速度的最佳實踐和方法。在本文中，我將分享一些實用且平衡的方法，以使現有程式碼庫符合MISRA。
使用MISRA Compliance: 2016框架
MISRA C 2012是用於C程式語言的一組編碼準則。該標準的重點是通過避免C語言中的已知問題構造，通過防止程式設計人員犯錯誤而導致執行時失敗（以及可能的安全問題），從而提高軟體的安全性。多年來，許多嵌入式系統開發人員一直（並且仍然）抱怨MISRA C對標準過於嚴格，並且編寫完全相容的程式碼的成本難以證明。實際上，鑑於MISRA C已應用在安全關鍵軟體中，因此將該標準應用於專案的價值取決於以下因素：
- 由於軟體故障而導致系統故障的風險
- 系統故障給企業造成的損失
- 開發工具和目標平臺
- 開發人員的專業知識水平
因此，程式設計師必須找到一種符合標準精神的實用中間立場，並且仍要聲稱自己符合MISRA，而不會浪費精力在非增值活動上。
在MISRA Compliance: 2016檔案中，MISRA聯盟提供了社群所需的響應，並提供了一個合理定義良好的框架，說明“符合MISRA”一詞的真正含義。該文件通過定義以下工件來幫助組織使用表達合規性要求的通用語言：
- 準則執行計劃——演示如何驗證每個MISRA準則。
- 準則重新分類計劃——在準則中傳達商定的各個規則的嚴重性，作為供應商/客戶關係的一部分。
- 偏差報告——以合理的理由記錄違反準則的情況。
- 準則合規摘要——是總體專案合規性的主要記錄。
為了專注於處理遺留程式碼庫，關鍵文件是指南重新分類計劃。本文件包含所有指令和規則，並確定已重新分類了哪些類別。例如，下圖顯示了重新分類計劃的一部分：
首先，對於“採用的”舊程式碼，《MISRA 2016: Compliance》文件建議不要從不太嚴格的分類到更嚴格的分類進行重新分類。此外，在與小組一起審查違規型別之後，也可以一起取消應用諮詢規則。
僅對於所有必需規則才需要記錄偏差。應該對所採用的規範中的任何違規行為進行審查，並且偏差必須清楚地表明違規行為不會損害安全性。不管重新分類如何，如果發現有損害系統安全性的問題，則必須解決此問題。同樣，對遺留程式碼的修改可能會引入其他問題，這些問題是開發人員無法清楚看到的。
以終為始
安全關鍵軟體開發人員遇到的關鍵問題是如何在專案結束時演示和證明合規性。如果評估標準基於各個利益相關者的主觀意見，那麼這可能是一個有爭議的問題，導致浪費時間和精力。在這種情況下，MISRA Compliance: 2016文件得以解決。
建議的改進對合規性準備情況評估的方法是將現有模板用於最終合規性和工具合格性報告。還有一種趨勢是向報告中新增比所需更多的資訊。如果標準不要求提供該資訊，請避免點綴。新增額外的資訊不僅浪費時間，而且存在延遲稽核過程的風險。
MISRA Compliance 2016提供了包含在最終報告中的必需資訊：
- 準則執行計劃
- 準則合規性摘要
- 所有批准的偏差許可證的詳細資訊
- 偏差記錄涵蓋了所有違反準則的情況，已按要求重新分類。
以下來自Parasoft工具的示例顯示了HTML格式，並帶有指向相應部分的連結：
儘早建立最終目標
除上述建議外，還需要考慮其他一些重要點：
- 在專案開始時是否制定了GRP（指南重新分類計劃）？根據MISRA標準，可以與收購方進行協商，也可以為所採用的程式碼建立多個GRP，這些程式碼無需進行任何修改就可以使用，而本機程式碼則是專案期間主動修改的。
- 對於每個增量更改，是否都存在要完全遵守法規的剩餘工作量？這有助於相應地計劃工作並與管理層建立正確的期望。
- 在專案開始時，是否已與採購方一起審查了GPS（指南符合性摘要）報告模板，這些模板是否被接受並完整？
商業靜態分析工具供應商（包括Parasoft）提供了這些文件的模板，以幫助組織滿足MISRA 2016合規性框架。
分階段實施：分而治之
儘管通過靜態分析工具對現有程式碼進行的初始掃描往往會產生數千個違規行為（尤其是在使用預設規則集時），但停止新的開發工作來集中精力解決所有這些違規行為是不切實際的。實際上，我已經看到在對程式碼庫進行重大更改以修復靜態分析違規時引入了迴歸的情況。因此，重要的是建立一個工作流來解決隨時間推移的違規問題，而又不影響開發流程和軟體質量。
下面列出了在專案中首次使用靜態分析工具時的一些關鍵建議：
- 基線。在對程式碼進行初始掃描之後，將所有初始違規標記為“稍後處理”，並設定為基準。從那時起，在更新現有程式碼和/或開發新程式碼時，應保持“不允許出現新的違規”政策。可以通過程式碼檢查過程或Jenkins或Bamboo等持續整合（CI）工具來實施此策略。當開發人員有幾個小時或幾天的空閒時間時，他們可以解決從基線標記的其餘違規情況。組織可以根據當前正在開發的程式碼，程式碼審查結果或依靠度量標準（例如複雜性）來建議下一個要解決的違規問題，從而優先考慮此方法。
- 線在“沙子”裡。開發確定了一個日期，即“界線”。在此日期之後，修改的每個翻譯單元（單個原始檔）都必須解決所有違規問題。所有未修改的翻譯單元都會自動歸入MISRA合規性文件中真實的“採用”程式碼定義之內。
- 基於嚴重性的優先順序。開發人員會修復分配給他們的模組的所有強制性發現。隨著時間的推移，他們會根據團隊負責人選擇的優先順序，在時間允許的情況下解決所有要求的違規行為。
對於上述任何一種方法，對於技術負責人和管理人員而言，通過集中式儀表板不斷監視進度和專案合規性狀態至關重要。例如，Parasoft的報告中心提供了以下預配置的合規性狀態儀表板：
工具資格
MISRA合規性的一個不太明顯的組成部分（通常留到專案結束時）是認識到產品中使用的開發工具需要針對預期用途進行資格驗證（已證明適合目的）。如果工具需要鑑定，則需要執行什麼級別的鑑定？
儘管在許多情況下需要工具鑑定，但用於進行工具鑑定的方法因與工具故障和軟體關鍵性等級相關的風險而異。Parasoft提供了針對特定安全標準及其要求的認證套件和認證。在缺少此高效工具包的情況下，軟體團隊在評估商業，免費和開源工具時必須考慮工具認證成本。
一些標準（例如ISO 26262和DO-178B/C）提供了有關工具鑑定要求的合理指導。無論採用哪種方法，工具鑑定過程的目標都是宣告“工具對預期用途有效”，並提供團隊如何得出此結論的證據和理由。
以下是一些建議的步驟，用於工具鑑定過程：
- 指定預期用途的工具要求
- 標識產品中使用的功能的子集。將認證過程簡化為僅使用的功能
- 概述資格計劃
- 概述驗證工具是否符合要求的一組資格驗證步驟（可能包括團隊執行的測試）
- 自動執行可以自動化的測試用例
- 提供一個框架來輸入手動測試步驟的結果
- 報告模板以減少開發人員需要輸入的文字量。
- 與利益相關者一起審查報告並簽字。
從一開始就忽視工具資格可能會導致專案週期延遲。
員工能力和培訓
開發人員的專業知識和培訓是軟體組織忽視的另一個關鍵因素，在評估產品的就緒狀態時，審計人員經常將其視為首要問題。
根據《MISRA指南》，員工能力是MISRA合規性的重要組成部分。最好在專案開始時進行培訓，並記錄培訓日期，所有開發人員都應簽字同意接受培訓。在專案結束時，開發團隊應該能夠證明：
- 批准偏差的工作人員瞭解並接受過培訓，可以認識到與違規有關的風險
- 人員經過培訓，可以在使用前正確配置和使用靜態分析和開發工具。
實際上，對經驗豐富的團隊的培訓相對較短，但是在錯過專案截止日期之後，在專案開始時投入幾天的時間就可以節省數週的返工。
總結
沒有任何捷徑可以使對安全至關重要的專案輕鬆實現對遺留程式碼的MISRA合規性。但是，正如本文所概述的那樣，隨著引入MISRA Compliance 2016框架，使用實用的分階段方法以及明確定義的終點（如本文所述），軟體開發團隊可以在不嚴重破壞其開發流程的情況下實現合規性。最重要的是，要實現合規性還需要進行大量工作，但是通過智慧計劃和正確的方法，可以建立起最小和平衡的任務集，以確保舊程式碼和新開發程式碼的安全。