最重要的是：您很困惑。如果您擔心其中一位開發人員故意在該代碼庫中隱藏了後門，則您不現實地希望知道是否存在後門。生活很糟糕。

評論：這裡的一些人建議您可以通過檢查代碼或使用靜態分析工具等來檢查後門。不要相信如果他們認為這很可能檢測到故意隱藏的後門，他們就會自欺欺人。我認為，這些答案過於樂觀，可能會給您帶來虛假的安全感。 （我知道我會這樣說並棄掉其他評論員，以使自己不受歡迎，但我有責任向您提供我誠實，坦率的建議。）

建議和緩解措施：關於您應該做什麼，我認為您需要向我們詳細介紹該軟件的功能，它與您的業務之間的關係以及如果擁有後門的後果。以下是您可能會考慮的一些通用緩解措施，具體取決於情況：

• 風險轉移。提供該代碼沒有後門的保證，並附有主要的經濟處罰條款（如果有）。 （請注意，如果存在後門，則發現它的機率很低，因此，如果發現後門，則其懲罰必須與檢測到它的概率的倒數成比例地增加。）

• 隔離。。您可以嘗試隔離後門程序的影響，以使其僅影響此軟件的功能，並且攻擊您其他系統的機會有限。您可以在虛擬機中運行它，將其從網絡中防火牆屏蔽，等等。也可以將其從網絡中防火牆屏蔽，從而使壞人更難激活後門。

• 監視。。在某些情況下，可以執行外部監視以檢測非法活動。例如，在老虎機聯合中，您可以監視所收取的金額，所支付的金額，並且從統計上講，這兩者之間應具有牢固的關係；如果您看到付款超出預期金額超過五個標準差，那可能是引起關注的一個很好的理由。再舉一個例子，在銀行，您可以使用兩次記賬簿並跟踪一些匯總指標，例如消費者的投訴率以及消費者對收費提出異議的頻率。這類監視技術是特定於您的特定業務的，但可能可以有效地檢測出惡作劇。

防範故意的後門程序，它們可能會或可能不會在任何特定情況下都適用，但是如果您很幸運，它們可能總比沒有好。

我將從結構概述開始-從設計角度來看，代碼的各個部分是否定義明確？例如，您是否在整個代碼庫中都具有用於這些目的的驗證代碼，輸入和輸出功能等，或者每個功能都是單獨的嗎？您是否具有功能上安全的代碼（通常某些樣式構造不會影響數據流的安全性）

如果您有一個安全包裝器可以對每個功能進行身份驗證，則可以對這些功能進行快捷檢查函數，並僅檢查包裝函數的用法。

如果代碼庫非常大，則需要運行Fortify之類的工具（或@AviD將能夠使用的其他工具）。名稱:-)首先解決問題，但是所有工具都缺乏上下文智能。它們基於典型簽名進行識別，因此您會得到錯誤的假陽性（甚至可能是假陰性），這就是為什麼擁有良好的概述可以幫助您識別工具無法發現的風險的原因

該工具縮小了可能的風險範圍，並確定了大多數問題，因為工具相對便宜，然後人工驗證並添加到工具的輸出中，將其置於應用程序環境中。

在聽起來過於商業化的風險我建議使用經驗豐富的安全顧問的服務，該顧問不僅完全了解代碼審查工具並且精通Java + Oracle，而且還具有基於業務和安全風險架構的經驗。

@Rory幾乎涵蓋了如何進行審核...

我要補充一點的是，您應該知道自己在尋找什麼，而不是通常只是“後門”（類似於@ VP01在其頂部的評論中所說）。

例如您是否正在尋找可以這樣做的後門？

• 身份驗證旁路（通過特殊身份或超級密碼）；
• 魔術參數（ala“？admin = 1”）；
• 一分錢竊取（就像在《超人3》中一樣）；
• 信息竊取（例如，在後端通過電子郵件發送信用卡號）；
• ...其他。

如果您知道要尋找的後門的類型，您不必平等地集中於數百萬行代碼的每一行，您可以確定優先級。

我還要補充一點，有一些自動化工具可以編寫非常豐富的腳本，因此它支持基於人工查找您定義的後門的特定類型情報和情境，然後將其應用於數百萬個LOC ...

PS您可能對以下一些相關問題感興趣：

• 代碼審查策略
• 良好的開源工具，可掃描以下文件的源代碼：漏洞？
• 正在尋找進行深度代碼審查的安全顧問？

我認為羅里（Rory）的答案涉及內核，但是時間在這裡確實很重要。在生產中已經存在大量代碼，記錄不良，未經測試的代碼之後進行代碼審查（我不知道這裡是否是如此），現在就“太遲了”，無法正確執行。即使使用最好的工具和Java / Oracle，外部分析師也將很難理解業務邏輯缺陷（有意植入其中）。在我看來，從一開始就進行代碼分析是必須的。

無論使用哪種語言，都有一些方法對於每次應用程序審查都是通用的。這裡有一些提示：

• 要觀看大代碼中的更改，您可以使用差異工具（就像我在這裡提到的：代碼審查策略）；
• 設置環境，因此您可以登錄並查看任何可疑的網絡請求；
• 非常簡單的方法是使用“ grep”之類的工具-有助於處理一些基本且顯而易見的惡意代碼；