作者：CHRIS TAPP，JAY THOMAS

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

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

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

保護嵌入式系統(tǒng)

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

這些要求不能是事后的想法，而必須從頭開始構(gòu)建。它們還經(jīng)常要求軟件遵守某些編碼準(zhǔn)則，如MISRA或CERT C，并且必須遵循工業(yè)或政府規(guī)定的標(biāo)準(zhǔn)，如DO-178C。隨著這些系統(tǒng)越來越受到認證要求的約束，必須證明和記錄編碼和功能的正確性。

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

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

建立和實施安全性

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

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

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

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

靜態(tài)和動態(tài)分析：安全合作伙伴

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

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

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

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

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

自動測試生成基于代碼的靜態(tài)分析，并在動態(tài)分析期間使用此信息來確定對應(yīng)用程序中軟件組件的適當(dāng)激勵?；具吔缰禍y試的這一支柱可以通過從需求文檔手動創(chuàng)建的功能測試輕松擴展。這些應(yīng)包括任何功能安全測試，例如模擬嘗試訪問控制設(shè)備或向其提供會改變其任務(wù)的錯誤數(shù)據(jù)。此外，基于創(chuàng)建的測試的功能測試應(yīng)包括穩(wěn)健性，例如測試不允許的輸入和異常條件的結(jié)果。

深入了解代碼

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

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

因此，靜態(tài)分析的功能是分析源代碼以獲得正確的編程實踐，還可以幫助為覆蓋率測試、功能測試、控制和數(shù)據(jù)流分析設(shè)置動態(tài)分析。后者對于突出和糾正潛在的問題領(lǐng)域并產(chǎn)生軟件質(zhì)量指標(biāo)至關(guān)重要。

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

從單元測試開始并發(fā)展項目

除非可以從頭開始進行測試，否則從頭開始考慮和開發(fā)安全性沒有多大幫助 - 這包括在目標(biāo)硬件可用之前在主機開發(fā)系統(tǒng)上進行測試。在這個階段，沒有人在談?wù)擁椖拷咏瓿傻碾A段，因此通?？梢赃M行早期單元測試，然后進行集成測試，因為任務(wù)來自不同團隊或開發(fā)人員。

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

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

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

將全面的測試和分析框架應(yīng)用于組織的開發(fā)過程，可以大大提高安全措施的徹底性和準(zhǔn)確性，以保護重要系統(tǒng)。

審核編輯：郭婷