翻譯|行業資訊|編輯:鄭恭琳|2020-05-22 17:17:05.933|閱讀 246 次
概述:編碼標準是良好軟件工程實踐的組成部分,使我們從“構建、失敗、修復”周期轉變為具有高質量、安全性和安全性的“設計、構建、交付”周期。本文將討論: 這些標準如何幫助我們從發現缺陷轉變為構建功能更強大的軟件。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關鏈接:
軟件從臺式機遷移到我們接觸的幾乎所有事物。從智能恒溫器到輸液泵再到汽車,軟件無處不在且在不斷發展。物聯網(IoT)中的所謂“事物”越來越多地帶有更多邏輯。有了它,更大的失敗風險。這些設備中的許多設備都被用于醫療和汽車等對安全至關重要的領域,有可能造成人身傷害。
大多數構建設備的公司都正確地將當前的軟件開發視為一群瘋狂的牛仔和混亂者,但是有希望。可以并且必須將軟件視為工程實踐。編碼標準是良好軟件工程實踐的組成部分,使我們從“構建、失敗、修復”周期轉變為具有高質量、安全性和安全性的“設計、構建、交付”周期。
事實證明,這些相同的標準還在網絡安全領域提供了雙重職責。這篇文章討論:
軟件對現實世界的影響通常是低估的。作為Parasoft的傳播者,我不斷討論的主要主題之一是軟件開發確實應該是工程設計。
我們經常由軟件工程師來稱呼軟件開發人員,但這不一定是他們今天工作方式的恰當術語。演變為良好的軟件工程實踐會導致成本下降和質量上升。其中的關鍵部分是采用標準,尤其是編碼標準。
互聯汽車、物聯網和永久互聯設備的時代在這里。軟件正在滲透到我們從未想到的產品、設備和其他地方。現在,我們必須認真考慮這些產品中的軟件及其后果。
我嘗試解釋的有趣的事情之一是,構建良好的軟件與構建汽車之類的東西不同。如果我要制造高質量的汽車,我必須花更多的材料和更多的時間來制造它。事實證明,在軟件中,您無需花費更多的時間來構建高質量的軟件。您花更多的錢來構建質量差的軟件。
我們必須了解,在軟件中,大多數缺陷來自程序員,后者將它們放入產品中。如果我們在開發軟件時能夠停止引入缺陷,那么我們可以以更低的價格獲得更好的軟件。
這句話引自Edsger W Dijkstra在1972年的一次演講,名為“謙虛的程序員”。今天仍然非常重要。
重要的是要意識到質量如何影響軟件開發成本。研究人員Capers Jones已經關注了數十年,并每年進行一次軟件成本調查。這些數字每年變化不大。數據顯示,從需求到編碼再到維護的每個階段,軟件的典型成本都會增加。但是,團隊對待質量的方式決定了他們的過程是健康的還是“病態的”。
有道理的是,如果我們在編寫代碼時就發現缺陷,那么成本就相對便宜了——例如,開發人員只需幾分鐘的時間。如果可以在開發階段消除85%的缺陷,那么對成本的影響就很大。考慮一下現在著名的Capers Jones圖表,它顯示了在每個開發階段修復缺陷的平均成本:
根據對使用真實軟件而不是理論模型的真實公司的研究,修復發布后的缺陷大約需要16000美元(可能更多)。如果我們查看周期后期的質量和安全性工作(例如滲透測試),則此處發現的安全性問題處于周期的昂貴末端。通過測試與早期安全審核相比,查找漏洞的成本可能高出15倍。
一種過時且可證明是錯誤的方法是通過在生命周期的結尾(即發行前)進行測試來提高軟件的質量。在制造業中,他們知道這是不可能的,但是出于某些原因,我們認為我們可以測試“進入”軟件的質量(和安全性)。
我之所以說軟件開發幾乎絕不是工程學,是因為當前軟件開發具有以下共同特征:
軟件編碼標準的目標是灌輸經過驗證的編程實踐,以產生安全,可靠,可測試和可維護的代碼。通常,這意味著避免使用已知的不安全編碼做法或可能導致不可預測行為的代碼。這對于像C和C++這樣的編程語言至關重要,因為在這些語言中,編寫不安全或不安全代碼的可能性很高。
但是,我認為行業在使用這些編程標準時已迷失了方向。在過去的十年中,這些工具(例如靜態分析工具)已經從檢測不安全的潛在問題代碼或已知的語言弱點轉變為以早期測試的形式尋找缺陷,也稱為左移。
盡管尋找缺陷很重要,但是開發完善的軟件是一項更具生產力的活動。我們應該做的是建立和執行標準,以避免出現缺陷首先出現的情況,即向左移動更遠。
作為支持,請考慮軟件工程研究所(SEI)所做的研究,他們毫不奇怪地發現,安全性和可靠性是緊密相連的,并且可以通過發現的質量缺陷的數量和類型來預測軟件的安全性。此外,關鍵缺陷通常是編碼錯誤,可以通過檢查和工具(例如靜態分析)來避免。
行業標準
這篇文章沒有詳細介紹每種編碼標準,但是在以下行業標準中有大量工作要做。盡管它們的應用可能特定于特定類型,但這些標準已在許多行業中得到采用。以下是一些已建立的安全性編碼標準示例。
讓我們考慮一下MISRA C,我提到的它不僅是用于汽車應用。但是,該標準自1998年以來一直在使用,并且定義明確。他們每兩年進行一次更新。隨著C和C++語言的發展,它們圍繞著它發展了標準。這是一個非常靈活的標準,其中考慮了不同的嚴重性級別,并且有成文的策略來處理和記錄偏差。
作為可以檢測違反編碼標準準則的技術(例如靜態分析),MISRA的最新版本考慮了哪些準則是可以確定的(可以用工具高精度地檢測到),而哪些不是。這使我們想到了采用和強制執行以及靜態分析工具在編碼標準中的重要性。
靜態分析的作用
研究表明,缺陷清除不足是軟件質量低下的主要原因。程序員發現自己軟件中的缺陷的效率約為35%。在開發周期的后期,在所有設計評審、同行評審、單元測試和功能測試之后,我們希望消除的大多數缺陷約為75%。
如果在預防模式下正確使用靜態分析,則可以將缺陷清除率提高到大約85%。但是,當今大多數組織使用靜態分析的重點是檢測和快速修復。
首先使用靜態分析工具來防止已知的不良編程習慣和語言功能,可能會帶來進一步的好處。在這里,編碼標準將作為指導原則和編程語言子集發揮作用,以防止將諸如緩沖區溢出或缺少初始化之類的常見缺陷寫入代碼中。
只需一點預防
考慮一個示例,在該示例中,可能使用動態應用程序安全工具(DAST)檢測到一個相當復雜的緩沖區溢出錯誤。運氣不好,因為您的測試剛好執行了包含錯誤的代碼路徑。一旦被檢測和調試,就需要重新測試等等。使用流分析的靜態分析可能也發現了此錯誤,但這取決于應用程序的復雜性。
運行時錯誤檢測非常精確,但是它僅檢查您執行的代碼行。因此,它僅與測試代碼覆蓋率一樣好。考慮一下編碼標準是否首先禁止了導致此錯誤的代碼。
像MISRA C這樣的編碼標準并沒有描述例如如何檢測未初始化的內存,而是指導程序員編寫首先不會導致這種錯誤的代碼。我相信這更多是一種工程方法:根據眾所周知的公認標準進行編程。以土木工程和建筑橋梁為例。
我們不會采取建造橋梁的方法,而是先通過越來越大的卡車來測試它,直到它倒塌,再測量最后一輛成功使用的卡車的重量,然后再次建造以承受新的重量。這種方法還是很愚蠢的,與我們進行軟件開發的方法沒有什么不同。
一旦軟件團隊采用編碼標準并正確應用了靜態分析,他們就可以及早發現錯誤并加以預防。換句話說,團隊正在改變編寫代碼的方式,這更好,而不是盡早發現缺陷,這是好的!
考慮Heartbleed漏洞。現在有針對此特定漏洞實例的檢測器,但有一種方法可以編寫代碼,從而使Heartbleed永遠不會發生。預防是一種更好、更安全的方法。
Dykstra說:“那些想要真正可靠軟件的人會發現,他們必須找到避免大多數bug的方法。”擁有可靠的預防方法比修復這些錯誤的成本要少。
編碼標準體現了以其相應語言進行編程的合理的工程原理,并構成了任何預防方法的基礎。好的軟件的成本小于劣質的軟件的成本。如果您今天不使用靜態分析,或者僅將其用于早期檢測,請查看Parasoft的C和C++,Java,C#和VB.NET靜態分析工具,其中包含豐富的檢查程序庫內置了流行的安全標準。
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn