作者：CHRIS TAPP，JAY THOMAS

經過適當測試和驗證的安全編碼實踐有助于確保軍事系統的可靠和安全運行。組織應從頭開始，結合使用靜態和動態分析、單元和集成測試以及需求可追溯性。

軍事系統中的安全漏洞可能是毀滅性的。具有嚴重后果的安全中斷的一個例子是據稱在2011年由中央情報局在伊朗上空捕獲的美國RQ-170無人機（UAV）。據伊朗稱，該飛船被伊朗網絡戰部隊安全降落，并設法接管了它。斷言是，無人機是通過干擾衛星和陸地控制信號捕獲的，隨后是GPS欺騙攻擊，該攻擊向無人機提供虛假的GPS數據，使其降落在伊朗，無人機認為是其在阿富汗的大本營。

雖然實際細節可能永遠不清楚，但似乎無人機確實受到了損害，以至于它可以安全地降落在伊朗境內，并被敵人擁有以進行可能的逆向工程。該無人機軟件中的某些內容允許訪問系統的至少一部分，這顯然打開了對其重要內部的訪問。

保護嵌入式系統

嵌入式系統現在滲透到軍隊中，從車輛控制、通信、武器控制和制導到自主和半自主系統，包括無人機和類似飛行器。這些設備現在相互連接，用于控制和協調目的。為了人員安全、完成任務的能力以及通常的國家安全，這些設備必須對其操作員安全且操作可靠。此外，它們必須免受未經授權的訪問和攻擊。如果它們不安全，則不能認為它們是安全或可靠的。因此，對安全性、可靠性和安全性的要求是不可分割和相互依存的。

這些要求不能是事后的想法，而必須從頭開始構建。它們還經常要求軟件遵守某些編碼準則，如MISRA或CERT C，并且必須遵循工業或政府規定的標準，如DO-178C。隨著這些系統越來越受到認證要求的約束，必須證明和記錄編碼和功能的正確性。

盡管有許多策略可用于實現安全性，但仍有必要確保這些策略也正確編碼 - 無論是在編碼標準方面還是在整個應用程序中的正確功能方面。傳輸層安全性 （TSL） 等傳輸協議 – 這是對安全套接字層 （SSL）、安全文件傳輸協議 （SFTP） 和其他協議的改進 – 現在被廣泛使用，但通常從組織外部獲取。其他策略可能包括使用安全設備驅動程序、遠程實施安全和加密固件升級的過程，以及個人驗證協議，如密碼、視網膜掃描和射頻識別 （RFID） 芯片，以確保訪問安全。其他分層安全策略僅允許對系統部分進行選定訪問，但這些策略也可能引入漏洞，如果未檢測到，這些漏洞可能會被利用。

過去，組織可能已經能夠通過手動代碼審查和軟件演練來檢查其代碼。然而，當今關鍵程序的規模和復雜性使得使用這種方法和手段無法確保完整的分析。需要一套新的測試和分析工具及方法來滿足當今的安全要求。

建立和實施安全性

當今全面的工具套件在單個開發環境中集成了用于測試、分析和驗證的工具。使用工具環境還可以幫助在組織內建立一種規范的方法，該方法可以幫助團隊協作，即使他們可能在不同的位置工作。

為了滿足認證或資格要求，實現雙向需求可追溯性的工具（從需求和設計到實施、驗證活動和工件）可以使組織與競爭對手區分開來，并確保獲得設備批準的最短路徑。需求管理工具允許團隊處理單個活動，并將代碼和驗證工件鏈接回更高級別的目標。

需要基于需求文檔的雙向可追溯性，以確保一個或多個低級別需求涵蓋每個高級需求，并且每個低級別需求都可以追溯到高級需求。

除此之外，還需要這些工具來執行基于靜態分析、動態覆蓋分析和單元/集成測試的廣泛基礎測試。這些結果有助于確保安全性、功能安全性和符合編碼標準，以及跟蹤需求并通過廣泛測試確保它們是否實際按預期運行的能力。

靜態和動態分析：安全合作伙伴

在確保安全方面，兩個主要問題是數據和控制。設計人員必須考慮誰有權訪問數據、誰可以從數據中讀取/寫入、數據如何流動以及不同級別的訪問和控制。為了解決這些問題，靜態和動態分析必須同時進行。

在靜態分析方面，這些工具使用未編譯的源代碼來檢查代碼與所選規則，這些規則可以是支持的標準以及開發人員或公司可能指定的任何自定義規則和要求的任意組合。這些工具還可以查找可能危及安全性的軟件結構，檢查內存保護以確定誰有權訪問內存的哪些部分，以及跟蹤可能遍歷內存位置的指針。為了獲得最佳結果，信息應以圖形屏幕顯示，以便于評估，以確保符合編碼標準。

