2025-12-31 by 高田鑑識

在應用程式安全（Application Security, AppSec）領域中，焦點往往集中在負面事件上：新的攻擊手法、工具與函式庫中出現的新漏洞、以及我們的組織與開發人員所仰賴的系統與基礎架構中不斷浮現的新弱點。然而，在這一切之外，也有許多正向的發展正在發生。

2025 年確實面臨重大挑戰——從幾乎失去 CVE 計畫的危機，到全球首個 NPM 蠕蟲事件。但同時，也出現了一些真正的進展。這些成果並非新產品、新聞稿或空洞的承諾，而是實質且有意義的改變，使開發人員與 AppSec 團隊能在現實限制下，更容易地採取正確且安全的行動。

以下是其中六項值得關注的成果：

儘管沒有人希望看到 Shai-Hulud（尤其是兩次爆發！），但這場事件最終成為壓垮駱駝的最後一根稻草，促使 JavaScript 與 TypeScript 生態系中的主要參與者採取積極行動，讓攻擊者更難將受信任的 npm 套件轉化為惡意軟體的傳播管道。

公開的 npm 登錄資料庫（registry）已進行多項變更，直接降低了套件維護者與使用者所面臨的風險；同時，GitHub 也加強並加速推行了多項相關計畫：

• 對高影響力發佈者強制實施雙重驗證（2FA）
  這項措施大幅提高了攻擊者成功竊取合法開發者帳號的難度。GitHub 已經實施強制 2FA 一段時間，而 npm 也終於跟進；此舉有效杜絕了針對關鍵函式庫維護者的一鍵式釣魚攻擊。
• 以短期存活權杖取代長期憑證的「Trusted Publishing」機制
  npm registry 於 2025 年中推出 Trusted Publishing，這項方法最早由 Python Package Index（PyPI）採用，允許 CI/CD 平台透過 OIDC 驗證機制取得有效期限極短、權限範圍極窄的發佈權杖（token）。如此一來，即使攻擊者竊得 npm 憑證，也會因其快速失效而無法利用。GitHub Actions 很快支援了這一機制，而 Shai-Hulud 事件更進一步促使各組織採用這種更安全的發佈流程。
• 移除攻擊者常利用的舊版權杖建立途徑
  npm 專門處理了攻擊者濫用的「經典（classic）」存取權杖問題——這類權杖可存取發佈者帳號下的所有儲存庫。2025 年 12 月，npm 撤銷了所有殘留的經典權杖，並預設採用更安全的設計：新權杖僅能存取特定套件，且有效期僅 7 天（必要時可擴展至 90 天）。此舉藉由限制權杖存活時間與存取範圍，有效降低了權杖外洩所造成的風險。
• 更快速的協調下架惡意活動
  當惡意活動被確認後，GitHub 與 npm 已建立協作機制以加速應對與下架流程，同時整體防禦社群也傾向採用更開放的協作方式，共同分享威脅情報。

綜合而言，這些變革在不增加開發人員與 AppSec 團隊負擔的前提下，顯著提高了攻擊者發動攻擊的難度。

隨著 Microsoft 的 Visual Studio Code、GitHub 的原始碼管理與 Actions CI/CD 系統引領潮流，2025 年出現了一系列低調但關鍵的改善——這些預設設定的調整旨在保護開發人員免受供應鏈攻擊與其他針對性威脅的影響。以下是幾個具代表性的例子：

• 更嚴格的外掛與擴充模組執行邊界
  針對「零點擊（zero-click）」類型攻擊，Microsoft 的 Visual Studio Code 等平台要求更多擴充模組必須經由明確啟用才能執行（而非安裝後自動啟用）。這降低了開發人員意外繞過或停用 Workspace Trust 控制機制的風險，並加強了對於可被濫用行為（如無需使用者互動的背景執行）的審查。
• 降低第三方整合的預設權限
  開發生態系更重視「安全預設值」與「最小權限原則」。例如，GitHub 調整 Actions 中使用的預設權杖（token）權限，縮小其作用範圍與有效時間。此舉在幾乎不影響 DevOps 與開發團隊運作的前提下，大幅提高了攻擊者進行常見攻擊所需的難度與成本。
