想象你正在建造一栋智能大厦。过去,很多团队的做法是:先埋头盖楼,等交付前一晚才请保安来“检查一下哪里能翻墙进来”——结果发现窗户没锁、后门大开、监控形同虚设,只能连夜返工,成本高到惊人。而今天我们要聊的“AI 应用安全开发生命周期”,就像是把这套安防思路从交付前的一道工序,拆解并融入打地基、砌墙、布线、装修、验收、运营的每一个环节。你不需要等大楼盖好才操心安全,而是在每一块砖里就埋好“安全钢筋”。这套方法论在业界叫 Sec-AI-DevOps:它把安全(Security)、人工智能(AI)与 DevOps 的持续交付节奏缝合在一起,让你开发的每一个 AI 应用,从需求分析的第一张图纸起,就自带防御基因。无论是防止提示注入攻击、模型窃取,还是应对数据投毒,这套生命周期都能帮你系统性地见招拆招。

岗位关联

对 AI 从业者而言,掌握 Sec-AI-DevOps 意味着你不再是被动“救火”的开发者,而是能从源头设计安全、在红蓝对抗中掌握主动权的稀缺人才——这正是 AI 工程化时代最值钱的能力之一。

目录
  1. 可视化演示
  2. 概念与价值:把安全从“收尾工序”变成“钢筋结构”
  3. 需求与建模:先画清“谁可能从哪扇窗翻进来”
  4. 设计与编码:每一块砖都砌进“防撬结构”
  5. 测试与门禁:竣工前的“全系统打压试验”
  6. 部署与运维:交付不是终点,而是安全的新起点
  7. 红蓝与AI专项:用“攻防演习”检验整栋大厦
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示AI安全开发生命周期全流程:五阶段安全门禁流水线(数据采集→训练→评估→部署→监控)、四类门禁检查项与通过率统计、运行时三维监控与安全事件响应链路,三模式切换理解Sec-AI-DevOps端到端安全防护。

本节配有交互动效(进入视口后自动加载,约 3KB)。

Sec-AI-DevOps五阶段流水线 数据采集→训练→评估→部署→监控 每阶段安全门禁自动检查 data -> train -> eval -> deploy -> monitor 将安全实践融入AI应用完整生命周期,每阶段设安全门禁实现自动化防护。

概念与价值:把安全从“收尾工序”变成“钢筋结构”

回到智能大厦的比喻。传统开发模式里,安全团队像是一支只在竣工验收前夜出现的保安队:他们拿着手电筒到处照,发现一百个漏洞,但大厦已封顶,改任何一根管道都要砸墙。而 Sec-AI-DevOps 的核心理念只有四个字——安全左移(Security Shift Left)。它要求安全活动从最左侧的需求阶段就开始介入,像钢筋一样浇筑进每一层楼板。等大厦封顶时,安全不是要“补”的,而是本来就长在结构里的。

为什么必须左移?因为安全问题的修复成本随阶段呈指数级增长。需求阶段发现一个逻辑漏洞,改一页文档就行;编码阶段发现,要改代码;测试阶段发现,要重跑全部用例;上线后才发现,可能要紧急回滚、赔偿损失、修复声誉。DevOps 强调的持续集成、持续交付,恰好为“安全左移”提供了流水线——每一次代码提交都触发自动安全扫描,安全检查和单元测试一样成为家常便饭。对 AI 应用而言,左移还多了一层含义:不仅要扫描传统代码漏洞,还要审视训练数据、模型权重、推理接口这些 AI 特有的攻击面。

在真实项目中,这个公式表现为:上线后修复一个高危漏洞的平均成本,是需求阶段的 30 到 100 倍。这也是为什么顶尖 AI 公司会把安全评审嵌入每一个迭代的“完成定义”(Definition of Done)里——安全不是可选项,而是和功能一样必须交付的构件。

