熊節：防疫軟件出故障，短板該怎麼補？
【文/觀察者網專欄作者 熊節】
與新冠疫情防控相關的軟件系統在關鍵時刻出現技術故障的問題，一直以來備受關注。這樣的重要系統屢屢出現重大技術故障，暴露出我國當前數字化建設過程中的若干短板，尤其是整個信息產業普遍缺乏交付可信軟件系統的能力。
“可信”的門檻
按照英國可信軟件基金會（Trustworthy Software Foundation）的定義，可信的軟件系統應當具備以下5個方面的特質：
無害性（Safety）：軟件運行時不會對任何東西或任何人造成傷害。
可靠性（Reliability）：軟件正確運行不發生錯誤的能力。
可用性（Availability）：軟件在需要時正常運行並提供服務的能力。
堅韌性（Resilience）：軟件從錯誤中快速和完全恢復的能力。
安全性（Security）：軟件防護惡意軟件、黑客或意外誤用造成危險的能力。
所有人都會贊同，良好的軟件系統應當具備上述這些特質，服務於大眾重要應用場景的軟件系統應當是可信的。然而事實證明，獲得可信的軟件系統並非易事。即便是當前最受重視的疫情防控相關係統，由“已在國內17個省120多個地市部署應用”的行業領先企業來實施，仍然會在關鍵時刻不可用、且無法從錯誤中快速恢復。
更值得關注的是，在我國大張旗鼓開展數字化新基建的大背景下，採購軟件系統的甲方單位普遍缺乏對軟件項目實質性的監管治理能力。大部分甲方單位、尤其是信息化程度較低的傳統行業和中西部地區甲方單位，基本不具備實質管控軟件項目的能力。
曾經，某西部地區知名國企採購一個軟件系統後，不確定乙方是否按合同要求交付了源代碼，請筆者幫忙鑑定。筆者打開甲方傳來的一個壓縮包一看，只有若干光禿禿的.java源文件，前端網頁源碼、構建腳本、配置文件、數據庫腳本、部署腳本等必要工作件（artefacts）全部付之闕如。
拿着這樣一堆“源代碼”，甲方根本不可能重新構建出線上運行的軟件系統，甚至無法知道自己拿到的究竟是不是線上系統的源碼，更遑論對其質量和可信性進行任何有效的管控。
在極度簡化的場景下，軟件開發商使用人類可讀的編程語言來開發軟件，產出的成果就是源代碼。源代碼和圖片、文本等各種資源文件一起，再加上眾多依賴軟件，通過一個叫做構建的過程，被打包成為可執行的軟件包，其中的內容通常是人類不可讀、但是計算機可以執行的二進制文件。這個軟件包再與各種配置文件相結合，通過叫做部署的過程，被安裝到真實使用的生產環境上，成為線上運行的軟件系統。
典型的（過度簡化的）軟件交付過程
在這個過程中，所有工作件的質量、所有操作的質量，都會影響最終線上系統的質量。
然而在當前我國數字化項目建設中，很多甲方只獲得乙方構建部署完成後的線上系統，對構建過程、部署過程及涉及的工作件無法觸及，也沒有專業技術能力評判這些過程和工作件的質量。毫不誇張地説，很多數字化項目中，甲方實際上只獲得了軟件系統的使用權，根本沒有獲得系統的所有權。
甲方對軟件系統所有權和管控權的缺失，會帶來兩個直接的惡果。首先是形成對廠商的嚴重依賴甚至綁定。因為甲方沒有掌握軟件交付過程和工作件，未來任何修補和增強都只能依賴原廠商，客觀上形成原廠商的反競爭壁壘。另外，軟件系統質量是否過關、是否可信，因為甲方不掌握軟件交付過程和工作件，基本只能依賴廠商“又當球員又當裁判”。
筆者在之前接受觀察者網採訪時打了一個比方：
我國現在很多軟件系統的驗收，甲方既沒有能力檢驗軟件的無害性、可靠性、可用性、堅韌性、安全性等非功能指標，也沒有能力深入軟件交付過程審核其架構質量、代碼質量、供應鏈質量等質量指標，常常只是以最終用户視角把軟件功能跑一遍就完成了驗收。這就好比修建一座大橋，甲方既不檢查橋樑結構是斜拉式還是拱式，也不監督橋墩的施工質量，到竣工那天開一輛小轎車從橋面上順利通過就算完工驗收。至於大橋是否安全可靠，就全憑乙方自己提供的一堆文檔來論證了。
這聽起來可能荒誕，卻是當前行業的真實現狀。
英國政府如何落實可信要求
英國政府和業界幾年前已經開始重視軟件可信能力。英國標準協會（BSI）於2014年發佈了《軟件可信：治理和管理》規範，2018年又代之以《信息技術系統可信：治理和管理》規範。
不過，英國政府對可信的重視為中國業界同行所知，大約是從他們以“軟件可信能力欠缺”為由限制華為產品開始的。
英國政府對華為實施審查的機構“華為網絡安全評估中心”（HCSEC）從2015年起開始發佈監督委員會年度報告（可在英國政府網站下載），迄今已發佈7期。透過這7期年度報告，可以部分還原英國政府落實軟件可信要求的治理結構和審查內容。
治理結構
HCSEC成立於2010年，其目的是“根據華為與英國政府之間的一系列安排，為英國電信市場上使用的一系列華為產品提供安全評估，以規避因華為參與英國部分關鍵國家基礎設施而帶來的任何風險”。2013年，該機構共有21名員工，到2020年已增加到42名員工。
HCSEC是華為下屬的一家全資子公司。但這隻表示華為要承擔審查相關的費用，卻不表示華為能“又當球員又當裁判”。該中心監督委員會的主席由英國國家安全顧問指派，主席再邀請其他委員會成員，也就是説，該中心的人事安排完全在英國國家安全委員會的控制下。
實踐上，HCSEC監督委員會的主席一直由政府通信總部（GCHQ）的主席兼任，前幾年是夏蘭·馬丁（Ciaran Martin），2020年由琳迪·卡梅倫（Lindy Cameron）取代——GCHQ是向英國外交大臣彙報的情報和國家安全機構與國家安全局（MI5）、秘密情報局（MI6）一同接受聯合情報委員會（JIC）的領導，其主要職責是向英國政府和英軍提供情報和信息保障。
華為現任監事會副主席、運營商BG總裁丁耘一直在HCSEC監督委員會擔任副主席，監督委員會的其他成員還包括華為英國區管理董事、英國內閣辦公廳國家安全秘書處網絡安全主任、英國國家網絡安全中心（NCSC）技術主任、以及白廳各部的代表。從監督委員會的人員構成就能看出，這個委員會確保了HCSEC服務於英國的國家安全利益。
另外，HCSEC還每年聘請知名審計事務所安永（Ernst and Young）對自身運作的獨立性進行審計——這裏所説的“獨立性”特指“獨立於華為總部”。安永基於國際鑑證業務準則（ISAE）3000的規範，從財務預算、人事、採購、評估計劃、與華為的協作關係、評估彙報機制等角度審計HCSEC的活動。
在2015年的審計報告中，安永指出：HCSEC僱員的獎金是由華為英國公司根據華為公司的標準計算的，HCSEC管理層無法審查或批准員工的獎金，並建議未來改為由HCSEC管理層負責審查其僱員的獎金分配。
安永還指出，部分HCSEC僱員尚未取得“高度審查”（DevelopedVetting）級別的安全許可，並建議未來強化對員工安全許可級別的管理制度。在外部專業審計公司的幫助下，HCSEC僱傭了一批通過英國政府安全審查的專業人士，給他們設置了不受華為影響的激勵制度，從而確保了對華為產品評估審查的獨立性。
HCSEC的組織架構
審查內容
雖然對華為產品的評估是基於BSI的可信規範，但縱觀7年的報告可以發現，HCSEC關注的重點並不是某個具體的軟件缺陷或漏洞，而是華為持續交付可信軟件的能力。從2015年發佈的第一期報告到2020年發佈的第六期報告，HCSEC一直在跟華為強調同樣的幾個問題：
首先是軟件構建流程一致性。HCSEC在2016年報告中指出，華為的多款運營商產品缺乏二進制等價性（binary equivalence）——即，HCSEC拿着華為提供的源代碼，無法構建出與線上運行的可執行軟件包等價的軟件包。HCSEC提出了一個非常合理的置疑：我們對源代碼做再多的審查，如果不能驗證這份源碼正是線上系統的源碼，又如何能説這些審查是有效的呢？
2018年的報告中，HCSEC聲稱：在經過“大量努力”後，他們終於成功地從源代碼構建出一個與正式發佈的可執行軟件包等價的軟件包，然而這個產品尚未被任何英國運營商正式使用。其他已經投產使用的產品，HCSEC仍然無法自主構建出來。因此HCSEC認為，華為的軟件構建流程缺乏端到端的可靠性，不能保障持續一致地交付可信的軟件。
合理的置疑：缺乏二進制一致性，如何保障審查的有效性？
然後受到強調的是軟件供應鏈可信性。在2018年的報告中，HCSEC記錄了在華為上海研究所舉行監督委員會會議期間，在華為軟件研發現場獲得的一手信息：在華為的一個產品中，就存在70多份OpenSSL——這是一個常用的開源組件——的完整拷貝，涉及4個不同的OpenSSL版本。在整個華為產品體系中存在“無數個”OpenSSL版本，其中一些甚至不是該組件的正式發行版本。HCSEC認為，這表明華為缺乏良好的配置管理和軟件組件生命週期管理實踐，會增加軟件供應鏈風險發生的概率和管控的難度。
HCSEC對軟件供應鏈可信的要求並非空穴來風。現代軟件開發高度依賴於第三方組件、尤其是開源軟件組件。雖然軟件廠商往往會聲稱“100%自主研發”，但軟件產品中絕大部分、經常多達99%的代碼是以依賴的形式引入的，廠商自主編寫的代碼通常只佔整個軟件的1%左右。一個典型的現代商用軟件通常會依賴幾千、上萬個開源組件，其中任何一個組件被發現安全漏洞，都可能給整個系統造成損害。
去年12月，一個用於記錄服務器日誌的開源組件Log4j被爆出安全漏洞，據估計互聯網上70%以上的企業系統都因此暴露在安全風險下。如果軟件研發組織不能有效地管理軟件供應鏈，對開源軟件的依賴管理混亂而無章法，軟件產品的可信程度必然大打折扣。
HCSEC還一直強調軟件代碼編寫質量。同樣在2018年的報告中，HCSEC指出：“華為的軟件開發人員大量地違背基本的安全編碼實踐，包括華為2013年推行的內部編碼標準也沒有得到有效執行；儘管有一些自動檢測違反編碼規範的工具存在，工程師卻常常對工具檢出的告警視而不見、甚至直接關閉某些類型的告警”。
HCSEC認為，儘管華為強制推行安全編碼標準，但管理要求並沒有落到實處，客觀上體現為代碼質量不穩定、不一致，從而削弱了華為持續地、一致地交付可信軟件系統的能力。
綜觀HCSEC的報告，可以看到英國政府作為甲方看待可信問題的思路：軟件系統的長期可信，不在於能否解決某一個兩個缺陷或漏洞，而是需要建立一套持續地、一致地交付可信軟件的流程和機制；而流程和機制的運行，最終要落實到乙方的組織能力和人員能力上。如果能力不足、缺乏有效的流程和機制，那麼不管應對某一個具體問題多麼積極主動，這個乙方供應的軟件系統長期來看仍然是不可信的。
儘管HCSEC最近的報告表現出受政治影響、鑽牛角尖的趨勢，但這個思路、以及他們落實這個思路的治理結構和審查方式是值得我國甲方單位學習借鑑的。
被甲方倒逼出來的可信能力
華為以積極正面的態度接納了HCSEC的批評意見，並投入了大量資源着手強化軟件可信能力。
就在HCSEC措辭尖鋭的2018年度報告發布後不久，任正非在2019年致全體華為員工的第一封信中就提出要“全面提升軟件工程能力與實踐，打造可信的高質量產品”，要求全體員工、特別是軟件工程師“從最基礎的編碼質量做起”、“深刻理解架構的核心要素”、“重構腐化的架構及不符合軟件工程規範和質量要求的歷史代碼”、“深入鑽研軟件技術”、“遵守過程的一致性”，並特別強調“全面強化以Committer角色為核心的代碼審核和提交機制，代碼經過更加嚴格和系統的審核才能合入版本”。
這可能是我國IT行業歷史上首次有一家重要企業將代碼層面的能力建設提到如此高的地位。同年，丁耘承諾華為將在未來3-5年投入超過20億美元資金，用於在包括軟件和硬件工程、第三方組件管理、公司文化等八個關鍵領域實現可信。
華為全面強化軟件可信能力的具體舉措大多不為外人所知，但透過零星的公開信息，仍能一窺這些舉措。尤其針對HCSEC多年強調的三方面問題，華為的應對取得了明顯的成效。從華為的案例，能看到在具備高度專業能力的甲方驅動倒逼下，乙方如何提升自身交付可信軟件的能力。
針對軟件構建流程一致性問題，華為建設了內部的研發雲平台，把原來分散在開發人員各自工作環境中的構建流程集中管理，統一代碼管理規範、統一構建過程、統一質量標準。到2022年，據稱華為內部研發雲平台搭建了超過40萬個CPU的計算資源池，支撐華為超過10萬開發人員每天100萬次以上軟件構建，徹底解決了軟件構建流程不一致、源碼與二進制軟件包無法證明等價性的問題。
針對軟件供應鏈可信性問題，華為一方面投入大量成本和精力清理過時的、不規範的依賴軟件，同時在內部研發雲上建設了受控的開源製品庫和開源軟件審查機制，從而儘量降低被開源供應鏈投毒的風險。
針對軟件代碼編寫質量問題，華為內部開發了可信認證考試體系，並要求所有技術人員通過考試。考試內容涵蓋編程知識、安全編程、質量、隱私、開發者測試、設計模式、重構等基礎技術能力。
從2021年HCSEC發佈的年度報告中，可以明顯看到華為建設可信能力取得的進展。在這份報告中，HCSEC多少有點不情不願地承認：“2020年期間，華為在補救英國網絡中產品的非主流支持組件方面取得了很大進展，在二進制等價性、固網產品質量問題和漏洞管理方面也取得了與預期一致的進展”，但又馬上話鋒一轉，説：“在2020年的過程中，在滿足NCSC所期望的產品軟件工程和網絡安全質量方面沒有整體改善”——筆者竟然從這份一本正經的報告中讀出了“雖然我提的所有問題都得到了解決而且我也提不出什麼新的問題了，但是我就是對你沒有信心”這樣無奈的傲嬌感。
華為（新華社資料圖）
我國信息產業應如何建設軟件可信能力
拋開帶有政治偏見的傲嬌姿態，英國政府作為甲方對軟件系統供應商的監管治理方式，有很多值得學習的地方。我國政府和國企作為數字化新基建的大甲方，可以參考借鑑英國在軟件可信方面的治理結構和審查內容，建立一套更完善的軟件可信准入機制，進而牽引倒逼乙方企業提升自身能力，從而促進整個行業基礎能力的提升。
首先應當設置獨立於供應商、服務於甲方利益的第三方專業機構，代表甲方負責對重要軟件系統的技術評估、審計、驗收工作。這類專業機構應當充分利用市場機制吸引具備專業技能的人才，同時又應當為其設置預防腐敗的圍欄機制。
受命於英國政府的HCSEC僱傭的專業人士有能力評估軟件從源碼到二進制包的構建過程、有能力評價產品源碼是否遵循編程最佳實踐，同時該機構又外聘安永對其獨立性進行審計，整個機構的運行費用還是由乙方來承擔的。這個巧妙又平衡的治理結構，值得我國政府和國企借鑑。
同時，政府作為國家數字化戰略的引領者，應當考慮牽頭建設一套標準的軟件研發雲平台，將代碼庫、依賴庫、構建流程、質量保障流程、產品發佈流程等絕大多數軟件項目和產品共通的流程、機制和基礎設施固化、標準化到研發工具中，並推動牽引其成為行業標準實踐。
即便短時間內無法實現軟件質量和可信性的顯著提升，至少能確保甲方能獲得源代碼、能從源代碼構建出二進制軟件包、能保障源碼與二進制軟件包等價，這就已經對提高軟件可維護性、降低廠商綁定有很大的意義。對可信軟件交付提供支撐的研發工具，也是我國工業軟件裝備體系上的一塊短板，目前仍嚴重依賴國外軟件。軟件研發工具的自主國產化，也應當受到國家重視。
最後，標準制訂機構和高校應當重視軟件開發工程師的基礎能力、尤其是基本的編程和設計能力建設。具體而言，諸如開發者測試、代碼重構等已經被歐美業界證明對軟件質量價值巨大的實踐，在我國IT業界一直沒有得到廣泛接受，這與過去二十年間標準制訂機構和高校對基礎編程能力的忽視是直接相關的。儘管多年來業界一直有一種幻想，認為靠“軟件工程”、靠“社會化大生產”，就能降低對一線程序員的能力要求，然而事實是絕大多數的技術決策仍然是在編碼的階段由程序員做出的。
正所謂“魔鬼藏在細節裏”，靠流程和文檔解決不了軟件質量差、缺陷多、可信性低的問題。長期來説，整個行業可信能力的提升最終還是要落實到全行業從業者能力的普遍提升上來。
本文系觀察者網獨家稿件，文章內容純屬作者個人觀點，不代表平台觀點，未經授權，不得轉載，否則將追究法律責任。關注觀察者網微信guanchacn，每日閲讀趣味文章。