他們說軟件會吃掉世界，但是Bug還沒解決掉

“9月25日周二下午，我們的工程團隊發(fā)現(xiàn)了一個影響近5000萬個賬戶的安全問題，”Facebook的Guy Rosen在公司9月份的一次安全更新中表示到。

這個問題很嚴重。被盜的并不是密碼，而是訪問令牌(access token)，這是一個不透明的字符串，用于標識用戶，并授予對API的訪問權，這里的API指的是應用程序用戶訪問Facebook時使用的軟件接口。

獲得令牌后，攻擊者便可以以其他用戶的身份登錄Facebook，更糟糕的是，這些不法分子還可以使用偷來的Facebook用戶身份來驗證登錄其他網(wǎng)站，不過目前尚不足清楚這種情況是否已經(jīng)發(fā)生，攻擊背后的幕后主使也不得而知。

這個安全災難的原因是一個編程錯誤，或者更確切地說，是工程VP Pedro Canahuati 所述的，這是“三個bug的組合”。第一個是發(fā)生在視頻只讀API中的bug，第二個是視頻上傳API中的一個bug，后者生成一個具有廣泛權限（Facebook移動應用程序權限）的訪問令牌。而第三個（可能也是最嚴重的）bug是生成的訪問令牌針對的不是當前用戶，而是正在查看概要文件的另一個用戶。

該事件表明，bug永遠無法避免，即使是那些資源最豐富的軟件項目，而且人們也很難發(fā)現(xiàn)那些不會立即影響功能的bug。雖然測試是今天軟件開發(fā)和部署中不可或缺的一步，但是沒有哪個測試可以試驗所有可能的輸入組合，或者展現(xiàn)出所有可能的失敗。

這個案例還展示了當今軟件bug的影響是如何被某些代碼的大量使用和放大的。在本例中，我們討論的是攻擊者可能會利用大約5000萬個帳戶，來訪問未知數(shù)量的第三方站點。

另一個近期的例子是: 2018年10月，微軟在沒有充分測試的情況下發(fā)布了Windows 10的特性更新，而其中的一個bug會在某些情況下會刪除用戶數(shù)據(jù)。在被下架之前，該更新已經(jīng)被安裝到了數(shù)千名用戶的系統(tǒng)中，微軟為此付出的聲譽、補救和支持成本可想而知。

時間往前推移一些，還有2014年發(fā)現(xiàn)的“心血”（Heartbleed）漏洞， 它源自OpenSSL加密庫中的一行代碼：

memcpy(bp, pl, payload);

該代碼不會檢查數(shù)據(jù)的實際大小是否與復制的數(shù)量相匹配。因此，攻擊者可以在大小上進行欺騙，并接收出現(xiàn)在內存中的其他數(shù)據(jù)副本，其可能包括用戶名和密碼。這個bug影響了Apache和Nginx web服務器，而這些服務器又被世界上三分之二的活躍網(wǎng)絡站點以及無數(shù)其他網(wǎng)絡應用程序使用著。

向前一步，退后兩步

2011年，風險投資家Marc Andreessen因認為軟件正在吃掉世界而登上新聞頭條。某種程度上，這個表述還算正確，但是我們可能都沒注意到軟件中的bug問題。早在二十年前，程序員及作家Steve McConnell 就認為按行業(yè)平均水平，每1000行的代碼中就會存在15到50個bug，同時權威IT項目跟蹤機構Standish Group也在報告中指出，1995年有三分之一的軟件項目最終取消，這帶來了810億美元的浪費。McConnell和Standish Group簡直是軟件交付派對上的幽靈，他們進一步加劇了軟件交付實踐質量不佳的壞名聲。軟件項目總是會延期，而且總是會存在大量的bug。在那時，如果真的有軟件項目真的能按時、按預期并按預期運行，那真可以用驚喜形容。