修复成本=基线成本×ek×阶段\text{修复成本} = \text{基线成本} \times e^{k \times \text{阶段}}
阶段越靠后,修复成本呈指数上升。这就是“安全左移”经济学上的根本动因——把问题消灭在便宜的时候。
  1. 修复成本指从发现安全缺陷到彻底解决所需的人力、时间和资金总和。
    修复成本\text{修复成本}
  2. 基线成本指在需求阶段就修复同一个问题所需的最低代价,把它设为 1。
    基线成本\text{基线成本}
  3. 指数系数k 是一个大于 0 的经验常数,表示阶段越晚修复代价增长越快,通常取 0.5~1.0。
    ek×阶段e^{k \times \text{阶段}}
  4. 阶段用 0 到 5 代表需求、设计、编码、测试、部署、运维六个阶段,阶段数字越大,成本越高。
    0≤阶段≤50 \le \text{阶段} \le 5

需求与建模:先画清“谁可能从哪扇窗翻进来”

盖楼前,建筑师要做地质勘探和风洞实验;做 AI 应用前,安全团队要做的是威胁建模(Threat Modeling)。简单说,就是坐下来问四个问题:我们在建什么?什么东西最值钱(模型权重、用户数据、API 密钥)?谁可能来偷(外部黑客、恶意用户、甚至内部人员)?他们有哪些路可以走(提示注入、数据投毒、模型窃取、拒绝服务)?

这一步产出的是攻击面清单和信任边界图。攻击面是指所有能被攻击者触碰的入口:用户输入框、API 端点、文件上传、模型推理日志,甚至第三方依赖的下载源。信任边界则把系统划成不同的“安全区域”:公网区、内网区、数据区、模型区。跨越边界的数据流必须经过身份验证和权限检查,就像大厦里不同楼层之间需要刷卡过闸。

一个实用的攻击面估算公式,能帮你量化“暴露了多少风险”:

做完威胁建模,你会得到一份结构化的安全需求清单:哪些接口需要限流?哪些 prompt 需要过滤?模型服务是否要单独隔离?这份清单直接成为开发的“安全验收标准”——只有满足清单上的每一项,产品才算真正完成。这就好比大厦的消防验收图必须在动工前画好,而不是等装修完再凿墙装喷淋。

攻击面=输入点×攻击路径×信任边界\text{攻击面} = \text{输入点} \times \text{攻击路径} \times \text{信任边界}
攻击面不是一个点,而是输入、路径、边界三者的乘积。任一个维度膨胀,整体风险都会放大。
  1. 输入点所有接收外部数据的位置,比如用户文本框、API 参数、上传文件、模型 Prompt。
    输入点\text{输入点}
  2. 攻击路径从输入点到达敏感资源(数据库、模型权重)所经过的代码链路。
    攻击路径\text{攻击路径}
  3. 信任边界系统内不同信任等级的区域之间的分界线,每跨一条边界都需要新的认证。
    信任边界\text{信任边界}

设计与编码:每一块砖都砌进“防撬结构”

有了安全需求,接下来要在设计图和代码里落地。大厦设计时会在关键位置设置防火门、承重墙和逃生通道,对应到软件设计就是三个原则:最小权限(每个模块只拿它干活必需的那点权限)、纵深防御(不依赖单道防线,而是多层校验叠加)、默认拒绝(没明确允许的一律禁止)。AI 应用还要额外加一道“模型防线”:对推理接口做输入输出的内容过滤,防止用户通过精心构造的 prompt 越狱。

编码阶段是漏洞的高发地带,尤其是 AI 应用往往用 Python 快速迭代,更容易踩中 eval、pickle.loads、shell=True 这类危险函数。业界最常用的是静态应用安全测试(SAST),它像安检仪一样扫描源代码,不运行程序就能找出危险调用、硬编码密钥、SQL 注入拼串。安全编码的黄金法则是“永远不要信任外部输入”,所有数据进来先校验、再净化、后使用:

