軟件從臺式機遷移到我們接觸的幾乎所有事物。從智能恒溫器到輸液泵再到汽車，軟件無處不在且在不斷發(fā)展。物聯(lián)網(wǎng)（IoT）中的所謂“事物”越來越多地帶有更多邏輯。有了它，更大的失敗風險。這些設(shè)備中的許多設(shè)備都被用于醫(yī)療和汽車等對安全至關(guān)重要的領(lǐng)域，有可能造成人身傷害。

大多數(shù)構(gòu)建設(shè)備的公司都正確地將當前的軟件開發(fā)視為一群瘋狂的牛仔和混亂者，但是有希望。可以并且必須將軟件視為工程實踐。編碼標準是良好軟件工程實踐的組成部分，使我們從“構(gòu)建、失敗、修復”周期轉(zhuǎn)變?yōu)榫哂懈哔|(zhì)量、安全性和安全性的“設(shè)計、構(gòu)建、交付”周期。

事實證明，這些相同的標準還在網(wǎng)絡(luò)安全領(lǐng)域提供了雙重職責。這篇文章討論：

• 這些標準如何幫助我們從發(fā)現(xiàn)缺陷轉(zhuǎn)變?yōu)闃?gòu)建功能更強大的軟件。
• 首先如何通過正確的編碼來防止問題。
• 如何通過使用諸如MISRA之類的公認行業(yè)標準來利用他人的努力來實現(xiàn)此目標。

從軟件開發(fā)到軟件工程

軟件對現(xiàn)實世界的影響通常是低估的。作為Parasoft的傳播者，我不斷討論的主要主題之一是軟件開發(fā)確實應(yīng)該是工程設(shè)計。

