跳到正文
ITDWeb 安全平台
ITD
搜索

安全指南

#AI 时代的准备#安全基础#CVE 监控#MFA

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 天。2024 年 1 月，英国国家网络安全中心（NCSC）也评估认为，未来两年 AI「几乎肯定」会增加网络攻击的数量。每月更新一次的习惯，有时会来不及。

现在该夯实的顺序（按优先级排序的清单）

从上往下。每一项都链接到本站更详细的讲解。

1

监控依赖关系的 CVE，并立即打补丁

已公开的已知漏洞，借助 AI 的『即时利用』已成现实。用机器来盯着，就能弥补人工的疏漏（→ CVE 应对实务・用 OSV 监控依赖・Next.js 的 CVE 跟进）。
2

停止密码复用，启用 MFA

应对加速中的暴力破解与复用撞库最有效的措施。密码管理器＋抗钓鱼的 MFA/通行密钥（→ 密码管理器・MFA 指南）。
3

清除暴露在外的机密文件

盘点一下 .env、密钥、备份是否残留在公开路径上。自动扫描会最先找到它们（→ 公开目录里的机密・.env 暴露的案例・.env 与 API key 的基础）。
4

最小权限，减少被入侵时的损害

即便被入侵，也要把损失限制在一个范围内。把密钥、权限收到必要的最小限度（→ SSH 密钥的最小权限）。
5

收缩公开面，阻止冒名

关掉不必要的管理后台与危险文件，用邮件认证防止他人冒用自己的域名（→ 冒名邮件对策・CORS 配置错误・会话固定）。
6

加固依赖与 Git

防患于未然，避免把机密提交进去，守护源代码供应链（→ 用 gitleaks 防止机密混入・自建 Git vs GitHub）。
7

留存日志，做到能凭 IOC 察觉

完全的防止是不可能的。要有能凭『行为』检测出未被拦住的入侵的准备（→ 什么是 IOC・什么是 IOA・什么是 EDR）。
8

准备好备份与恢复

其他对策失效时的后备手段。事先实际演练一下从勒索软件或破坏中恢复的手段（→ 备份与恢复）。

速查表：频率与工具

把上面 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 推送保护
8. 备份在别处保存一份副本，并试着还原一次每三个月做一次还原测试服务商的快照、外部存储

个人账户向公开仓库推送时，GitHub 推送保护默认开启。它不覆盖私有仓库和其他 Git 服务，所以要搭配 gitleaks 这类本地检查。

常见错误与对策

常见错误会发生什么对策
收到更新通知，却没有确认是否已应用明明有修复，漏洞却一直开着更新后确认版本，并重新扫描
从文件和历史记录中删除泄露的密钥后就停手不作废的话，拿到副本的人仍然能用先在签发方作废，再换成新密钥
只给自己的账户开启 MFA有人从共用的管理员账户或旧账户进来列出所有有管理员权限的账户，全部开启
把备份放在同一台服务器上服务器故障或被加密时，备份也一起没了存放到别处，并实际测试还原
把 AI 写的配置或代码直接部署到生产环境调试输出或写死的机密被留了下来发布前运行机密检测和依赖扫描

真实的案例

成为本站起点的那起事故，就是一个典型例子。把用 AI 写的代码公开后不久，API key 就被窃取，遭到了盗刷。原因是把一个已公开的最高等级 CVE（CVSS 10.0）放任了数月之久。 这是 AI 让未修补的弱点代价更高的一个具体例子（→ 用 AI 写的代码泄露 API key 的案例）。

同类型的案例还有其他。

  • Equifax（2017 年）：Apache Struts 漏洞的修复在公开当天就已发布，但没有应用到一个对外系统上，约 1.47 亿人的个人信息因此泄露。这就是跳过第 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、复用的密码、一直暴露在外的机密文件）。所以正如本文所讲，按优先级夯实基本功，才是性价比最高的准备。

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 推送保护；多因素认证大多数服务都内置了。容易花钱的是检测产品和备份存储，两者都可以等基本功做完之后再考虑。

Q这份清单多久应该重新检查一次？
A

依赖扫描每周运行一次，或在每次代码变更时自动运行。账户和密钥的复查、备份的还原测试，大约每三个月一次。开始使用新服务或负责人变更时，也要重新检查。