把安全函数嵌套在输入处理的最外层,就像在大厦入口设置“安检门 + 闸机 + 保安”三重验证。SAST 工具在 CI 流水线里自动跑,任何一重检查失败,代码就无法合入主干——安全开始真正“左移”进了开发者的日常。

安全处理=校验(净化(外部输入))\text{安全处理} = \text{校验}(\text{净化}(\text{外部输入}))
外部输入先用“白名单正则”校验格式,再用编码转义净化内容,最后才进入数据库查询或模型推理——三步缺一不可。
  1. 外部输入来自用户、上游服务或数据集的任何不可信内容。
    外部输入\text{外部输入}
  2. 净化移除或转义其中的危险字符,如 SQL 注入的引号、提示注入的越狱指令。
    净化\text{净化}
  3. 校验用白名单确认输入符合预期格式(如邮箱、整数、枚举值),不合规直接拒绝。
    校验\text{校验}

测试与门禁:竣工前的“全系统打压试验”

再好的设计也可能在施工中走样,所以测试阶段要上双引擎:SAST 负责“静态看图纸找毛病”,DAST(动态应用安全测试)则像打压试验一样对运行中的应用发起真实攻击流量。与此同时,依赖扫描会检查第三方库是否有已知 CVE 漏洞——在 AI 领域还要专门扫描模型文件和数据集的来源是否可信。

当所有测试跑完,发布前最后一道关卡是安全质量门禁(Security Gate)。门禁是一组硬性指标:高危漏洞数必须为 0、SAST 扫描通过率 ≥ 98%、依赖漏洞无未修复项。任何一项不达标,版本就被一票否决,不能进入生产环境。这就像大厦竣工必须通过消防验收,否则拿不到使用许可证:

落地时,门禁通常写成流水线里的一个“守门人”脚本:拉取扫描报告 → 解析漏洞等级 → 高危出现即 return 1 → 流水线变红 → 开发者的合并请求被自动拒绝。这套机制把“人盯人”的安全评审,变成了机器自动执行的刚性约束。

门禁通过率=通过检查项总检查项×100%\text{门禁通过率} = \frac{\text{通过检查项}}{\text{总检查项}} \times 100\%
门禁不是“尽量多通过几项”,而是高危项一票否决、全部项达到阈值才放行。
  1. 通过检查项在当前构建中通过安全测试的检查条目数量。
    通过检查项\text{通过检查项}
  2. 总检查项本次门禁配置的全部安全规则条目总数。
    总检查项\text{总检查项}
  3. 100%将比值换算成百分数,便于与阈值(如 98%)直接比较。
    ×100%\times 100\%

部署与运维:交付不是终点,而是安全的新起点

大厦交付后,物业团队开始接管。在 Sec-AI-DevOps 里,这一阶段叫安全运维。首先是基础设施即代码(IaC):服务器的防火墙规则、网络策略、IAM 权限全部用代码声明,并纳入版本管理——这样每一份基础设施配置都能被审查和追溯,杜绝“某人在生产环境手动开了一个端口”这类安全隐患。

然后是镜像签名:AI 模型服务通常打包成容器镜像,签名机制确保只有经过安全审核的镜像才能被拉取部署,防止供应链投毒。运行时防护(RASP)则像大厦里的智能烟感,实时监控应用行为,发现异常流量或异常模型输出立刻告警甚至自动阻断。

安全事件的处置效率是运维阶段的核心指标,用平均修复时间(MTTR)来衡量:

AI 应用的运维还有一个独特场景:模型在线上会持续接收到真实用户输入,其中可能包含对抗样本。因此运维团队要定期用“影子数据集”回放攻击流量,评估模型鲁棒性是否随着线上数据漂移而退化。一旦发现模型被针对性地“带偏”,就触发告警并回滚到上一版本——这正是从“防漏洞”升级到了“防对抗”。

