先抛结论AI 用于网络安全不是万能钥匙也不是一点用没有。过去半年我们围绕“AI 能否真正参与安全工作”做了一轮系统性实测覆盖告警降噪、代码安全审计、安全基线核查这几个高频场景。结果比预想的更有参考价值AI 在辅助分析、结果解释、效率提升方面表现明显但它仍然更像一个“高水平的实习生”而不是可以完全托管安全决策的“自动防御系统”。这篇文章会把这次实测的设计思路、环境配置、三个典型场景的完整代码、评测结论、常见坑点和工程化建议全部整理出来。无论你是安全工程师、运维开发还是刚准备入门网络安全的同学都可以参照这套流程做一次自己的小实验。1. 背景为什么大家都在讨论“AI 搞网络安全”1.1 一个半年实测项目的由来近几年大模型的能力越来越强很多人开始尝试用 AI 做代码修复、文档生成、数据分析。但在网络安全方向讨论总是两极分化。一边是“AI 漏洞挖掘大杀器”的宣传另一边是安全老手吐槽“AI 连告警都分不清”。我们做这次实测的初衷很简单不吹不黑把 AI 放进真实安全工作流里看它到底能承担哪部分工作、在哪些环节帮倒忙、哪些环节必须保留人工决策。测试周期拉到了半年是为了尽量覆盖不同版本迭代、不同来源的告警数据以及不同复杂度代码审计任务。1.2 先分清几个容易混淆的概念很多刚接触的同学会把下面几个概念混在一起这里先做一个区分概念含义典型场景AI 安全Security for AI保护 AI 系统本身的安全提示词注入、模型窃取、训练数据投毒AI 赋能安全AI for Security用 AI 技术提升安全工作效率告警降噪、日志分析、代码审计辅助传统安全自动化基于规则和脚本的自动化定时扫描、基线核查、SIEM 规则命中本文的核心是第二种AI for Security也就是把大模型作为安全分析工作流中的一环来辅助人做判断。1.3 哪些读者适合阅读本文这篇文章适合下面几类读者刚入门网络安全想了解 AI 和安全的结合点在哪里。后端开发或运维需要做告警处理和代码安全自查。安全工程师希望用 AI 减少重复性分析工作。技术负责人需要评估 AI 安全工具的采购或自研成本。读完这篇文章你会得到一套可以自己复现的实测框架而不是空泛的“AI 很厉害”或“AI 不行”的结论。2. 环境准备与版本说明在动手之前先把实验环境说清楚。需要说明的是AI 相关工具链更新非常快下面的版本只是一个参考你在实际环境里需要根据自己的项目情况调整。2.1 基础运行环境这次实测使用的是一台 Linux 服务器配置为 8 核 CPU、32GB 内存操作系统为 Ubuntu 22.04 LTS。Python 版本为 3.10主要负责数据处理和调用大模型接口。除此之外还需要准备一个可访问的大模型 API 服务或者是本地部署的模型服务。一份经过脱敏处理的告警日志数据。一个待审计的测试代码仓库允许授权测试。一套安全基线配置模板例如 SSH、Nginx 的加固建议。安全提示本次所有测试数据均在授权范围内使用生产环境数据必须经过完整脱敏并且涉及真实系统时必须获得明确授权。2.2 项目目录结构为了便于复现建议按下面的目录结构组织项目ai-security-test/ ├── data/ │ ├── alerts/ │ │ └── alert_demo.csv │ └── source_code/ │ └── demo_app/ ├── src/ │ ├── alert_analysis.py │ ├── code_audit.py │ └── baseline_check.py ├── prompts/ │ ├── alert_prompt.txt │ ├── audit_prompt.txt │ └── baseline_prompt.txt └── requirements.txt2.3 依赖安装本次示例主要依赖下面几个 Python 包pip install pandas openai pyyaml如果你使用本地模型或私有化部署的 OpenAI 兼容接口只需要调整base_url和api_key即可代码逻辑不需要大改。# 文件路径src/config.py import os API_BASE os.getenv(LLM_API_BASE, https://your-llm-endpoint.example.com/v1) API_KEY os.getenv(LLM_API_KEY, ) MODEL_NAME os.getenv(LLM_MODEL_NAME, your-model-name)注意API Key 绝对不要写死在代码里建议通过环境变量或密钥管理服务注入。3. 实测方向一用 AI 做安全告警分析与降噪3.1 场景痛点SOC安全运营中心中最常见的痛点是告警量太大。大量安全设备每天产生成千上万条告警真正需要人工处置的可能只有 2% 到 5%。传统的降噪方案依赖规则但规则写得太死容易漏报写得太松又会引入大量误报。我们的想法是先用规则把明显无效的告警过滤掉再利用大模型对剩余告警做语义理解和聚类让安全分析师更快定位真正的高危事件。3.2 数据准备首先准备一份脱敏后的告警数据字段包括时间、源 IP、目标 IP、告警类型、严重级别、告警描述。下面是一个演示用的 CSV 结构timestamp,src_ip,dst_ip,alert_type,severity,description 2025-03-01 10:23:15,192.168.1.10,192.168.1.20,SQL_INJECTION,high,possible sql injection pattern in request parameter 2025-03-01 10:23:16,192.168.1.10,192.168.1.20,SQL_INJECTION,high,possible sql injection pattern in request parameter 2025-03-01 10:24:01,172.16.0.15,192.168.1.30,BRUTE_FORCE,medium,multiple failed login attempts detected 2025-03-01 10:24:02,172.16.0.15,192.168.1.30,BRUTE_FORCE,medium,multiple failed login attempts detected 2025-03-01 10:24:03,172.16.0.15,192.168.1.30,BRUTE_FORCE,medium,multiple failed login attempts detected用 pandas 做第一层处理把重复告警聚合起来# 文件路径src/alert_analysis.py import pandas as pd def load_and_aggregate(csv_path): df pd.read_csv(csv_path) # 按时间段、源 IP、目标 IP、告警类型聚合统计出现次数 df[time_bucket] pd.to_datetime(df[timestamp]).dt.floor(5min) grouped df.groupby( [time_bucket, src_ip, dst_ip, alert_type, severity] ).agg( count(description, count), sample_desc(description, first) ).reset_index() return grouped.sort_values(count, ascendingFalse) if __name__ __main__: result load_and_aggregate(../data/alerts/alert_demo.csv) print(result.head(10))这段代码最关键的是groupby聚合操作把 5 分钟窗口内相同来源、相同目标、相同类型的告警合并成一条并统计次数。这样大模型需要处理的输入就从几千条变成了几十条既省成本又能聚焦高风险事件。3.3 调用大模型生成告警研判建议接下来把聚合后的告警信息交给大模型让它生成研判建议。为了让输出更稳定我们使用提示词模板。提示词文件prompts/alert_prompt.txt内容如下你是一名网络安全运营分析师。下面是几条聚合后的安全告警请对它们进行研判。 要求 1. 判断是否可能是真实攻击。 2. 判断是否需要升级处理。 3. 给出建议的下一步操作。 4. 如果信息不足明确说“需要补充上下文”。 告警内容 {alert_context}Python 调用代码如下# 文件路径src/alert_analysis.py import os from openai import OpenAI from config import API_BASE, API_KEY, MODEL_NAME client OpenAI(base_urlAPI_BASE, api_keyAPI_KEY) def analyze_alert(row): context ( f时间窗口{row[time_bucket]}\n f源IP{row[src_ip]}\n f目标IP{row[dst_ip]}\n f告警类型{row[alert_type]}\n f严重级别{row[severity]}\n f发生次数{row[count]}\n f描述{row[sample_desc]} ) with open(../prompts/alert_prompt.txt, r, encodingutf-8) as f: prompt_template f.read() prompt prompt_template.replace({alert_context}, context) resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你是一个严谨的安全分析助手。}, {role: user, content: prompt} ], temperature0.2, ) return resp.choices[0].message.content if __name__ __main__: aggregated load_and_aggregate(../data/alerts/alert_demo.csv) top_alert aggregated.iloc[0] print(analyze_alert(top_alert))这里temperature设置为 0.2是为了让输出更稳定减少模型自由发挥。安全分析的结论应该尽量一致不能一会说是一会说不。3.4 实测结论效率提升明显但不能直接信任从半年的实际使用体验来看AI 在告警降噪这个方向的效果是最值得肯定的。它可以把重复告警压缩 80% 以上并且在大多数情况下能给出合理的研判方向。但有一个很关键的坑当告警确实就是同一事件的重复上报时模型容易把“次数多”误判为“危害大”。例如暴力破解尝试次数很高但可能来自同一个失陷账号的自动化行为处置方式和 SQL 注入完全不同。所以我们的实际做法是让 AI 输出“研判建议”而不是“最终结论”。4. 实测方向二用 AI 辅助代码安全审计4.1 为什么代码安全审计适合 AI 辅助代码审计是安全团队的重要工作也是耗时大户。传统工具比如 SAST 能扫描出很多问题但误报率往往偏高。人工审计准确率高但速度慢不可能每个项目都完整人工过一遍。AI 在这个场景中适合做两件事第一对可疑代码片段做解释帮助开发人员理解漏洞成因第二结合上下文判断一段代码是否真的存在风险。4.2 建立轻量规则预筛选先用正则规则把明显的关键函数调用筛出来例如 SQL 拼接、命令拼接、文件路径拼接等。这里以 SQL 拼接为例。# 文件路径src/code_audit.py import re FOLLOWED_FUNCTIONS [ execute, exec, query, rawQuery, ] DANGEROUS_PATTERNS [ re.compile(r.*SELECT.*FROM.*WHERE.*\.*, re.IGNORECASE), re.compile(r.*INSERT INTO.*VALUES.*\.*, re.IGNORECASE), ] def prefilter_code(file_path): 返回包含可疑拼接的代码片段列表。 found [] with open(file_path, r, encodingutf-8) as f: lines f.readlines() for idx, line in enumerate(lines): line_lower line.lower() if any(func in line_lower for func in FOLLOWED_FUNCTIONS): for pattern in DANGEROUS_PATTERNS: if pattern.search(line): found.append((idx 1, line.strip())) break return found这个函数只做初步筛选找到疑似存在动态拼接的代码行最终判断交给大模型。4.3 大模型审计提示词提示词prompts/audit_prompt.txt内容如下你是一名资深代码安全审计专家。下面是一段代码片段请判断是否存在安全风险。 分析要求 1. 风险类型SQL注入 / 命令注入 / 路径遍历 / 其他。 2. 触发条件用户输入是否可控是否经过过滤。 3. 危害描述在什么场景下可能被利用。 4. 修复建议给出具体代码层面建议。 5. 风险等级高 / 中 / 低。 代码片段 {code_context}注意这里并没有要求模型生成攻击载荷而是面向防御视角的修复分析。这也是我们在实际项目中的原则AI 辅助安全必须优先服务于检测、修复和防护。调用代码与告警分析类似# 文件路径src/code_audit.py from openai import OpenAI from config import API_BASE, API_KEY, MODEL_NAME client OpenAI(base_urlAPI_BASE, api_keyAPI_KEY) def audit_with_llm(code_snippet): with open(../prompts/audit_prompt.txt, r, encodingutf-8) as f: prompt_template f.read() prompt prompt_template.replace({code_context}, code_snippet) resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你是一个严谨的代码安全审计助手。}, {role: user, content: prompt} ], temperature0.1, ) return resp.choices[0].message.content4.4 效果评估误报率比预想的低但漏报仍需警惕在一个小型测试代码仓库上我们用 AI 辅助审计与人工审计做了对比。整体来说AI 对明显问题的定位能力很强输出结论也比较结构化开发人员照着修改就完事了。但有一个问题比较突出当漏洞代码被拆成多个函数、跨文件传递时单看一段片段很难发现问题。大模型如果只看局部会漏掉跨函数的污点传递。我们的优化方式是把“预筛选结果 相关调用链上下文”一起放进提示词里让模型看到入口函数、中间传参和危险函数准确率会明显提升。但这也会增加 token 成本所以需要做平衡。4.5 结论适合做人工审计前的第一道过滤AI 代码安全审计的方向可以重点投入但建议定位为“辅助工具”而不是“唯一审计手段”。在实际流程中可以把 AI 审计放在 SAST 工具之后把扫描结果交给人做最终确认。5. 实测方向三AI 辅助安全基线核查与合规检测5.1 基线核查是什么安全基线是一组系统、应用、网络设备的安全配置要求。例如 Linux 服务器是否允许 root 远程登录、SSH 是否开启密码认证、Nginx 是否关闭了不安全的 HTTP 方法、数据库是否开启了公网访问等。基线核查通常是安全运维的日常任务问题在于核查结果是一堆配置项非安全专业人员往往看不懂每一项的修复含义。AI 在这里能做一件事把配置项的结果解释成普通人能理解的整改说明。5.2 用脚本检查常见配置项下面是一个简单的基线检查脚本用 Python 读取配置文件检查关键项# 文件路径src/baseline_check.py import re import json def check_ssh_config(config_path/etc/ssh/sshd_config): findings [] with open(config_path, r, encodingutf-8) as f: content f.read() # 常见检查项是否允许 root 登录 permit_root_login re.search(r^PermitRootLogin\s(.*)$, content, re.MULTILINE) if permit_root_login: value permit_root_login.group(1).strip() if value.lower() yes: findings.append({item: PermitRootLogin, status: NG, value: value}) else: findings.append({item: PermitRootLogin, status: OK, value: value}) else: findings.append({item: PermitRootLogin, status: UNKNOWN, value: not set}) return findings if __name__ __main__: result check_ssh_config(../data/sample_sshd_config) print(json.dumps(result, ensure_asciiFalse, indent2))5.3 让 AI 生成整改建议拿到核查结果后把结论交给大模型让它生成面向运维人员的整改工单。# 文件路径src/baseline_check.py from openai import OpenAI from config import API_BASE, API_KEY, MODEL_NAME client OpenAI(base_urlAPI_BASE, api_keyAPI_KEY) def explain_baseline(findings): context json.dumps(findings, ensure_asciiFalse, indent2) prompt f 你是一名安全运维专家。下面是安全基线核查结果请对每一条生成 1. 不符合项说明。 2. 可能造成的安全风险。 3. 具体整改命令或配置修改建议。 4. 整改后如何验证。 核查结果 {context} resp client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperature0.3, ) return resp.choices[0].message.content这种“脚本检查 AI 解释”的组合方式在实际使用中反馈很好尤其是对开发刚接手安全整改的场景能减少大量沟通成本。5.4 结论安全基线检查是低风险高收益的 AI 落地场景这个方向不容易出错因为 AI 只做解释和建议不直接执行配置变更。更重要的是配置变更本身需要在测试环境验证AI 只是提高了“发现问题到完成整改”的效率。6. 半年实测结果汇总AI 到底行不行6.1 能力评测总结把三个方向的评测结果汇总成一张表方便快速查看场景效率提升结果准确率小样本人工依赖程度推荐落地优先级告警日志降噪与研判很高重复告警压缩明显较高但存在误判可能高需要人工复核高代码安全审计辅助中高批量扫描效率提升明显中高跨函数场景会漏报高需人工确认高安全基线核查与整改解释高直接产出整改建议高配置项解释稳定中高漏洞自动利用不推荐不稳定且有安全风险极高不落地完全替代安全运营人员不现实会漏关键上下文极高不落地6.2 我们得到的三个核心结论第一AI 在处理“大量低复杂度信息”时优势突出。告警聚合、日志分类、基线解释这类工作本质上是模式化的文本理解任务AI 做起来又快又稳。第二AI 在处理“需要完整上下文”的安全决策时能力仍然不足。网络攻击的链路往往跨越多个系统单点分析很难得出全局判断。把关键上下文喂给 AI 可以缓解但成本也会迅速上升。第三AI 的输出直接影响安全决策所以必须设计人工复核环节。这一点非常重要安全行业不像内容生成一个错误的判断就可能导致严重事故。6.3 为什么说“结果挺意外”在实测之前团队内部对 AI 的能力预期其实是偏保守的觉得大模型在安全领域最多只能做点文本整理工作。真正跑下来之后发现模型对安全告警的理解能力、对代码风险的解释能力已经超过了大多数初级分析师的水平。但意外不等于放心。模型仍然会一本正经地给出错误解释尤其在告警信息不完整时。比如把一次正常的批量登录误判为暴力破解把一段带参数化的 SQL 误报为注入风险。所以最终的结论可以概括为AI 在网络安全领域已经从“玩具阶段”走到了“辅助工具阶段”但距离“自主决策阶段”还有很长的路。7. 常见问题与排查思路7.1 告警分析不准确问题现象常见原因解决思路AI 把普通误报判成高危缺少上下文信息在提示词中加入资产重要性、历史事件信息重复告警被误判为攻击模型把“次数多”等同于“风险高”人工设置告警聚合规则输入中只保留汇聚结果模型输出不稳定temperature 设置过高降低 temperature建议 0.1 到 0.37.2 代码审计有漏报问题现象常见原因解决思路跨函数漏洞没有发现模型只看当前片段在提示词中补充入口函数和完整调用链误报多预筛选规则过宽先让正则规则剔除明显安全代码输出格式不一致提示词约束不足在提示词中给出固定格式甚至给一个 few-shot 示例7.3 调用大模型 API 报错常见错误包括连接超时、鉴权失败、token 超限。排查顺序如下检查API_BASE和API_KEY是否配置正确。在命令行用curl测试接口连通性。检查单次请求的 token 数量必要时对输入做截断。查看模型服务端日志确定是否触发了限流策略。8. 最佳实践把 AI 安全能力工程化落地8.1 明确边界AI 只提供建议不直接执行在实际安全系统中AI 输出必须经过一个“建议层”不能直接对接防火墙、EDR、云平台等执行类能力。建议先输出可读结论再通过人工或严格变更流程转化为操作。8.2 建立提示词版本管理提示词是会持续迭代的资产。建议像代码一样管理提示词放到 Git 仓库中每次修改记录变更原因。8.3 加强数据安全和隐私保护安全数据通常高度敏感。需要注意日志进入大模型前必须脱敏去掉真实的用户名、手机号、会话信息。优先选择私有化部署模型避免敏感数据出域。使用敏感信息检测脚本对输出内容做二次过滤。8.4 设置人类复核指标在流程上线初期至少让安全分析师对 AI 结论进行百分百复核并记录误判率。当误判率稳定在一个可接受范围后再考虑逐步扩大自动化比例。8.5 成本和性能平衡大模型调用成本与告警量线性相关。可以通过下面的手段控制成本先用规则把明显无害的内容过滤掉。对相似日志先聚类再让模型分析聚合结果。使用本地小模型处理简单任务大模型只处理复杂任务。8.6 和现有安全工具链打通AI 不应该孤立存在它最好嵌入到 SIEM安全信息和事件管理、SOAR安全编排自动化与响应、工单系统等已有工具链中。例如SIEM 触发高优先级告警后自动调用 AI 生成研判摘要。代码扫描工具识别问题后自动调用 AI 生成修复建议并关联到开发工单。这样 AI 的价值才不是“一次实验”而是真正进入日常工作流。9. 总结与后续学习建议这次半年实测最关键的一课是网络安全行业看待 AI既不需要神话也不需要妖魔化。它已经能在告警降噪、代码审计辅助、基线核查解释等场景做出实际贡献但前提是使用方式正确——规则过滤在前大模型分析在中人工复核兜底。如果你也想从零开始做类似实验建议按下面的顺序推进先找一份脱敏告警数据跑通第一版“规则聚合 大模型分析”流程。再拿公司自有代码仓库授权范围内做一次代码安全审计试点。最后把安全基线核查做成月度自动化巡检观察 AI 输出质量和人工复核成本。如果想继续深入下一步可以学习这几个方向提示词工程如何让大模型输出更稳定的安全结论。检索增强生成RAG把安全知识库、历史漏洞库接入模型提升判断准确性。本地大模型部署在数据不出域的前提下搭建安全运营专用模型服务。安全自动化编排把 AI 分析结果接入企业工单或 SOAR 平台。本文只是给了一个可复用的起点。真正的价值在于你能不能根据自己业务里的真实数据把小实验扩展成可维护的安全能力模块。动手跑一遍你会有自己的答案。