動態分析測試編譯的代碼，該代碼使用編譯器生成的符號數據鏈接回源代碼。動態分析，尤其是代碼覆蓋率分析，需要大量的測試。開發人員可能能夠手動生成和管理自己的測試用例（生成測試用例的典型方法），從需求文檔開始工作，該過程可能會以不同程度的有效性刺激和監視應用程序的各個部分。然而，鑒于當今代碼的大小和復雜性，這種方法通常不足以獲得某些必需的認證。

圖1：LDRA 工具套件的動態分析功能可生成基于當前測試運行的變量和參數使用情況報告。該報告突出顯示了文件中使用該變量的文件和位置，并使用自定義篩選器進行了更精細的測試。

安全性需要對功能漏洞進行嚴格而徹底的測試，以及遵守正在運行的應用程序中的編碼規則和指令。如果覆蓋率分析要求包括語句或分支/決策覆蓋率、過程/函數調用覆蓋率，或者在更嚴格的環境中，修改條件/決策覆蓋率 （MC/DC） — 則這些通常需要源代碼和目標代碼分析。它還可能需要自動生成測試，作為衡量測試有效性的一種手段（圖 1）。

自動測試生成基于代碼的靜態分析，并在動態分析期間使用此信息來確定對應用程序中軟件組件的適當激勵。基本邊界值測試的這一支柱可以通過從需求文檔手動創建的功能測試輕松擴展。這些應包括任何功能安全測試，例如模擬嘗試訪問控制設備或向其提供會改變其任務的錯誤數據。此外，基于創建的測試的功能測試應包括穩健性，例如測試不允許的輸入和異常條件的結果。

深入了解代碼

發現安全漏洞可能涉及更微妙的問題。例如，存在與“死”代碼區域相關的危險，這些代碼可能被黑客激活或系統中的模糊事件用于惡意目的。盡管從頭開始實現安全性是理想的，但大多數項目都包含預先存在的代碼，這些代碼可能沒有經過與當前項目相同的嚴格測試。靜態和動態分析一起使用可以揭示死代碼區域，這些區域可能是危險源或可能占用所需空間。

區分真正死代碼和很少使用的代碼的能力是雙向需求可追溯性很重要的另一個原因;為了能夠檢查應用程序中的代碼是否滿足需求，還可以從實際代碼中將代碼追溯到實際需求。如果這些路由都沒有顯示連接，則代碼肯定不屬于那里。

因此，靜態分析的功能是分析源代碼以獲得正確的編程實踐，還可以幫助為覆蓋率測試、功能測試、控制和數據流分析設置動態分析。后者對于突出和糾正潛在的問題領域并產生軟件質量指標至關重要。

為滿足機載或作戰系統的嚴格安全要求而開發的公司可能需要展示對數據流和控制流的分析，以進行軟件認證。在根據DO-178C認證機載軟件和系統的情況下，需要在對象級別進行驗證。這涉及將源代碼級別的代碼覆蓋率與目標代碼級別的代碼覆蓋率相關聯的能力。在某些情況下，可能還需要提供在匯編程序級別擴展代碼覆蓋率的機制。此擴展對于 DO-178C A 級認證特別有用，其中軟件故障可能導致飛機損失和/或生命損失。

從單元測試開始并發展項目

除非可以從頭開始進行測試，否則從頭開始考慮和開發安全性沒有多大幫助 - 這包括在目標硬件可用之前在主機開發系統上進行測試。在這個階段，沒有人在談論項目接近完成的階段，因此通常可以進行早期單元測試，然后進行集成測試，因為任務來自不同團隊或開發人員。

此方法也適用于可能從頭開始編寫、從其他項目引入、作為商業產品購買或作為開源獲得的代碼部分。即使是內部代碼也需要檢查，因為它最初可能沒有經過相同的分析。使用單元測試工具的決定歸結為商業決策：產品開發中發現缺陷的時間越晚，修復成本就越高（圖 2）。

圖2：在開發周期的后期，修復缺陷的成本急劇增加。

可以在不考慮硬件時序的情況下完成主機上的功能測試，在某些情況下，可以在具有模擬連接的外圍設備的基于主機的虛擬目標上執行。在主機上執行的相同測試也必須在目標硬件上執行，以確保正確的功能測試。

將全面的測試和分析框架應用于組織的開發過程，可以大大提高安全措施的徹底性和準確性，以保護重要系統。

審核編輯：郭婷