MTTR=总修复时间安全事件次数\text{MTTR} = \frac{\text{总修复时间}}{\text{安全事件次数}}
每次安全事件从发现到恢复的平均耗时。持续监控、自动化响应和复盘改进,都在压缩这个分母和分子。
  1. 总修复时间一段时间内所有安全事件从发现到彻底修复所用的时间总和。
    总修复时间\text{总修复时间}
  2. 安全事件次数同一时间段内发生的安全事件总数,如入侵尝试、数据泄露、异常调用。
    安全事件次数\text{安全事件次数}

红蓝与AI专项:用“攻防演习”检验整栋大厦

最后但最精彩的一环,是红蓝对抗。红队扮演攻击者,用尽一切手段尝试入侵;蓝队负责防守和响应。在 AI 应用场景里,红队的目标格外丰富:对聊天机器人发起提示注入,套取系统提示词;对图像识别模型投递对抗贴纸,让“停止”标志被识别成“限速”;通过 API 返回的置信度分数,逆向窃取模型内部的训练数据。蓝队则要借助全生命周期的安全设施来发现并阻断这些攻击。

红蓝对抗平台建设是 Sec-AI-DevOps 的高级形态:它把攻击剧本、漏洞靶场、监测指标和复盘报告沉淀成平台能力,让攻防演练可以常态化、自动化地运行。每次对抗结束,红蓝双方共同产出漏洞清单和防御改进项,再反馈到最左侧的需求和设计阶段——至此,整个生命周期闭合成为一个不断进化的螺旋:

红蓝对抗最大的价值不是“赢”,而是“暴露”。它把隐藏在代码深处的假设性风险,变成肉眼可见的攻防数据,让安全投入有的放矢。就像消防演习真正着火时,大家才知道逃生通道到底通不通——与其等黑客来当“免费演习”,不如自己先红蓝一把。

检测率=蓝队成功拦截的攻击红队发起的有效攻击×100%\text{检测率} = \frac{\text{蓝队成功拦截的攻击}}{\text{红队发起的有效攻击}} \times 100\%
检测率不是越高越好,而是要配合误报率一起看。红蓝对抗的价值,就是在真实攻防中不断校准这两个指标。
  1. 蓝队成功拦截的攻击被 WAF、RASP、模型防火墙等防御设施有效阻断的攻击次数。
    蓝队成功拦截的攻击\text{蓝队成功拦截的攻击}
  2. 红队发起的有效攻击红队真正命中系统弱点的攻击次数,排除无效探测。
    红队发起的有效攻击\text{红队发起的有效攻击}
  3. 100%转换为百分比,用于和行业基准对比。
    ×100%\times 100\%

AI 应用场景

场景一:大模型客服系统的上线安全评审

阶段:需求分析与威胁建模

解决的问题:某金融公司要上线 AI 客服,传统做法是等开发完再渗透测试,结果上线前发现模型可被提示注入诱导泄露用户订单信息,被迫推迟两周。用 Sec-AI-DevOps 后,在需求阶段就做了威胁建模,识别出“prompt 越狱 + 接口未限流 + 日志含敏感信息”三大风险。

具体案例:安全团队在需求文档中直接写明“系统提示词必须加密存储”“推理接口必须做敏感词双向过滤”“日志脱敏后才可持久化”。开发按清单实现,上线前门禁一次通过。

场景二:AI 红蓝对抗平台日常攻防演练

阶段:测试验证与安全运维

解决的问题:传统安全测试只能覆盖已知漏洞,无法应对对抗样本和复杂攻击链。红蓝对抗平台把攻击剧本自动化,让防御体系在持续攻击中暴露短板。

具体案例:某自动驾驶公司搭建红蓝对抗靶场,红队每周产出新对抗样本(贴纸攻击、3D 打印干扰物),蓝队用检测率和误报率两个指标评估模型鲁棒性,不达标模型不允许进入车队实测。

场景三:AI 代码仓库的供应链安全扫描

阶段:编码与依赖管理

