您不能審查單個代碼行。您會死於嘗試這樣做。

在某個時候，您必須信任其他人。 1984年，許多Unix的共同發明者之一肯·湯普森（Ken Thompson）寫了一篇關於 trusts的局限性的簡短文章。在某些時候，您確實必須信任其他人，您必須相信，編寫文本編輯器的人不會自動隱藏一些PHP解釋程序將執行的Trojan代碼，這些代碼將被執行為竊取比特幣的惡意軟件。

您

在大多數情況下，您應該儘自己最大的努力來審查代碼的作者，項目的內部安全實踐以及如何對代碼進行審查。代碼到達您。審查代碼實際上是昂貴且艱鉅的，因此應將其保留給您認為對您的項目最重要的部分。

該圖書館是受歡迎的圖書館嗎？背後的知名項目負責人？項目是否具有適當的項目管理流程？圖書館是否有安全問題的良好歷史記錄，它們是如何處理的？它是否具有測試以涵蓋其需要處理的所有行為？它可以通過自己的測試嗎？這樣就降低了在沒有任何人注意的情況下破壞庫的風險。

請獲取一些示例文件以進行更深入的審查。你看到有關那裡的事嗎？如果您拿走的幾個文件有重大問題，則可以推斷出代碼庫的其餘部分也有類似的問題。如果它們看起來不錯，則可以增強您對其餘代碼庫的編寫類似的信心。請注意，在非常大的代碼庫中，代碼的不同區域將具有不同級別的代碼質量。

您的包管理器存儲庫是否檢查包簽名？是否需要預先審核系統才能將軟件包註冊到資源庫中，還是開放的註冊資源庫？您是否以源代碼形式或預編譯的二進制形式接收該庫？這些都會影響您對庫的信任程度，風險因素以及如何進一步提高信任度。

您還必須考慮應用程序以及應用程序將在其上運行的執行環境。這是國家安全代碼嗎？這個代碼處理是電子商務或銀行處理信用卡號碼的一部分嗎？此代碼是否以超級用戶身份運行？該代碼壽命/安全性至關重要嗎？您是否具有補償控件來隔離和運行具有不同特權（例如容器，VM，用戶權限）的代碼？這是周末項目的代碼嗎？如何回答這些問題，應該讓您定義一個預算，以便可以在審查代碼上投入多少資金，從而確定如何對哪些圖書館需要審查，在什麼級別進行優先排序以及哪些圖書館需要較低的信任度進行優先排序。

我的“ Composer”目錄樹當前有超過120,000行代碼。那就是我需要的最少數量的關鍵PHP庫。

您的錯誤是試圖像對待您自己的代碼一樣審查第三方代碼。您不能也不應該嘗試這樣做。

您沒有按名稱提及任何庫，但是我將假定其中有相當一部分是因為您正在使用一個較大的框架，例如 Laravel或 Symfony。像其他主要圖書館一樣，此類框架也有自己的安全團隊；問題得到快速修補，並且安裝更新很簡單（只要您使用的是受支持的版本）。

與其嘗試自己審查所有代碼，還需要放手並相信供應商已經擁有了完成-並將繼續為您進行審核。畢竟，這就是為什麼使用第三方代碼的原因之一。

實際上，應該將第三方PHP庫與在編譯後對待第三方庫的方式完全一樣。 .NET或Java之類的環境。在那些平台上，這些庫以DLL文件或類似文件的形式出現，您可能永遠也看不到源代碼。您無法審核它們，也不會嘗試。如果您對PHP庫的態度與此不同，那麼您需要問問自己為什麼。僅僅因為您可以讀取代碼並不意味著您從中獲得任何好處。

所有這些都歸於失敗的地方當然就是您的第三方庫中包含較小的庫。不支持或沒有安全策略。因此，這就是您要使用的所有庫的問題：是否完全支持它們，並且它們具有您滿意的安全策略。對於任何沒有的庫，您可能要考慮尋找這些庫的替代方法。但這仍然並不意味著您應該嘗試自己審核它們，除非您實際上打算取代對它們的支持。

