requirements.txt：核心工具還是隱藏威脅？
每個 Python 專案都有它。那個看似無害的程式。 requirements.txt 位於倉庫根目錄的文件 pip install requirements.txt consumes 確實是一個依賴項列表，但如果你不小心，它也可能成為導致構建不穩定、軟體包易受攻擊和嚴重安全問題的敞開大門。
其核心， requirements.txt 控制應用程式引入哪些第三方軟體包。當您運行 pip install -r requirements.txtPython 的套件管理器會安裝所有列出的依賴項。但關鍵在於：如果你不指定確切的版本，就會出現問題。 信任 PyPI 始終提供安全、相容且未修改的版本，這並非現代應用程式安全的工作方式。
如果沒有版本鎖定，建置可能會失敗。更糟的是，您的應用程式可能會在不知情的情況下攝取惡意軟體包。開放式版本控制（燒瓶 >=1.0, 例如）或寬鬆的版本約束（django~=3.2）是注入不安全程式碼的溫床。這就是為什麼妥善管理如此重要。 requirements.txt 這是一項核心安全任務。
pip freeze 和 pip install requirements.txt 的詳細步驟
點凍結 它很方便，但如果不了解它捕獲的內容，使用起來也很危險。開發人員經常生成 requirements.txt 使用 pip freeze 要求.txt他們期望它能鎖定環境。但 freeze 指令並不會驗證依賴項的安全性或來源；它只是卸載了所有目前已安裝的軟體包，包括傳遞依賴項和可能已過時的軟體包。
現在想像一下，你的隊友或你的持續整合團隊成員盲目地運行 pip install -r requirements.txt如果該文件包含已棄用的、易受攻擊的，甚至 拼字錯誤佔位包你剛剛自動觸發了一起安全事件。
簡單範例：
⚠️ 此範例不安全，請勿在生產環境中使用
現在將此添加到您的 CI 中 pipeline:
你相信環境是可復現的，PyPI 上沒有任何變化，並且 每個依賴項 仍然安全。依賴這一點時，這是一個巨大的假設。 pip freeze 要求.txt 工作流程。
應用程式安全性面臨的真正威脅：requirements.txt 檔案中的網域搶註與依賴關係混亂
攻擊者鍾愛開源生態系統。為什麼？因為開發者往往依賴預設設定和隱性信任。以下是他們如何利用開源生態系統發動攻擊。 requirements.txt:
- 註冊近似域名上傳一個名為「惡意軟體」的軟體包 請求 而不是 請求少一個角色，你的角色就完蛋了。
請求 # ⚠️ 範例，並非實際安裝的軟體包
- 依賴性混淆如果你的內部軟體包沒有被鎖定或設定為私有範圍，攻擊者就可以將同名的惡意版本發佈到 PyPI。如果你的持續整合（CI）系統沒有驗證原始碼，你就會安裝他們的軟體包而不是你自己的軟體包。
這兩種攻擊都利用了缺乏嚴格的版本控制和原始碼控制。 requirements.txt如果你的 只是說 一些內部庫然後你跑 pip install requirements.txt 在持續整合（CI）中，它可能會從錯誤的位置獲取錯誤的軟體包。
確保 requirements.txt 檔案安全 CI/CD Pipeline帶有哈希和固定
以下是硬化的方法 requirements.txt 應對現實世界的威脅：
- 精確版本：始終使用 == 在您的每個包裹中 requirements.txt不支援通配符，不支援範圍。
- 使用 --require-hashes這使得 pip install -r requirements.txt 驗證每個下載軟體包的完整性。
示例：
⚠️ 範例僅供參考，實際項目請替換為真實雜湊值
- 隔離你的構建始終使用簡潔、精簡的容器進行建置。切勿盲目信任基礎鏡像。
- 使用私有 PyPI 索引：自行託管代理/緩存，並且只鏡像可信任軟體包。
執行依賴關係掃描整合以下工具 pip-audit 或使用 SBOM在您的分析中基於 - pipelines.
GitHub Actions 程式碼片段範例：
⚠️ 教育 pipeline 例如，適應你的環境
嚴格處理 pip install -r requirements.txt in CI/CD 這是降低開源風險最簡單的方法之一。
可複現建置：保持其在不同環境下的穩定性
如果你的應用程式在本機運作正常，但在測試環境或生產環境中運作失敗，則可能是依賴項不一致。 requirements.txt 都是老熟人。即使是很小的版本偏差也會造成大問題。
使用以下策略：
- 點子工具： 使用 pip編譯 生成 requirements.txt 從 requirements.in它透過正確的鎖定來解決依賴關係。
- 環境標記對於特定於作業系統的軟體包或特定於 Python 版本的依賴項，請使用類似這樣的標記： platform_system == 'Linux'.
- Docker 快取在持續整合 (CI) 中，安裝相依性後快取 Docker 層。 requirements.txt 減少構建差異。
使用 pip-tools 的範例：
⚠️ 此為範例，實際輸出取決於您的環境
輸出端完全固定。 requirements.txt.
類似的工具 點凍結，當與 pip install -r requirements.txt 施工過程中需要嚴格的紀律和額外的安全措施。
結論：自信鎖定您的需求
管理不善 requirements.txt 這不僅僅是糟糕的做法；它本身就是一種安全隱患。鬆散的註冊表鎖定、未經驗證的安裝以及對開放註冊表的盲目信任，正是攻擊者利用這些漏洞的手段。 CI/CD pipeline這些並非理論上的缺陷；它們每天都在被利用。
依賴項綁定不僅僅是一種最佳實踐，它也是Python中抵禦供應鏈攻擊的第一道防線。將其與 --require-hashes建構隔離機制和可復現的工具，例如 點子工具，你會得到一個 pipeline 這一點更難妥協。
是否使用 pip install requirements.txt 無論是在本地還是在持續整合環境中，都要始終驗證和監控建置過程中使用的內容。諸如此類的工具： Xygeni 提供可視性、策略執行和自動化檢查，從而保護您的 Python 供應鏈免受侵害。 pip freeze 要求.txt 貫穿整個生產過程。