解决的问题:AI 项目 80% 的代码来自开源依赖,传统开发对依赖漏洞几乎无感知。通过把依赖扫描和 SAST 嵌入 CI 流水线,从源头阻断已知漏洞流入生产。

具体案例:某 AIGC 创业公司在流水线中加入依赖漏洞扫描,自动发现 transformers 库某个版本的序列化反序列化漏洞,拦截了一次可能导致远程代码执行的合并请求。

Python 演示

python103 行
# -*- coding: utf-8 -*-"""Mini SAST scanner: 模拟安全开发生命周期中的静态代码扫描阶段。"""import astimport sys  class SecurityScanner(ast.NodeVisitor):    """遍历 Python AST,查找危险调用与不安全模式。"""     def __init__(self):        self.vuln_list = []        self._count = 0     def _record(self, node, risk, msg):        self._count += 1        self.vuln_list.append({            "id": self._count,            "line": getattr(node, "lineno", 0),            "risk": risk,            "message": msg,        })     def visit_Call(self, node):        func = node.func        if isinstance(func, ast.Name):            if func.id == "eval":                self._record(node, "HIGH", "使用 eval 执行动态代码")            elif func.id == "exec":                self._record(node, "HIGH", "使用 exec 执行动态代码")            elif func.id == "input":                self._record(node, "MEDIUM", "input 直接接收不可信输入")        elif isinstance(func, ast.Attribute):            attr = func.attr            if attr == "loads" and isinstance(func.value, ast.Name) \                    and func.value.id == "pickle":                self._record(node, "HIGH", "pickle.loads 存在反序列化风险")            elif attr == "run" and isinstance(func.value, ast.Name) \                    and func.value.id == "subprocess":                for kw in node.keywords:                    if kw.arg == "shell" and isinstance(kw.value, ast.Constant) \                            and kw.value.value is True:                        self._record(node, "HIGH", "subprocess 开启 shell=True")        self.generic_visit(node)     def visit_Assign(self, node):        for target in node.targets:            if isinstance(target, ast.Name) and "key" in target.id.lower() \                    and isinstance(node.value, ast.Constant):                self._record(node, "MEDIUM", "疑似硬编码密钥")        self.generic_visit(node)  def scan(source_code):    """解析源码并返回漏洞报告。"""    scanner = SecurityScanner()    try:        tree = ast.parse(source_code)    except SyntaxError as exc:        return [{"id": 1, "line": 0, "risk": "ERROR",                 "message": "源码语法错误: %s" % exc}]    scanner.visit(tree)    return scanner.vuln_list  def main():    sample = '''import osimport pickleimport subprocess def load_model(path):    # 危险: 反序列化不可信数据    return pickle.loads(open(path, "rb").read()) def run_cmd(cmd):    # 危险: 开启 shell    subprocess.run(cmd, shell=True) cmd = os.popen("ls")  # 危险: popen 调用api_key = "sk-1234567890abcdef"model_name = input("please input model name:")'''     if len(sys.argv) > 1:        with open(sys.argv[1], "r", encoding="utf-8") as fh:            source = fh.read()    else:        source = sample     report = scan(source)    print("=== Sec-AI-DevOps 静态扫描报告 ===")    if not report:        print("未发现安全风险")        return    for item in report:        print("第%4d行 [%s] %s" % (item["line"], item["risk"], item["message"]))    high = sum(1 for r in report if r["risk"] == "HIGH")    print("高危漏洞: %d 个, 不满足安全门禁 (要求: 0)" % high)    sys.exit(1 if high > 0 else 0)  if __name__ == "__main__":    main()
目的:实现了一个极简 SAST 扫描器,模拟安全左移中“代码提交即扫描”的自动化门禁,找出 eval、pickle.loads、shell=True 等典型高危模式。
  1. class SecurityScanner(ast.NodeVisitor)继承了 Python AST 访问器,像安检遍历每个语法节点。
  2. visit_Call每次遇到函数调用就检查其名称和参数,判断是否命中危险模式。
  3. subprocess.run(cmd, shell=True)攻击者可拼接命令实现远程执行,必须一票否决。
  4. visit_Assign扫描疑似硬编码的 API 密钥,AI 服务尤其容易把密钥写死在训练脚本里。
  5. sys.exit(1 if high > 0 else 0)门禁逻辑:高危漏洞为 0 才允许流水线继续。

