軟件漏洞將一直存在，壞人會設法找到并利用它們，而好人也會嘗試尋找漏洞并……。
這句話應該怎樣補充完整是安全研究人員和軟件供應商目前最為關注的熱門話題，而且，自1998年Morris蠕蟲病毒成為第一個廣泛傳播的病毒以來，這一直是大家關注的焦點。
Project Zero是由谷歌內部安全分析師組成的團隊，旨在發現零日漏洞利用。最近該團隊再次引發了有關研究人員應該何時以及如何披露漏洞的爭論。事情經過是這樣：該團隊在向微軟公司報告其產品中零日漏洞的90天后自動披露了這些漏洞，主要因為微軟沒有及時進行修復。
對潛在危險的軟件漏洞進行公開披露背后的理由是：這種漏洞披露會給供應商施加壓力以讓他們發布補丁，并且客戶有權利知道他們的系統是否存在危險，使他們能夠決定在補丁發布前如何更好地保護其系統。與之相對的觀點是，對軟件漏洞保密可以讓它們不被攻擊者利用。然而，這種方法的問題在于，攻擊者自己可以發現漏洞，而軟件公司不太可能花時間和金錢去修復未公開的漏洞。
軟件行業最初反對獨立漏洞研究以及公開披露漏洞的做法。例如，在2005年，思科對安全研究人員Mike Lynn和Black Hat采取了法律行動，因為他們解釋了如何運行攻擊代碼以控制思科路由器。值得慶幸的是，該行業最終認同漏洞披露是有益的，但對于應該如何處理漏洞披露，目前仍然無法達成一致意見。主要問題在于在公開漏洞前應該給企業多長時間來修復漏洞。如果沒有時間期限，供應商不可能優先開發補丁的工作。在1999年，黑客網站Nomad Mobile Research Centre表示他們在公布漏洞之前會給供應商一個月的時間。一年后，RFPolicy只給供應商五個工作日來與向他們報告漏洞的人進行溝通。如此這般短的窗口期部分是因為沒有得到應有的回饋所導致，在收到軟件漏洞的詳細信息后，很多供應商都沒有響應以及開發補丁。一刀切最后期限并沒有什么意義，畢竟補丁開發和測試時間可能有所不同。
軟件行業逐漸開始推行負責任的軟件漏洞披露模式，即在公開發布漏洞詳細信息之前，所涉及的所有人要對漏洞修復時間期限達成一致意見。畢竟，制定標準響應時間只能取得有限的成功，因為供應商和研究團隊都是以不同的時間表來運作。ISO/IEC 29147 2014對供應商應該如何接收有關其產品或在線服務潛在漏洞信息以及如何披露它們提供了指導意見，但其中并沒有涉及供應商應該在多長時間內修復補丁。另外，微軟有其自己的政策—Coordinated Vulnerability Disclosure（協調漏洞披露），該政策主要推動與研究人員的合作，其中鼓勵負責任的披露而非完全披露。負責任的披露規定，在供應商發布補丁之前，秘密地將漏洞報告給供應商，而不是其他任何人。這有利于實現與供應商發布更新步調一致的協調公開披露。
當然，對于如何處理軟件漏洞的整個話題，大家都有著不同的看法。在2002年黑帽大會上，安全研究人員David Litchfield展示了SQL服務器漏洞利用的概念證明代碼，隨后該研究人員發現該代碼被用作Slammer蠕蟲病毒的模板，這讓他開始質疑公開披露其代碼的好處。Anti Security Movement（反安全運動）組織完全反對完整披露有關軟件漏洞的信息，因為他們認為這可能會讓腳本小子利用它們來攻擊系統。而支持美國中情局的非營利性機構In-Q-Tel首席信息安全官Dan Geer則提出了這樣的觀點，美國政府應該公開壟斷全球漏洞市場，并將這些漏洞公開；這不僅會鼓勵更多研究人員尋找漏洞，還將會阻止大多數惡意軟件編寫者和黑客。
可以肯定的是，從長期來看，對漏洞保持隱秘并不可行，但不考慮各種情況的嚴格信息披露時間表也不利于用戶。對于谷歌Project Zero在補丁開發好前披露漏洞以讓大多數用戶可以采取緩解行為的做法，微軟做出了很好的回應：“那些認同全面公開披露漏洞信息的人認為這會迫使用戶保護自己，但其實絕大多數用戶不會采取任何行動，而在很大程度上依賴軟件供應商來發布安全更新。”
自那以后，谷歌的Project Zero在其軟件漏洞披露政策中為供應商增加了更多的回旋余地，讓供應商可以選擇延長兩個星期時間以便他們順利發布補丁，但在給供應商足夠時間來管理敏感資源密集型過程的同時，對于供應商做出響應的適當時間期限，業界并沒有達成共識。CERT的45天披露政策中稱，在公開披露安全漏洞的需要以及供應商需要時間作出響應之間需要進行平衡。雅虎的90天政策指出，“我們越迅速解決風險，攻擊造成的傷害就越小”，而TippingPoint的Zero Day計劃認為120天政策就足夠。
如果漏洞披露政策不考慮各種情況，可能會弊大于利。這個行業需要與善意的安全研究人員攜手合作，以負責任的態度不斷提高軟件的質量，從而推動整個互聯網的發展。
京公網安備 11010502049343號