不過，那是上世紀90年代的舊事了，如今的軟件工具、開發(fā)實踐和文化自那時起已發(fā)生了很大變化。這類轉變的突出代表包括測試驅動型開發(fā)和源于極限編程方法論（Extreme Programming methodology）的代碼覆蓋概念（即測試期間執(zhí)行代碼的數(shù)量）。靜態(tài)代碼分析是另一個突破，該方法使用工具執(zhí)行編碼標準，并捕捉比較明顯的bug。同時，編碼標準本身也在不斷發(fā)展，包含了使代碼變得更可靠的知識，例如保持代碼單元簡短。

更安全的編程語言也在提供幫助。具有自動內存管理且不直接使用指針的高級語言，如1996年首次發(fā)布的Java，它使開發(fā)人員更容易避免一些錯誤。在最近，像GitHub這樣的云托管工具的出現(xiàn)，也使得各個團隊的中軟件生命周期管理工具變得更加易用。

開發(fā)人員是否因此保持了代碼的“清潔”?

隨著軟件變得越來越普遍，答案應該是肯定的。軟件不再僅僅是工作場所(Windows個人電腦和服務器)的專利，也不再是為晦澀難懂的工業(yè)控制系統(tǒng)編寫的復雜流程。但同時軟件缺陷帶來的風險，也不再是僅存在于公司的服務器中了。

據(jù)2017年Mitre常見缺陷列表（CWE）所示，實際情況并不樂觀。首先就是注入攻擊（injection attack），它包括SQL注入在內，在此情況眾，用戶輸入可以執(zhí)行未經(jīng)授權的命令。 多年來，該缺陷一直為人所知，并不斷引發(fā)問題。

CWE列表中收錄的另一大缺陷是“使用具有已知漏洞的組件”。軟件開發(fā)人員一直依賴于代碼庫;而任何項目中的大多數(shù)代碼都是由其他人編寫的。但是，正如Heartbleed所顯示的那樣，庫和組件并不能避免漏洞。當庫或組件中的錯誤被發(fā)現(xiàn)時，它將被修復。

不過，修補所有正在使用的應用程序中的bug是非常具有挑戰(zhàn)性的。許多受到影響的應用程序可能得不到良好地開發(fā)，一些bug還可能存在于永遠得不到修補的網(wǎng)絡設備固件中。因而物聯(lián)網(wǎng)變成了“bug網(wǎng)”，除非有自動補丁存在，同時供應商也提供細致的補丁管理。

此外，bug不僅很昂貴，而且還性命攸關?？突仿〈髮W教授Phil Koopman專門研究嵌入式軟件的質量，比如自動駕駛汽車和其他類汽車軟件安全等，在最近的一篇關于汽車軟件缺陷與潛在致命性的文章中，Koopman列出了50個令人不安的缺陷報告，如突然加速、無法脫離自動駕駛控制以及妨礙司機進行轉向控制等。

降低代碼復雜度

Koopman指出，提高軟件質量在很大程度上就是觀察最佳實踐。

這包括降低代碼復雜性、使用靜態(tài)分析工具和零警告編譯、認真檢查實時代碼調度、嚴格軟件測試以及使用基本工具(包括配置管理、版本控制和bug跟蹤等)。

CAST Research Labs在2017年發(fā)表了一篇關于應用軟件健康程度的報告，該報告基于遍及8個國家和329個組織的1850個“大型、多層、多語言的商用程序”，一共具有10億行代碼。該報告基于五個健康因素：穩(wěn)定性、安全性、效率、可更改性（代碼修改難度）和可轉移性（對于剛接觸代碼的開發(fā)人員來說理解代碼有多難）。

CAST的報告令人鼓舞，所有類別的總體平均得分在3.0或以上，其中安全性最好在3.22分，可移植性最差在3.0分。這種相當高的質量水平反映了這樣一個事實，即這些應用程序通常會在資源豐富的部門中起關鍵作用。