常见误区

误区很多团队觉得安全就是上线前找黑客朋友测一测,测完没问题就万事大吉。反正 AI 模型“自己会学习”,漏洞应该比传统软件少。

正解AI 应用的安全问题大多源于需求设计阶段:训练数据被投毒、prompt 越狱、模型权重被窃取,这些根本不是上线前测一测能发现的。Sec-AI-DevOps 的「安全左移」理念强调,越早发现修复成本越低,阶段越靠后代价指数级上升。安全必须像钢筋一样浇筑进每个阶段,而不是最后刷一遍漆。

为何常见:传统软件测试的思维惯性让人误以为安全 = 渗透测试,而忽略了 AI 特有的数据面、模型面攻击在更早的阶段就已埋下。

误区CI 流水线里接了 SAST 工具,扫描报告全是绿的,就以为应用固若金汤、可以放心上线。

正解SAST 只是静态检查,它看不到运行时的逻辑漏洞、越权访问、业务风控缺失,更检测不了对抗样本和提示注入这类 AI 特有的攻击。Sec-AI-DevOps 要求 SAST + DAST + 依赖扫描 + 人工渗透 + 威胁建模协同作战,任何单一工具都只是防线的一小块拼图。

为何常见:工具输出的“0 漏洞”给人确定的错觉,而安全本质是概率游戏,需要用红蓝对抗不断逼近真实风险。

误区认为一年组织一次红蓝对抗演练,让大家打一打、拍拍照、发个报告就算完成安全任务。或者觉得红队没打进来就代表系统很安全。

正解红蓝对抗的核心价值是持续暴露防御短板,并形成「发现 → 修复 → 复测 → 沉淀」的闭环。真正的 Sec-AI-DevOps 会把对抗平台化,让攻击剧本、样本库、检测指标沉淀为组织的长期安全资产。红队没打进来有时只是因为攻击面没覆盖全,不能证明系统绝对安全。

为何常见:把一次性的安全活动误当成持续的安全能力建设,忽略了生命周期需要不断反馈迭代的本质。

面试题

Q1. “安全左移”(Shift Left)的核心含义是?

单选题 · easy

  • A.把安全测试放到上线之后进行
  • B.让安全活动从需求阶段提前介入← 正确答案
  • C.用更多安全人员替代开发人员
  • D.把系统部署到更左侧的数据中心

答案:B。安全左移指把安全活动从传统“上线前测试”前置到需求、设计、编码阶段,像浇筑钢筋一样把安全融入每个环节,从而降低修复成本。A 是“右移”,C、D 与环境无关。

Q2. 威胁建模的首要产出是什么?

单选题 · easy

  • A.最终的渗透测试报告
  • B.攻击面清单与信任边界图← 正确答案
  • C.生产环境防火墙规则
  • D.模型训练数据的增强策略

答案:B。威胁建模在需求阶段回答“谁可能攻击、从哪条路攻击、哪些资产最值钱”,输出攻击面清单、信任边界图和对应的安全需求清单。渗透测试报告、防火墙规则是后续阶段产物。

Q3. 下列关于修复成本的说法,正确的是?

单选题 · mid

  • A.上线后修复漏洞比需求阶段更便宜
  • B.修复成本随阶段后移呈指数上升← 正确答案
  • C.修复成本与发现阶段完全无关
  • D.测试阶段修复成本最低

答案:B。修复成本 = 基线成本 × e^(k×阶段),阶段越靠后成本越高。因此需求阶段修复最便宜,上线后修复最贵,这是“安全左移”的根本经济动因。

