資安指南

AI 時代的安全防護|個人開發者現在就該夯實的基本功(按優先級排序的清單)

AI 讓攻擊者能自動、大規模利用常見弱點,最好的準備是按正確順序夯實基本功。為個人開發者整理按優先級排序的清單:CVE 修補、停用重複密碼與 MFA、清除暴露的機密、最小權限與備份。

發布於 2026-06-26 更新於 2026-10-06 閱讀時間 4 分鐘
本頁內容

「等高效能 AI 普及了,安全到底會有什麼變化」——答案其實意外地樸素。需要的並不是什麼特別的新對策,而是把那些隨處可見的基本功『現在』做到位,其價值上升了。我們從防禦的角度,把其中的原因,以及現在該按什麼順序夯實,梳理清楚(不涉及攻擊手法)。

為什麼是『現在』

AI 與其說是在『發明』攻擊,不如說是在放大既有的攻擊。從防禦角度需要把握的,是下面這 5 個方向(都是為了防禦而應當了解的趨勢,不涉及手法細節)。

① 自動化的偵察與漏洞探測大規模化(不停掃描整個網際網路)
② 剛公開的 CVE 被即時利用(從公開到被利用的時間差在縮短)
③ 針對性釣魚變得流暢、個人化、大批量
④ 暴力破解、重複使用密碼的撞庫(credential stuffing)加速
⑤ AI 寫的程式碼,連同漏洞一起被公開
AI 放大的不是新型弱點,而是對隨處可見的弱點的攻擊。所以越是基本的漏洞越會被早發現。

它們的共同點是,都是經由隨處可見的基本弱點入侵。反過來說,越是把基本功夯實,即使是大規模的攻擊也越難得手。一直往後拖的基本漏洞,會最先被自動化的攻擊找到。這就是現在就該做的理由。

數字也證實了這一點。Mandiant(Google Cloud)發現,從漏洞公開到被利用的平均時間,從 2021–2022 年的 32 天縮短為 2023 年的 5 天。英國國家網路安全中心(NCSC)在 2024 年 1 月也評估,未來兩年內 AI「幾乎肯定」會增加網路攻擊的數量。每月更新一次的習慣,有時會來不及。

現在該夯實的順序(按優先級排序的清單)

從上往下。每一項都連結到本站更詳細的講解。

1

監控相依套件的 CVE,並立即打修補程式

已公開的已知漏洞,借助 AI 的『即時利用』已成現實。用機器來盯著,就能彌補人工的疏漏(→ CVE 應對實務・用 OSV 監控相依套件・Next.js 的 CVE 跟進)。
2

停止重複使用密碼,並開啟 MFA

應對加速中的暴力破解與重複使用撞庫最有效的措施。密碼管理器+抗釣魚的 MFA/passkey(→ 密碼管理器・MFA 指南)。
3

清除暴露在外的機密檔案

盤點一下 .env、金鑰、備份是否殘留在公開路徑上。自動掃描會第一個把它們撿走(→ 公開目錄裡的機密・.env 暴露的案例・.env 與 API key 的基礎)。
4

最小權限,讓入侵造成的損害更小

即便被入侵,也要把損害限制在一個區塊裡。把金鑰、權限收到必要的最小限度(→ SSH 金鑰的最小權限)。
5

收縮公開面,阻止冒名

關掉不必要的管理後台與危險檔案,用郵件認證防止他人冒用自己的網域(→ 冒名郵件對策・CORS 設定錯誤・工作階段固定)。
6

加固相依套件與 Git

防患於未然,避免把機密提交進去,守護原始碼供應鏈(→ 用 gitleaks 防止機密混入・自架 Git vs GitHub)。
7

留存記錄,做到能憑 IOC 察覺

完全的防止是不可能的。要有能憑『行為』偵測出漏網之魚的準備(→ 什麼是 IOC・什麼是 IOA・什麼是 EDR)。
8

準備好備份與還原

其他控制失效時的退路:事先實際演練一下從勒索軟體或破壞中還原的手段(→ 備份與還原)。

速查表:頻率與工具

把上面的八項分成「最先要做的」和「之後多久做一次」。頻率是本站建議的參考標準。

項目最先要做的之後多久一次工具(多數免費)
1. 相依套件的漏洞對所有專案的相依套件掃描一次每週,或每次程式碼變更時自動執行osv-scanner、npm audit、composer audit、GitHub Dependabot 警示
1. 修補期限先修補已確認被利用的漏洞(列在 KEV 上的)KEV 項目在幾天到兩週內用 CVSS、EPSS 與 KEV 決定優先順序
2. 多重要素驗證從電子郵件、GitHub、雲端與網域管理的管理員帳號開始每次建立帳號時passkey、驗證器 App
3. 暴露的機密盤點公開目錄與公開儲存庫;找到的金鑰一律撤銷每次發布前機密外洩掃描、網站診斷
4. 最小權限停用不用的金鑰、權杖與帳號每三個月各服務的存取權杖清單
6. Git 的防護加上在提交前攔下機密的檢查自動(每次提交)gitleaks、GitHub push protection
8. 備份把副本存到別處,並試著還原一次每三個月做一次還原測試服務商的快照、外部儲存空間

