AI 资源库 · 已整理 8 项
查看与漏洞管理相关的 AI 资讯、工具、Skill、工作流和开源项目。
Dynatrace 推出了一个叫「漏洞风险暴露」的新仪表板，把漏洞到底影响哪些主机、进程和 Kubernetes 环境集中到一张图里看。原来只看漏洞数量，既不知道哪些进程受影响、漏洞扩散有多广，也看不出是不是所有该扫描的进程都扫了。这个仪表板把暴露情况、受影响对象和扫描覆盖率放在一起，还支持按团队、集群、命名空间筛选，让团队先修影响面最大的漏洞，并发现没被扫描到的盲区。该功能随文章发布，原文未说明具体开放时间或付费情况。
AI 让软件开发变快，也让漏洞被找到和利用的速度变快。过去安全团队靠一张表格记录漏洞、按严重程度打分再排优先级，但现在漏洞太多，这种方法很难跟上。文章提出换个问法：不要只问“我们有多少个漏洞”，而要先问“哪些漏洞真的会给我们带来风险”。做法包括：用更干净的基础镜像和代码扫描减少漏洞进入系统，同时持续扫描真正在生产环境里运行的软件，并结合网络可达性判断风险。这样能帮团队少做“表面功夫”，把精力放在真正危险的地方。
提供的材料未提及具体可用工具。
AI 编程工具让开发者写代码快了很多，但也让攻击者更容易找到和利用漏洞。文章说，现在 AI 不只帮人写代码，还在替人选择用哪些开源库；一旦攻击者攻破某个被广泛信任的开源组件，就可能像推倒多米诺骨牌一样影响很多下游系统。作者认为，组织不能只等扫描出漏洞再修，而要把更多精力放在“入口把关”，也就是确认进入开发流程的软件来源和内容是否可信。对读者的用处是：理解为什么软件供应链安全需要提前预防，而不是事后检测。文章没有说明具体的解决工具或发布日期。
提供的材料未提及具体可用工具。
三家安全研究员在常用图片处理库里发现了一个可被恶意文件触发的漏洞，原本想用它入侵 OpenAI 的官方论坛。简单的漏洞利用不难，难的是在真实服务器上用它远程控制机器；他们先让 Claude Opus 4.8 做这一步，但在系统正常开启内存随机化保护时失败了。当晚 Anthropic 发布 Opus 5，第二天换上新模型后，约三个小时就做出了可用的 ARM64 攻击，四小时后拿到了测试论坛的远程控制权。最终他们串起了从论坛漏洞、OpenAI 单点登录权限过大，到员工 Codex 账号、公司私有代码库的完整路径，并用一个无害的文档修改证明访问成功后就停手。这事的意义是：以前需要资深专家花大量时间做的漏洞利用开发，现在可能相当一部分能交给 AI 完成。目前这是研究者公开的实验记录，OpenAI 已修复权限并给了一笔漏洞赏金。
recetariodmix/garak · 🔍 Discover vulnerabilities in LLMs with garak, a tool that probes for weaknesses like hallucination, data leakage, and misinformation effectively.
garak 是一个用 Python 编写的 LLM 漏洞扫描工具，通过探测幻觉、数据泄露和虚假信息等弱点，帮助识别大语言模型应用中的安全隐患，并生成报告以呈现潜在风险。
Trail of Bits 发文批评 1Password 于 2026 年 8 月 6 日发布的 FLAWED 报告，认为其“模型仅 26% 生成干净修复”的结论具有误导性。文章指出该报告存在样本偏向复杂漏洞、部分提示词故意要求应用错误修复、超过三分之一试验禁止构建或运行代码、两个模型使用不同推理强度等问题。重新分析其数据后发现，在允许运行代码且未被误导的试验中，1Password 模型生成的 3,067 个补丁中有 2,634 个（86%）成功阻止了给定漏洞利用。文章还发布了两项 agent 技能：post-patch-validation 与 review-walkthrough。
一家有全球业务的300人B2B公司，被安全扫描发现有一个暴露在互联网上、认证很弱的数据库，看起来是最该优先修的高危问题。但研究人员仔细一看，这其实只是一个可以重置的测试数据库，用来考核应聘者，根本不存客户数据。这件事说明，光靠扫描器的严重性评分，没法判断一个漏洞真正会带来多大业务损失，团队还是得结合业务重要性、是否能被攻击者触达、是否已被实际利用等信息来决定先修什么。对外部安全分诊伙伴和公司安全团队来说，价值在于把“技术上很严重”和“业务上很要紧”区分开，避免把有限精力浪费在噪音上，同时也不错漏真正危险的漏洞。
{unscripted} 2026 旧金山站围绕 AI 智能体在软件交付生命周期中的信任、安全与采用展开讨论。核心观点包括：信任是底线，护栏应针对可逆性设置；攻击者利用漏洞的时间已从 125 天缩短至约 1 天，而防守方平均仍需约 7 天修补；代码审查而非代码生成正成为新瓶颈。