• 更完善的建置與測試環境隔離機制
  多家服務供應商密切合作，推動以 OIDC 與其他短期、範圍受限的憑證作為跨服務整合的預設與建議方案，使建置與測試流程自動與開發人員個人憑證分離。這種設計既能確保建置與測試任務穩定執行，又能在開發帳號或工作站遭入侵時保護組織安全，同時維持開發效率。

更安全的預設設定與明確的「安全捷徑（secure paved paths）」使安全作法成為最簡單的選項，讓組織在不犧牲開發者生產力的情況下，提升整體安全性與韌性。對任何 AppSec 改進而言，「不惹惱開發人員」本身就是一項極佳的成果。

自從 GitHub Actions 引入 pull_request_target 事件以來，GitHub 一直提醒開發者與 DevOps 團隊：這項便利功能同時也帶來一定風險。舉例而言，若設定不當，這類事件可能被濫用形成所謂的「pwn requests」——惡意的 Pull Request 能夠存取機密資訊（如憑證或密鑰），並將其外傳給攻擊者。

然而，GitHub 並未將責任全數推給使用者，而是在 2025 年 12 月引入新的限制措施，以防範這類攻擊。這些更新包含：限制外部 PR 對潛在不安全工作流程（workflow）檔案的存取權限，並封鎖所有依賴「不受信任分支名稱」的攻擊途徑。

這一變革充分體現了 GitHub 在自動化與開發效率需求，與安全預設值及可審核性之間取得的平衡。它讓開源生態系的維護者與貢獻者能更輕鬆地防禦惡意行為，同時維持穩定的協作與開發流暢度。

另一項令人振奮的「非技術性」進步，來自安全研究社群的文化轉變——特別是在面對重大弱點與高影響力惡意軟體攻擊行動時的協作方式。

在 2025 年，我們觀察到以下幾項顯著變化：

• 減少爭奪媒體版面焦點：研究人員更傾向於採取協調式揭露（coordinated disclosure），並將重點放在維護整體社群安全，而非追求個人聲量。
• 跨組織協作應對事件：例如在 Shai-Hulud 等安全事件期間，研究人員鼓勵並促進受影響組織之間的資訊共享與聯合應變，而非試圖獨占討論主導權。
• 更廣泛的成果共享與互相致謝：研究人員在擴展他人研究成果的同時，更積極地協助放大他人的貢獻，形成正向循環。

對防禦方而言，這種改變意味著能更快速掌握事件全貌與應對策略，並顯著減少因恐慌而導致的即興應變行為。
對研究人員而言，這增進了社群內部、以及研究者與平台營運方、防禦團隊之間的 信任關係——而這種信任，正是能在傳統流程之外快速緩解與修復安全問題的關鍵基礎。ㄎ

2025 年 4 月，MITRE 所主導的 CVE（Common Vulnerabilities and Exposures）計畫 一度面臨危機。由於美國聯邦政府對 CVE 及相關計畫的資金支持出現不確定性，業界一度擔憂這些關鍵基礎設施的未來發展。然而，安全社群的回應展現出卓越的韌性與組織能力：

• 成立 CVE Foundation：這個新組織致力於多元化資金來源，並推動 CVE 計畫建立更透明且獨立的治理架構。
• 提升對 EUVD 的關注與投入：EUVD 是歐洲版的弱點資料庫，可視為美國 NVD（National Vulnerability Database）的替代方案之一，同時也為高度依賴 CVE 系統的機構提供了「備援計畫」。
• 強化對 OSV 的支持：OSV（Open Source Vulnerabilities）專注於開源生態系的弱點通報機制，由 Google 與 OpenSSF 共同協作開發，確保該系統能獨立於 MITRE 的 CVE 計畫之外運作。

整體而言，這次事件提醒了業界：應用程式安全社群並非依附於單一來源或政府支持，而是具備足夠的工具與前瞻思維，能在充滿挑戰的情況下，持續維護全球軟體生態的安全與穩定。