不過，我要補充一件事：如果您要對PHP代碼進行安全審核，強烈建議您使用 RIPS掃描器。它並不便宜，但是如果您有很強的安全性要求，那麼它很可能是您可以從PHP獲得的最好的自動化安全性分析工具。絕對在您自己的代碼上運行它；您可能會驚訝於它收到了多少個問題。如果您很偏執，當然也可以在第三方庫上運行它。不過，這將花費您更多的錢，而我的上述觀點仍然成立。您確實應該信任您的第三方供應商為自己做這種事情。

歡迎使用新的編碼範例：您在庫之上使用庫。您並不孤單，但是您還需要了解，每當您引入未編寫的代碼時，都會帶來一定的風險。

您的實際問題是我該如何應對這種風險？

了解您的軟件應該做什麼

通常，庫管理器成為一種方便的方式來將代碼拍打成“可行”的方式，而無需打擾從高層次了解它應該做什麼。因此，當您信任的庫代碼做壞事時，您會措手不及，想知道發生了什麼。這是單元測試可以提供幫助的地方，因為它可以測試代碼應該執行的操作。

了解源代碼

Composer（或任何程序包管理器） ）可以從您指定的任何來源進行安裝，包括昨天由一個完全未知的來源匯總的庫。我願意從具有SDK的供應商那里安裝軟件包，因為該供應商是高度受信任的來源。我還使用了來自其他可信任工作源的軟件包（即，PHP項目中的某個人有一個庫回購）。盲目地信任任何來源都會給您帶來麻煩。

接受存在一些您無法完全緩解的風險

在2016年，一個NodeJS開發人員癱瘓了很多軟件包當他們退出該項目並要求其圖書館不公開時。他們有一個簡單的庫，其中有數百個其他軟件包列為依賴庫。也許該基礎結構不是為處理軟件包分發而構建的，所以它隨機失效。互聯網在分佈式軟件開發世界中已經非常擅長“使事物正常工作”，以至於人們在停止工作時往往會感到沮喪或困惑。

當PHP 7.0發佈時，我不得不做大量的工作來製作我們在7.0環境中使用功能的開源第三方軟件包。我花了很多時間，但是我能夠幫助該軟件包的作者解決一些問題，並使它在7.0環境中可用。替代方案是替換它……這將花費更多時間。我們接受這種風險是因為該軟件包非常有用。

但是，最基本的安全問題仍然存在：我不知道此“已安裝”代碼包含的內容，也不知道每次更新都添加/更改了什麼。當我的Composer獲取更新時，庫的一位作者可能很容易受到損害，導致我的PHP CLI腳本突然將我的Bitcoin wallet.dat發送到某個遠程服務器，在我的機器上安裝了RAT /特洛伊木馬，甚至更糟。實際上，它可能已經發生了，我再也不明智了。我根本不知道。從邏輯上講，我沒有任何想法。

查找 Heartbleed，這是OpenSSL中的巨大安全漏洞。 Heartbleed通過首先將最後幾百個（網絡加密的）事務保存為純文本，然後為知道它的任何人提供了一個簡單且未記錄的工具來進行遠程連接並檢索用戶認為的所有內存緩存事務，從而有效地使SSL失效已以純文本格式安全加密。到那時，OpenSSL可以保護絕大多數自託管網站，大量銀行甚至政府情報服務。

然後查找 Meltdown和 Spectre，這是現代英特爾CPU中內置的大量錯誤。 Meltdown和Spectre完全抵消了在保護模式下運行CPU的能力，並且與操作系統無關，可在每個操作系統上使用。

幾年前，一個名為 MSBlaster的惡意軟件利用了一種Windows XP後台服務（我什至不知道這是一個錯誤-只是一個非常愚蠢的），甚至沒有業務在運行默認情況下-只有絕大多數Windows用戶會積極使用它，然後IT部門才能知道。最終，這促使ISP發布了內置在其調製解調器設備中的硬件防火牆，並促使Microsoft將內置的軟件防火牆嵌入其操作系統中。大約在同一時間，發現所謂的“防病毒” Linux平台發行版在主要發行版本中包含內置的rootkit。

正如其他人所說：您必須信任某人點。事故和惡意都會造成問題。我就像你- X-Files 和 Uplink 的忠實擁護者（TRUST Noone！）-但是現實是，您的SSL加密引擎或您的物理硬件設備可能存在安全漏洞，而當它們出現時，它們更可能代表關鍵任務故障。