但這些結論仍值得再推敲一下。比如安全評分差異較大，這說明缺乏安全編碼實踐仍然是一個問題。在團隊規(guī)模方面，CAST認為超過20名開發(fā)人員的團隊得分較低，并建議最佳團隊規(guī)模應該在10人或更少。

另一個有趣的地方是，最佳評分項目背后的方法既不是敏捷性的(強調迭代開發(fā))，也不是瀑布式的(強調預先計劃)，而是一種混合方法，它具有廣泛的預先分析，然后是簡短的迭代編碼沖刺。

CAST還指出，涉及“跨應用程序的多層多組件”的軟件架構類的代碼質量更難測試;但結構質量才是導致大多數(shù)運營問題的原因。

慢編碼

編寫防彈代碼的速度依然較慢，因此開發(fā)時成本較高，這也是軟件質量仍然如此參齊不齊的一個原因。眾所周知，缺陷發(fā)現(xiàn)得越晚，修復缺陷的成本就會越高，不過，由于差異很大，很難給出缺陷造成具體多大影響的通用數(shù)字。

在web應用程序的DevOps流程中，我們可以進行代碼更改、自動測試并快速部署到生產(chǎn)環(huán)境中，所以修復最近發(fā)現(xiàn)的bug的成本可能不算太高。但這里有個極端的例子，1996年阿麗亞娜5號火箭（Ariane 5） 在發(fā)射時發(fā)生了爆炸，這是由64位變量轉換為16位變量后數(shù)量太大導致系統(tǒng)無法容納引起的，這個bug的直接經(jīng)濟損失約為5億美元。

而日常生活中呢？根據(jù)IT軟件質量聯(lián)盟（Consortium for IT Software Quality）的數(shù)據(jù)，除去技術債務后，所謂的“低質量”軟件給美國經(jīng)濟造成2.26萬億美元的損失。再細分一下，軟件故障造成的損失占該數(shù)字的37.46%，查找和修復缺陷的任務占16.87%。

對于任何公司來說，在生產(chǎn)過程之前，找到bug并進行修復是一個優(yōu)先事項，因為修復bug或處理后續(xù)問題所涉及的成本會隨著時長的延長而增加。

因此，生產(chǎn)過程中的bug可能會帶來嚴重的長期成本。如果bug出現(xiàn)在其他軟件所依賴的軟件或固件中，例如API，那么第三方開發(fā)人員可能必須要圍繞該bug編寫代碼。然后這就會出現(xiàn)兼容性問題，因為修復這個bug可能會破壞其他軟件。

當今互聯(lián)時代與早期軟件開發(fā)時代的一個關鍵區(qū)別是，部署補丁很容易，而且通常是自動化的。由于使用了一些技術，例如提示用戶將崩潰數(shù)據(jù)提交回開發(fā)人員，或者使用“飛行記錄器”代理捕獲應用程序狀態(tài)并準確記錄崩潰時正在執(zhí)行的代碼，現(xiàn)在人們更容易跟蹤導致崩潰的bug。通過快速發(fā)現(xiàn)和修復，可以減輕明顯的缺陷。

在McConnell的言論發(fā)表了幾十年后，盡管經(jīng)歷了許多變化，但我們遇到的軟件質量挫敗仍然存在：編寫可靠代碼所需的是知識和工具，但包括財務，截止日期，錯誤管理，技能短缺和處理遺留代碼與系統(tǒng)的人為因素仍意味著代碼質量的不均衡。

考慮到軟件的巨大和日益增長的重要性，bug的持續(xù)肆虐既發(fā)人深省又令人不安。實現(xiàn)最小化部署補丁的負擔的系統(tǒng)當然是有幫助的，但是從源頭上提高軟件質量才是最關鍵的。

生成海報

免責聲明：此文內容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權歸作者所有，且僅代表作者個人觀點，與極客網(wǎng)無關。文章僅供讀者參考，并請自行核實相關內容。投訴郵箱：editor@fromgeek.com。

免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。