我們經(jīng)常由軟件工程師來稱呼軟件開發(fā)人員，但這不一定是他們今天工作方式的恰當術(shù)語。演變?yōu)榱己玫能浖こ虒嵺`會導致成本下降和質(zhì)量上升。其中的關(guān)鍵部分是采用標準，尤其是編碼標準。

互聯(lián)汽車、物聯(lián)網(wǎng)和永久互聯(lián)設(shè)備的時代在這里。軟件正在滲透到我們從未想到的產(chǎn)品、設(shè)備和其他地方。現(xiàn)在，我們必須認真考慮這些產(chǎn)品中的軟件及其后果。

質(zhì)量差的代價

我嘗試解釋的有趣的事情之一是，構(gòu)建良好的軟件與構(gòu)建汽車之類的東西不同。如果我要制造高質(zhì)量的汽車，我必須花更多的材料和更多的時間來制造它。事實證明，在軟件中，您無需花費更多的時間來構(gòu)建高質(zhì)量的軟件。您花更多的錢來構(gòu)建質(zhì)量差的軟件。

我們必須了解，在軟件中，大多數(shù)缺陷來自程序員，后者將它們放入產(chǎn)品中。如果我們在開發(fā)軟件時能夠停止引入缺陷，那么我們可以以更低的價格獲得更好的軟件。

這句話引自Edsger W Dijkstra在1972年的一次演講，名為“謙虛的程序員”。今天仍然非常重要。

重要的是要意識到質(zhì)量如何影響軟件開發(fā)成本。研究人員Capers Jones已經(jīng)關(guān)注了數(shù)十年，并每年進行一次軟件成本調(diào)查。這些數(shù)字每年變化不大。數(shù)據(jù)顯示，從需求到編碼再到維護的每個階段，軟件的典型成本都會增加。但是，團隊對待質(zhì)量的方式?jīng)Q定了他們的過程是健康的還是“病態(tài)的”。

為什么我們需要及早修復缺陷

有道理的是，如果我們在編寫代碼時就發(fā)現(xiàn)缺陷，那么成本就相對便宜了——例如，開發(fā)人員只需幾分鐘的時間。如果可以在開發(fā)階段消除85％的缺陷，那么對成本的影響就很大。考慮一下現(xiàn)在著名的Capers Jones圖表，它顯示了在每個開發(fā)階段修復缺陷的平均成本：

根據(jù)對使用真實軟件而不是理論模型的真實公司的研究，修復發(fā)布后的缺陷大約需要16000美元（可能更多）。如果我們查看周期后期的質(zhì)量和安全性工作（例如滲透測試），則此處發(fā)現(xiàn)的安全性問題處于周期的昂貴末端。通過測試與早期安全審核相比，查找漏洞的成本可能高出15倍。

一種過時且可證明是錯誤的方法是通過在生命周期的結(jié)尾（即發(fā)行前）進行測試來提高軟件的質(zhì)量。在制造業(yè)中，他們知道這是不可能的，但是出于某些原因，我們認為我們可以測試“進入”軟件的質(zhì)量（和安全性）。

我之所以說軟件開發(fā)幾乎絕不是工程學，是因為當前軟件開發(fā)具有以下共同特征：

• 大多數(shù)開發(fā)人員正在做的事情是不可重復的。也就是說，如果我將相同的任務(wù)分配給兩個不同的人，結(jié)果將是不同的。
• 缺乏良好執(zhí)行的最佳實踐。軟件開發(fā)人員將編碼標準視為一個毫無意義的詞。標準被認為是團隊領(lǐng)導堅持要求我遵循的一組規(guī)則，而不是理解編碼標準是知識，實踐和經(jīng)驗的體現(xiàn)。電氣工程師知道，標準是首次制造安全產(chǎn)品的方法。軟件開發(fā)人員認為標準是一種限制因素，正在減慢它們的速度……“誤報”。
• 開發(fā)人員培訓是未知且不一致的。軟件開發(fā)教育沒有像工程學科那樣標準化。標準和既定做法通常不是課程的一部分，而是重點放在編程語言上。

編碼標準提高了安全性

軟件編碼標準的目標是灌輸經(jīng)過驗證的編程實踐，以產(chǎn)生安全，可靠，可測試和可維護的代碼。通常，這意味著避免使用已知的不安全編碼做法或可能導致不可預測行為的代碼。這對于像C和C++這樣的編程語言至關(guān)重要，因為在這些語言中，編寫不安全或不安全代碼的可能性很高。

但是，我認為行業(yè)在使用這些編程標準時已迷失了方向。在過去的十年中，這些工具（例如靜態(tài)分析工具）已經(jīng)從檢測不安全的潛在問題代碼或已知的語言弱點轉(zhuǎn)變?yōu)橐栽缙跍y試的形式尋找缺陷，也稱為左移。

 盡管尋找缺陷很重要，但是開發(fā)完善的軟件是一項更具生產(chǎn)力的活動。我們應(yīng)該做的是建立和執(zhí)行標準，以避免出現(xiàn)缺陷首先出現(xiàn)的情況，即向左移動更遠。

作為支持，請考慮軟件工程研究所（SEI）所做的研究，他們毫不奇怪地發(fā)現(xiàn)，安全性和可靠性是緊密相連的，并且可以通過發(fā)現(xiàn)的質(zhì)量缺陷的數(shù)量和類型來預測軟件的安全性。此外，關(guān)鍵缺陷通常是編碼錯誤，可以通過檢查和工具（例如靜態(tài)分析）來避免。

行業(yè)標準

這篇文章沒有詳細介紹每種編碼標準，但是在以下行業(yè)標準中有大量工作要做。盡管它們的應(yīng)用可能特定于特定類型，但這些標準已在許多行業(yè)中得到采用。以下是一些已建立的安全性編碼標準示例。

• MISRA C/C++：由汽車工業(yè)軟件可靠性協(xié)會開發(fā)，它描述了C或C++語言的子集以及使用它們的準則，以提高應(yīng)用程序的安全性。盡管最初是針對汽車應(yīng)用，但在其他對安全要求嚴格的應(yīng)用中，它的使用卻有所增加。
• SEI/SANS CERT：軟件工程學院（SEI）的計算機緊急響應(yīng)小組（CERT）具有一組準則，可以幫助開發(fā)人員創(chuàng)建更安全和更可靠的軟件。這些準則被“規(guī)則”和“建議”分組劃分為重要的內(nèi)容，并且非常詳盡和廣泛，并包括風險元數(shù)據(jù)。
• OWASP Top 10：顧名思義，開放Web應(yīng)用程序安全項目（OWASP）是致力于改善Web應(yīng)用程序安全性的組織。因此，他們的OWASP Top 10項目提供了最常見和影響最大的Web應(yīng)用程序安全漏洞的列表。OWASP Top 10的最新版本與特定的CWE ID直接相關(guān)，并且包含風險元數(shù)據(jù)。
• Joint Strike Fighter Air Vehicle C++ Coding Standard (JSF AV)：一種基于MISRA C子集的標準，專門針對JSF計劃。
• CWE - Common Weakness Enumeration Top 25：CWE是基于對報告的漏洞（CVE）的分析發(fā)現(xiàn)的軟件弱點的列表。前25名列出了從較大的CWE列表中選擇的最常見和最危險的安全漏洞，這些漏洞都是極有可能發(fā)生的漏洞，利用漏洞的影響很大。CWE還以技術(shù)影響的形式包括風險信息，有助于了解哪些問題對您的組織最重要。

讓我們考慮一下MISRA C，我提到的它不僅是用于汽車應(yīng)用。但是，該標準自1998年以來一直在使用，并且定義明確。他們每兩年進行一次更新。隨著C和C++語言的發(fā)展，它們圍繞著它發(fā)展了標準。這是一個非常靈活的標準，其中考慮了不同的嚴重性級別，并且有成文的策略來處理和記錄偏差。

作為可以檢測違反編碼標準準則的技術(shù)（例如靜態(tài)分析），MISRA的最新版本考慮了哪些準則是可以確定的（可以用工具高精度地檢測到），而哪些不是。這使我們想到了采用和強制執(zhí)行以及靜態(tài)分析工具在編碼標準中的重要性。

靜態(tài)分析的作用

研究表明，缺陷清除不足是軟件質(zhì)量低下的主要原因。程序員發(fā)現(xiàn)自己軟件中的缺陷的效率約為35％。在開發(fā)周期的后期，在所有設(shè)計評審、同行評審、單元測試和功能測試之后，我們希望消除的大多數(shù)缺陷約為75％。

如果在預防模式下正確使用靜態(tài)分析，則可以將缺陷清除率提高到大約85％。但是，當今大多數(shù)組織使用靜態(tài)分析的重點是檢測和快速修復。

首先使用靜態(tài)分析工具來防止已知的不良編程習慣和語言功能，可能會帶來進一步的好處。在這里，編碼標準將作為指導原則和編程語言子集發(fā)揮作用，以防止將諸如緩沖區(qū)溢出或缺少初始化之類的常見缺陷寫入代碼中。

只需一點預防

考慮一個示例，在該示例中，可能使用動態(tài)應(yīng)用程序安全工具（DAST）檢測到一個相當復雜的緩沖區(qū)溢出錯誤。運氣不好，因為您的測試剛好執(zhí)行了包含錯誤的代碼路徑。一旦被檢測和調(diào)試，就需要重新測試等等。使用流分析的靜態(tài)分析可能也發(fā)現(xiàn)了此錯誤，但這取決于應(yīng)用程序的復雜性。

運行時錯誤檢測非常精確，但是它僅檢查您執(zhí)行的代碼行。因此，它僅與測試代碼覆蓋率一樣好。考慮一下編碼標準是否首先禁止了導致此錯誤的代碼。

像MISRA C這樣的編碼標準并沒有描述例如如何檢測未初始化的內(nèi)存，而是指導程序員編寫首先不會導致這種錯誤的代碼。我相信這更多是一種工程方法：根據(jù)眾所周知的公認標準進行編程。以土木工程和建筑橋梁為例。

我們不會采取建造橋梁的方法，而是先通過越來越大的卡車來測試它，直到它倒塌，再測量最后一輛成功使用的卡車的重量，然后再次建造以承受新的重量。這種方法還是很愚蠢的，與我們進行軟件開發(fā)的方法沒有什么不同。

一旦軟件團隊采用編碼標準并正確應(yīng)用了靜態(tài)分析，他們就可以及早發(fā)現(xiàn)錯誤并加以預防。換句話說，團隊正在改變編寫代碼的方式，這更好，而不是盡早發(fā)現(xiàn)缺陷，這是好的！

考慮Heartbleed漏洞。現(xiàn)在有針對此特定漏洞實例的檢測器，但有一種方法可以編寫代碼，從而使Heartbleed永遠不會發(fā)生。預防是一種更好、更安全的方法。

總結(jié)

Dykstra說：“那些想要真正可靠軟件的人會發(fā)現(xiàn)，他們必須找到避免大多數(shù)bug的方法。”擁有可靠的預防方法比修復這些錯誤的成本要少。

編碼標準體現(xiàn)了以其相應(yīng)語言進行編程的合理的工程原理，并構(gòu)成了任何預防方法的基礎(chǔ)。好的軟件的成本小于劣質(zhì)的軟件的成本。如果您今天不使用靜態(tài)分析，或者僅將其用于早期檢測，請查看Parasoft的C和C++，Java，C＃和VB.NET靜態(tài)分析工具，其中包含豐富的檢查程序庫內(nèi)置了流行的安全標準。