如果您認真努力為您和用戶的安全性重新發明Composer滾輪，則認真考慮進一步努力：設計您自己的CPU，主板，RAM，HDD和光盤驅動器。編寫自己的操作系統和硬件驅動程序。也製作自己的編譯器。忘了PHP，因為解釋器中可能會出現問題-實際上，也忘了C和C ++，因為編譯器中可能存在問題，甚至不用別人編寫的彙編器來考慮彙編語言。使用十六進制編輯器從頭開始將所有自己的軟件編寫為機器說明。

或者您可以扮演行業成員的角色。訂閱Composer / PHP / YourLinuxDistro的更新新聞通訊，並可能也加入一些基於安全性的獨立新聞通訊，並訂閱 Wired 。查看系統日誌。使用PCAP定期測試您的網絡，以確保沒有任何未經授權的網絡流流入或流出。積極主動地監視可能的威脅，而不要對尚未發生的事情抱有幻想。

作為中級到高級開發人員，我已經考慮過相同的問題。需要考慮以下幾點：

• 優先審閱對於安全性至關重要的代碼。顯然，這將包括身份驗證和登錄代碼，權限驗證，支付處理器集成。任何需要敏感信息或進行網絡呼叫的東西。
• 在視覺上瀏覽之類的東西，例如樣式庫-您應該能夠快速確定它們僅在進行樣式設置-如實用程序功能。大寫的字符串，空格替換，重新排列數組...您應該能夠快速瀏覽代碼，並看到它們沒有做任何意外的事情。
• 即使您沒有完全反向工程代碼，就像完全是您自己的，您應該能夠瀏覽源代碼，並確定它是否旨在 對逆向工程友好 。代碼應文檔化，並帶有有用的註釋，變量和方法名稱應相關且有用，功能和實現不應太長或太複雜或包含不必要的功能。 令人愉悅的代碼肯定不是惡意黑客的首選攻擊媒介。
• 確認該代碼具有已建立且成熟的用戶基礎強>。您想吸引那些獲利且知名的公司使用的項目。
• 確認主要貢獻者的真實世界身份。對於大型項目，首席開發人員將為他們的工作而感到高興。您應該能夠找到博客文章，社交媒體帳戶，甚至可以找到簡歷或用於諮詢工作的營銷頁面。 與我聯繫！ 等
• 確認已使用最新錯誤修正 積極維護了 開放源代碼。查看出色的錯誤報告-數量肯定會很少-不要相信聲稱某個特定工具或庫沒有錯誤的說法。
• 避免帶有過多廣告的“免費”網站。避免使用沒有可用的演示站點的項目，或者該演示“難看”，維護不當或經常脫機的項目。避免過度宣傳的項目或過多的流行語，不要提出未經測試的卓越性能聲明。避免從匿名博客下載。等等。
• 惡意思考。如果您想破壞自己的網站，該怎麼辦？如果您想將不安全的代碼潛入廣泛使用的庫中，該怎麼辦？ （顯然，實際上不嘗試這樣做。）
• Fork 開源項目，或下載備份。永遠不要相信您喜歡的開源項目的正式倉庫會無限期在線。

因此，與其嘗試分別閱讀和理解每一行代碼，不如了解一下每個庫 做什麼，並且您相信 為什麼 。我真的認為，如果您的工作有利可圖，那麼項目的規模沒有上限。 您可以“審核” 1,200,000多行代碼或120,000,000+行代碼！

Composer可以使用 composer.lock 文件，並且默認情況下通過 https://packagist.org/下載軟件包（請注意HTTP S。）因此，您將擁有龐大的軟件包存儲庫以及帶有SHA1校驗和的安全下載，以確保您完全下載了曾經指定的內容。

如果僅是依賴更新的保守派，您還可以期望該軟件包的版本已用於生產環境。

最後，您將不得不信任某人。您可以信任自己編寫無漏洞利用的代碼，也可以像其他人一樣信任成千上萬的社區項目，甚至更多用戶可以看到它。

最後，我不認為您有選擇。如果其他人“盲目地飛行”，即沒有您想要進行的安全審核，並且以較低的價格和更快的功能發布來吸引“您的”客戶，則無論如何，任何人都不會從您的安全自編寫應用程序中受益。