個人帳號推送到公開儲存庫時,GitHub push protection 預設是開啟的。它不涵蓋私人儲存庫或其他 Git 服務,所以請搭配 gitleaks 這類本機檢查。

常見錯誤與修正

常見錯誤會發生什麼修正方式
收到更新通知,卻沒確認已套用明明有修補,漏洞卻一直開著更新後確認版本,並再掃描一次
把外洩的金鑰從檔案和歷史紀錄中刪除就結束沒有撤銷的話,持有副本的人仍然能使用先到發行方撤銷,再換成新的金鑰
只替自己的帳號開啟 MFA有人從共用的管理員帳號或舊帳號進來列出所有具管理員權限的帳號,全部開啟
備份放在同一台伺服器上伺服器故障或被加密時,備份也一起沒了存到別處,並實際測試還原
把 AI 寫的設定或程式碼直接放上正式環境除錯輸出或寫死的機密被留了下來發布前執行機密偵測與相依套件掃描

實際案例

成為本站起點的那起事故,就是典型的例子。把用 AI 寫的程式碼公開後不久,API key 就被竊取,遭到了違規扣費。原因是一個已公開的最高等級 CVE(CVSS 10.0)被放任了數月之久。 這是 AI 讓未修補的弱點代價更高的具體例子(→ 用 AI 寫的程式碼洩漏 API key 的案例)。

同類型的案例還有其他。

  • Equifax(2017):Apache Struts 漏洞的修補在公開當天就已釋出,卻沒有套用到對外公開的系統,導致約 1 億 4,700 萬人的個人資料外洩。這就是跳過第 1 項的結果(→ Equifax 外洩事件)。
  • Hugging Face(2026):研究用 AI 代理的入侵,起點是被公開暴露的憑證。這就是跳過第 3 項的結果(→ Hugging Face 入侵事件)。

本站的觀點:AI 讓未修補的弱點代價更高,所以基本功要現在就做

本站認為,AI 時代的準備,是把基本功提早做好,而不是加上特別的新對策。高效能 AI 落到攻擊方手裡最見效的,不是發明零時差漏洞,而是把你一拖再拖的基本功(未打修補程式、重複使用、暴露的機密),低成本、大規模地找到並下手。所以有效的是那些樸素的基本功,按正確的順序現在就做到位。你自己網站的現狀,現在就能用 網站綜合安全診斷・郵件認證檢查器・相依套件漏洞掃描器 來檢查。光是設定好還不夠;只有真正檢查過才算生效。

出處

  • Google Cloud(Mandiant)「How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends」— cloud.google.com
  • 英國 NCSC「The near-term impact of AI on the cyber threat」(2024 年 1 月 24 日)— ncsc.gov.uk
  • 美國 CISA「BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities」— cisa.gov
  • GitHub Docs「About push protection」— docs.github.com

接下來閱讀

FAQ

Q在 AI 時代,是不是需要什麼『特別的新安全對策』?
A

多數情況下,需要的不是什麼特別的新對策,而是『把基本功,按正確的順序,現在就做到位』。高效能 AI 帶來的最大變化,與其說是新型弱點,不如說是攻擊者能夠自動、快速、大規模地找到並利用那些一直被『嫌麻煩而往後拖』的既有弱點(未打修補程式的 CVE、重複使用的密碼、一直暴露在外的機密檔案)。所以正如本文所講,按優先級夯實基本功,才是 CP 值最高的準備。

Q個人開發或小型網站也會被盯上嗎?
A

會的。自動化的攻擊省去了『由人來挑選目標』這道工序。它會不停地掃描整個網際網路,從發現弱點的地方無差別地下手,因此與規模大小無關。『我們小,所以沒事』這種想法,隨著自動化、大規模化的推進會越來越站不住腳。

Q應該從哪裡入手?
A

從本頁這份按優先級排序的清單從上往下做就足夠了。尤其是①相依套件的 CVE 監控與立即打修補程式、②停止重複使用密碼+MFA、③清除殘留在公開目錄裡的機密檔案,這三項效果最大,而且今天就能著手。你自己網站的現狀,可以用本站的免費診斷工具來檢查。

Q漏洞公開後,應該多快打修補程式?
A

對於已確認被利用的漏洞,目標是幾天之內。Mandiant 的分析發現,2023 年從公開到被利用的平均時間是 5 天。作為公開的參考標準,美國 CISA 要求聯邦機構原則上在兩週內修補其 KEV 目錄(已確認被利用的漏洞清單)中的項目(2021 年以前分配的 CVE 編號為六個月)。不在 KEV 上的,則用嚴重程度(CVSS)與被利用的可能性(EPSS)來決定順序。

Q不花錢能做到多少?
A

這份清單的大部分都是免費的。相依套件掃描可以用 osv-scanner、npm audit 或 GitHub Dependabot 警示;阻止機密被提交可以用 gitleaks 與 GitHub push protection;多重要素驗證則內建在大多數服務中。容易花錢的是偵測產品和備份的儲存空間,兩者都可以等基本功做好之後再說。

Q這份清單應該多久重新檢視一次?
A

相依套件掃描每週一次,或在每次程式碼變更時自動執行。帳號與金鑰的檢查,以及備份的還原測試,大約每三個月一次。開始使用新服務或負責人更換時,也請重新檢視。