整理 | 如煙
出品 | 51CTO技術棧（微信號：blog51cto）
Python 已成為世界上最流行的編程語言之一，許多 Web 應用程序都是使用它構建的。然而，隨著受歡迎程度的增加，安全風險和漏洞也隨之增加。
2023年年初，Python 軟件基金會（Python Software Foundation，PSF）宣布了啟動為期一年的安全增強計劃。6 月，PSF 聘請 Seth Larson 加入 PSF，成為首位常駐安全開發人員（SDIR）。
一、首位駐場安全開發，要做哪些事情
Larson 在 Python 社區中廣為人知，并且在他的博客撰寫了大量有關 Python 和安全相關的文章。他在博客中表示：“Python 社區是我生活中非常重要的一部分，我很感激有這個難得的回饋機會。我期待與大家合作，構建一個更安全的Python生態系統。”
據 Larson 介紹，SDIR 的工作職責包括：
- 對 PyPI 代碼庫和基礎設施進行安全審計
- 規范并改進 CPython、PyPI 和更廣泛的 Python 社區的安全實踐
- 解決 CPython 和 PyPI 等 PSF 項目的安全問題，并提高識別和解決未來問題的能力
- 與其他致力于安全改進的貢獻者合作，包括PSF 招聘的新PyPI安全工程師
- 建立安全態勢指標以顯示影響
Larson 作為 PSF 首位駐場安全開發人員，目前提出了哪些有關 Python 的安全問題？又是如何解決的呢？我們從 Larson 的博客中提煉出部分內容，以供參考。
1.Python發行版中的捆綁庫漏洞
Python 以其作為“粘合”語言的能力而聞名，這要歸功于它的 C API 以及對用 C、C++、Go、Fortran 和 Rust 編寫的庫的訪問。這一特性可能是 Python 廣泛流行的原因之一。但Python 的這種“超能力”對供應鏈安全有一定影響。
發現問題：
PyPI（Python Package Index，Python 軟件包倉庫）僅托管 Python 發行版，包括源發行版和 Wheel 發行版。
想要利用編譯庫的 Python 發行版要么需要用戶自己安裝這些編譯庫，要么隨發行版附帶預編譯庫。必須使用系統包管理器安裝已編譯的庫，然后從源代碼編譯每個包，這對用戶來講真的很不方便。
二進制Wheel的常見工作流程是并行運行cibuildwheel和auditwheel repair，從而在許多不同的操作系統和架構（manylinux、musllinux、macOS、Windows 等）中構建 wheel，然后使用auditwheel repair，這樣需要捆綁的庫就會自動捆綁到 wheel 中。
看似操作好像更方便了，但在這個過程中，不斷捆綁的庫也帶來了漏洞風險，特別是當pdftopng包含易受攻擊的libpng版本時(在其他庫中)。
這些捆綁的庫不會出現在requirements.txt或pip freeze中，因此審核工具更難了解正在使用的庫和版本。
解決方法：
軟件物料清單 (SBOM)可以解決以上問題。通過編程方式了解下載的發行版中包含哪些內容，包括非 Python 組件。如果審核工具可以訪問這些 SBOM 以及相關組件的漏洞來源，就可以檢查發行版是否不易受到攻擊，包括其子組件。
不僅僅是二進制庫，pip等軟件包還捆綁了大量Python庫及其源代碼， jupyter-notebook 捆綁了 TypeScript 和 JavaScript。將這些捆綁項目添加到 SBOM 也將有助于工具查找這些捆綁項目的漏洞。
2.Sigstore 簽名很混亂
發現問題：
自 Python 3.11.0 版本以來，所有 Python 版本 tarball 均使用 Sigstore 進行簽名。
給定 Python 版本（即 3.7、3.8 等）的每個發布經理在 Sigstore 信息頁面都有一個身份（電子郵件地址為@python.org）。Sigstore 使用 OpenID Connect，這意味著我們還需要指定一個身份 (IdP) 來驗證簽名。
圖片
據了解，驗證簽名的說明與工件的簽名方式并不一致。我整理了一些簡單的腳本，這些腳本嘗試根據其簽名驗證每個 Python 版本工件并發布結果。其中發現了一些問題：
- Ned Deily 和 ?ukasz Langa 使用GitHub 的IdP，Pablo Galindo Salgado 和 Thomas Wouters使用 Google 的 IdP。
- 所有簽名的 ?ukasz 身份都是lukasz@langa.pl，而不是記錄在案的lukasz@python.org。
- Python 3.11.4 是使用 Pablo 的正確身份進行簽名的，但使用的是 GitHub 的 IdP，而不是 Google 的 IdP。
- Python 3.7.14 是由 Pablo 簽署的，但 Ned 是 3.7 的發布經理。
- Python 3.8.14和3.9.14已生成簽名，但由于權限問題而無法訪問python.org/download。
- Python 3.10.1 和 3.10.7 及以上版本已簽名，但 3.10.0 和 3.10.2-3.10.6 未簽名。不過這很好，因為只有 3.10.7 及更高版本被記錄為已簽名。
解決辦法：
根據這些發現，發布經理采取了以下步驟，以使簽名驗證保持一致：
- Ned 以自己的身份退出了 3.7.14 版本。
- Pablo 從 3.11.4 退出了 Google IdP。
- ?ukasz 修復了 3.8.14 和 3.9.14 的權限，使簽名可用。
- 必須清除 CDN 緩存才能使更新可用。
你可以在對上述數據集中看到狀態的變化。此刻需要做的就是在簽名上修復 ?ukasz 的身份。我還在 Python 的發布工具中打開了一個 PR ，以使 Sigstore 簽名與未來 Python 版本的文檔保持一致。
3.證書和信任庫問題
早在 7 月底，certifi 就發布了關于刪除 e-Tugra 根證書的 GHSA 公告。該公告有一個關聯的 CVE ID，因此最終應該會進入 PyPA 公告數據庫，但自動化無法自動導入它。該問題解決后，pip 能夠獲得 PR 升級證書到最新版本。
發現問題：
Certifi 是Python生態系統中的一個關鍵包，由于Python的ssl模塊與 OpenSSL 庫的緊密聯系，它是配置 SSLContext 實例的最常見方式。
每當根 CA 出現安全問題時，在 pip 中使用 certifi 的后果（特別是由于捆綁）會導致一系列問題：
- Mozilla Root CA Bundle 中發生刪除。
- Certifi 捆綁了 Mozilla Root CA Bundle，需要更新、咨詢和新版本的 certifi。
- Pip 捆綁了 certifi，需要新版本的 pip。
- 新的 pip 版本需要發布get-pip。
- Python 捆綁了 pip 的默認版本，并且最好捆綁不易受任何 CVE 攻擊的 pip 版本（但用戶可以修復此問題）。
每當 certifi 中刪除 CA 時，此更新鏈都會導致大量混亂，并且不考慮單個應用程序鎖定文件中需要發生的所有升級。
解決辦法：
Truststore 是我和 David Glick 編寫的一個庫，可以通過使用系統信任存儲而不是硬編碼捆綁來消除對證書的需求，這樣一來保持信任存儲的責任就在系統本身上（對于 macOS 和Windows 可以在后臺自動更新）。
由于PDM通過 pdm[truststore]或pdm[all]安裝時采用了該庫，Truststore 最近收到了大量消極用戶。如果安裝了 truststore，則會自動使用代碼路徑，這意味著我們可以確保該庫按預期工作，適用于各種應用配置。我一直在監控 PDM 的問題跟蹤器中是否存在與信任庫相關的問題，到目前為止，每天安裝大約 2,000 次后還沒有出現任何問題。
如果已經安裝了信任庫，pip 目前支持使用信任庫，并且我有一個出色的 PR，可以向 pip 添加信任庫支持，而無需單獨安裝該庫。
下面是直接依賴于 certifi 的項目列表（按下載量排序），這些項目也可能是從 certifi 切換到 truststore 的備選方式，但不存在與 pip 相同的捆綁證書問題：
圖片
該列表是根據 pypi-data 數據集上的以下 SQL 查詢生成的。
圖片
我希望能夠放棄 certifi，以減少使用 PyPI 作為 CA 分發渠道所產生的流失量。
二、三個關鍵“原則”
在 9 月份的演講中，Larson 強調了他作為 PSF 駐場安全開發人員工作的三個“指導原則”：可持續性、清晰度和可見性。
“可持續性”意味著要專注于產生持久的影響，包括改進流程、自動化、處理官僚主義或發布標準。全職意味著有一個寶貴的機會進行改進，這需要一致和長期的承諾，例如與外部組織合作、跟上新標準以及向其他開源生態系統安全人員倡導 Python 的觀點。開展這項工作并提供成果應該有助于解鎖進一步的下游改進，而不會給志愿者帶來時間負擔。
“清晰度”：開源軟件安全領域一直在經歷新舉措、新技術以及爆炸式增長。隨著新安全工具的不斷出現，Larson 努力保持思路清晰，從而找出最適合 Python 生態系統的方法。
“但我一個人做不到！開源領域有很多專家，他們比我更了解他們感興趣的領域。我們可以互相學習。”
“可見性”：這個角色所做的大部分工作都將公開完成，Larson將通過博客文章和公告的形式，讓Python 生態系統的安全問題得到更多的關注。
“我對迄今為止所取得的成就感到非常自豪，”Larson 在 10 月份的一篇博客文章中寫道，“這顯示了通過雇用人員全職工作來投資開源安全的價值。”
三、寫在最后
針對開源項目和基礎設施的開源供應鏈發生的安全攻擊與日俱增，讓人們越來越認識到 Python 和 PyPI 等提供安全可靠的生態系統的重要性。
此前，PSF 對關鍵安全問題的改進，只是從專門的志愿者團隊或者現在有基礎設施工作人員中抽時間來進行，或者偶爾收到贈款才會專門去做。
如今，PSF 在維護Python安全和促進Python社區發展方面做出不少努力。光是2023年，PSF就招聘了一位常駐安全開發人員，一位 PyPI 安全和安保工程師，以及支持社區活動和傳播的兩位全職工作人員，讓 Python 社區變得更加強大和多元。
除了招兵買馬壯大隊伍，PSF 今年終于獲得授權成為 CVE 編號機構（CNA）。這是 PSF 改善 Python 生態系統關鍵項目漏洞響應流程戰略的重要里程碑。Python 軟件基金會 CNA 范圍涵蓋 Python 和 pip，這兩個項目對于 Python 生態系統至關重要。
Larson 的加入將負責解決 CPython 和 PyPI 等 PSF 項目的安全問題，并與社區志愿者合作實現關鍵措施的改進，此外還將建立新的流程和功能，讓預防、檢測和應對安全風險變得更容易，從而使整個社區能夠更輕松、可持續地識別和解決未來的安全問題，期待 Larson 和他的伙伴們能帶來更多創新和驚喜。
參考鏈接：
https://thenewstack.io/pythons-new-security-developer-has-plans-to-secure-the-language/
