Products 產品資訊
Code Intelligence (汽車Fuzz)

https://www.code-intelligence.com/

 

 

 

 

Code Intelligence

 

 

Fuzz Test for Automotive Software

 

 

 

 

 

 

 

 

Code Intelligence 提供了一個強大的軟體安全檢測平台,可以幫助開發人員在完成產品系統的開發之前就能夠事事先找到並修復漏洞。 許多大公司已經使用我們的技術來保護其軟件。 Code Intelligence還與開源社區密切合作,使安全的代碼得到廣泛傳播。 

 

由於新的 ISO/SAE 21434,許多汽車製造商 (OEM) 正在擴大其軟件測試活動。 該標準包含對車輛內軟件設備及其與外部系統的連接的規定。 該 ISO 建議 OEM 將基於反饋的模糊測試集成到 DevOps 流程中,並定義軟件安全工程的新要求。  

 

模糊測試或模糊測試是一種自動化安全測試技術,涉及提供無效、意外或隨機數據作為計算機程序的輸入。 然後監視程序是否存在異常,例如崩潰、內置代碼斷言失敗或潛在的內存洩漏。 模糊測試的主要優點之一是它可以在開發期間完成,類似於動態應用程序安全測試(DAST)和交互式應用程序安全測試(IAST)。

 

共同的挑戰


作為一名每天與汽車客戶打交道的客戶成功工程師,我看到開發人員和安全團隊在為其汽車軟體實施模糊測試時面臨三個主要挑戰。

 

1. 從哪裡開始模糊測試?


當開發人員第一次實施模糊測試時,他們通常以較低的預算開始,幾乎沒有模糊測試經驗,也沒有專業支援。 此外,他們經常感到很大的壓力,因為他們的第一個模糊測試項目必須取得良好的結果。 因此,選擇正確的項目開始至關重要。

 

2. 如何對具有依賴關係的複雜系統進行模糊測試?


現代車輛中的資訊娛樂系統通常與各種外部感測器進行通訊。 程式碼很快就會變得混亂和複雜。 軟體中的依賴性使得開發人員很難正確地對應用程式進行模糊測試,並且手動工作量仍然非常高。 因此,您的長期目標應該是持續模糊應用程式並同時模擬這些嵌入式系統的輸入。 這樣,您將能夠比傳統 DAST 或 IAST 更自動化地實現測試過程,並實現更高水準的程式碼覆蓋率。

 

3. 如何將模糊測試整合到CI/CD中?


將模糊測試整合到 CI/CD 中可以幫助擴大該方法的優勢。 但對於成功的整合,溝通才是關鍵。 開發人員、安全專業人員和管理人員應該就這些變更的影響以及它們如何影響某些流程達成共識。


本文是汽車安全測試系列的一部分,我將在其中討論所有三個問題。 有關如何建立安全汽車軟體的更多文章,請查看程式碼智慧 - 安全部落格。 在本文中,我現在將主要關注這個問題:“從哪裡開始模糊測試?”

 

建議:從簡單開始


從簡單開始,然後繼續應對更複雜的挑戰。 開發人員(包括我自己)有時傾向於從最複雜的專案或可能出現最多錯誤的專案開始。 但我的經驗是,當涉及模糊測試時,保持簡單通常會更好。

 

例如,我始終建議使用已經經過安全專家測試的簡單 C/C++ 程式庫開始模糊測試汽車軟體。 透過這種方式,您可以更好地感受模糊測試過程。 稍後,您可以逐步進行更複雜的專案。

 

在許多情況下,模糊測試會在這些已經測試過的 C/C++ 程式庫中發現許多新的 bug,即使您認為這段程式碼是安全的。 (太棒了,第一次成功!但是請對上次測試此程式碼的人保持溫和。記住......自動錯誤查找也有一個人為因素。)

 

成功模糊測試的路線圖(針對汽車)


我始終建議汽車開發人員透過三個簡單的步驟實施模糊測試。 每踏出一步,您都會對自己所做的事情變得更加自信和熟練。 這樣您將獲得最佳結果。 每一個小小的成功都會引導您採用更先進的模糊測試方法,幫助您提高軟體的安全性。

 

單元模糊測試、介面模糊測試、系統模糊測試

*點擊放大

 

第 1 步:單元模糊測試


當最初在汽車環境中設定模糊測試時,最簡單的方法是使用預先存在的單元測試作為一種模板。 在大多數專案中,這些單元測試已經存在,因為許多汽車開發人員使用單元測試來測試其軟體的功能。

 

在設定模糊器後的最初幾個小時內,您通常只需使用這些獨立單元進行測試即可檢測到大多數安全問題。 這些唾手可得的成果的理想候選者是函式庫、API 函數和不同類型的解析器。

 

在此階段,您還可以非常輕鬆地設定持續集成,只需對每個即將到來的合併請求重複此已定義的過程(類似於 DAST 或 IAST)。

 

第 2 步:介面模糊測試


在網路層面,模糊測試需要更多的努力,因為必須考慮不同的網路介面協定(TCP/IP、乙太網路、CANBus 等)。 為了模擬這一點,模糊測試引擎必須能夠理解某些協議,例如 IPSec、UDS 和 Protobuf。 這就是為什麼,介面模糊測試可能需要幾天到幾週的時間,但隨著複雜性的增加,您也會發現更多的錯誤。

 

如果您在單元測試模糊測試之前開始進行介面模糊測試,那麼您很可能還會偵測到透過單元測試模糊測試所能偵測到的所有結果。 但是,當透過介面模糊測試發現錯誤時,您可能需要更多時間來偵錯和分析錯誤。 因此,通常最好先從單元模糊測試開始。

 

第 3 步:系統(類似)模糊測試


特別是在汽車和複雜的嵌入式專案中,系統模糊測試是長期目標。 在某個時刻,所有測試都應該連接到硬件,以了解商業編譯器在作業系統上實際發生的情況。 幸運的是,可以模擬這些系統的輸入。 在單元測試期間建立的模擬可以作為測試實際硬體的基礎。