Q4. 在 AI 应用安全中,“信任边界”指的是?

单选题 · mid

  • A.模型训练时使用的数据增强范围
  • B.不同信任等级区域之间的分界← 正确答案
  • C.用户输入内容的长度限制
  • D.模型推理的置信度分数阈值

答案:B。信任边界把系统划分为公网区、内网区、数据区、模型区等不同信任等级的区域,跨边界的数据流必须通过身份认证和权限检查,与输入长度、置信度阈值无关。

Q5. 某 AI 应用安全门禁配置为“高危漏洞数必须为 0、SAST 通过率 ≥ 98%”,现扫描出 2 个高危漏洞、SAST 通过率 99%,则门禁结果如何?

单选题 · hard

  • A.通过,因为 SAST 通过率达标
  • B.不通过,高新漏洞数不为 0← 正确答案
  • C.需要人工复核后决定
  • D.只要测试通过率达标即可放行

答案:B。安全门禁的典型规则是“高危漏洞一票否决”——即使其他指标全绿,只要存在高危漏洞,构建就被拒绝。这是为了阻止带病上线,确保生产环境只接收已知安全状态的应用。

Q6. 下列哪些属于 AI 应用特有的攻击面?

多选题 · mid

  • A.提示注入越狱← 正确答案
  • B.训练数据投毒← 正确答案
  • C.模型权重窃取← 正确答案
  • D.SQL 注入

答案:ABC。提示注入、数据投毒、模型窃取都是 AI 应用引入的新攻击面。SQL 注入属于传统 Web 安全范畴,不是 AI 特有。Sec-AI-DevOps 要求同时覆盖传统代码漏洞和 AI 特有威胁。

Q7. “纵深防御”原则指的是?

单选题 · easy

  • A.只依赖一道最强的安全防线
  • B.构建多层叠加的防御体系← 正确答案
  • C.把服务器埋入地下机房
  • D.加大密码的长度和复杂度

答案:B。纵深防御强调不依赖单一防线,而是网络层、应用层、数据层、模型层多层设防。即使某一层被攻破,后续防线仍可阻断攻击。它和最小权限、默认拒绝共同构成安全设计的基石。

Q8. 关于红蓝对抗在 Sec-AI-DevOps 中的作用,下列说法正确的有?

多选题 · hard

  • A.红队负责模拟攻击者发起攻击← 正确答案
  • B.蓝队负责监测、响应和修复防御← 正确答案
  • C.红蓝对抗报告应反馈到需求设计阶段← 正确答案
  • D.红蓝对抗可以完全替代 SAST 扫描

答案:ABC。红蓝对抗以真实攻防检验防线,其产出的漏洞清单应反馈到生命周期最左侧形成闭环。但它不能替代 SAST、DAST 等自动化测试——对抗是“抽样验证”,扫描才是“全量检查”。

Q9. 在 Python 安全扫描中,下列哪段代码属于高危模式?

单选题 · hard

  • A.value = request.get_json()
  • B.pickle.loads(file_bytes)← 正确答案
  • C.result = a + b
  • D.logger.info("done")

答案:B。pickle.loads 反序列化不可信数据可导致任意代码执行,是 SAST 工具必须拦截的高危调用。读取 JSON、普通加法运算、日志输出均不属于高危模式。

Q10. 下列哪些做法符合 Sec-AI-DevOps 的最佳实践?

多选题 · mid

  • A.在 CI 流水线中集成 SAST 扫描← 正确答案
  • B.对容器镜像进行签名验证← 正确答案
  • C.把安全门禁设为发布的前置条件← 正确答案
  • D.只在年终总结时做一次安全评审

答案:ABC。SAST 集成、镜像签名、安全门禁都体现了安全嵌入交付流水线的实践。只在年终做一次安全评审属于“安全右移”的过时做法,无法在早期控制风险。