文章来源于盛邦安全太湖实验室，作者太湖实验室

卫星互联网设备正在变成"联网计算设备"——只要有代码，就存在安全审计的问题。

前言

用户终端、船载终端、航空终端、地面网关、PoP 节点、远程运维平台、OTA 升级系统，共同组成了一个高度软件化、网络化、云端化的复杂体系。

在这个体系中，安全风险不再只来自链路干扰、信号欺骗或物理破坏。设备固件、Web 管理后台、API 接口、认证逻辑、升级流程、配置文件、证书密钥管理、路由控制组件——这些才是问题的多发地带。

卫星互联网设备正在变成一种"联网计算设备"。只要它是计算设备，就存在代码安全审计的问题。

为什么代码审计越来越重要

传统上，卫星通信安全更多关注频谱、链路、加密体制和地面站安全。但随着星座规模扩大、终端数量增加、业务场景向海事、航空、应急、车载和偏远地区扩展，设备侧软件安全的重要性在上升。

一个卫星互联网终端并不是单纯的天线设备。它通常包含：

• • 嵌入式 Linux 系统

• • 路由组件

• • Web 管理服务

• • 远程运维 Agent

• • 升级程序

• • 诊断工具

• • 日志采集模块

• • 证书管理模块

• • 网络策略执行模块

任何一个模块出现安全缺陷，都可能影响终端控制、网络接入、配置下发或业务连续性。

卫星互联网设备往往分布广、环境复杂、远程维护依赖强。一旦某类设备出现通用漏洞，影响范围可能跨越国家、海域、航线和行业用户。设备代码审计因此不只是研发安全问题，也是网络空间测绘、供应链安全、基础设施防护和运营安全的重要组成部分。

传统审计方法的困难

卫星互联网设备代码审计的难点，首先来自设备类型和软件栈复杂。家庭终端、船载终端、航空终端、车载终端、便携终端、网关站设备、边缘接入节点和云端控制系统，使用的架构、语言和运行环境都不完全相同。

攻击面也分散。常见入口包括 Web 管理后台、调试接口、远程运维通道、OTA 升级接口、配置同步接口、日志上传接口、终端注册认证流程、API 网关、DNS/路由组件、证书与密钥管理模块。单靠某一种规则扫描工具，难以覆盖完整风险面。

还有一个问题：业务上下文强。终端入网、星地链路切换、网关选择、PoP 归属、策略下发、带宽控制、地理围栏、用户鉴权、远程锁定——这些问题不在单个函数里，而在跨模块流程里。传统 SAST 工具擅长发现危险函数和典型模式，但对复杂业务逻辑、权限边界和状态切换理解不足。

靠人工逐行审计，成本高、周期长；靠传统规则扫描，又容易漏掉规则之外的真实风险。这正是 AI 代码审计进入卫星互联网安全研究的背景。

AI 审计的误区

很多人对 AI 代码审计的理解，还停留在"把整个项目交给大模型，让它找漏洞"。这种方式看起来方便，实际效果不稳定。

原因很简单：大型代码库中，AI 面临的不是"是否懂漏洞"，而是"是否看到了关键代码"。

模型没有看到认证逻辑，就很难判断越权；没有看到文件包含点，就很难发现路径穿越；没有看到 OTA 校验流程，就很难判断升级包签名是否可靠；没有看到配置解析模块，就很难发现命令注入或危险参数传递。

AI 审计失败，往往不是因为模型不懂安全，而是审计流程没有把它带到正确位置。对于卫星互联网设备，这个问题更突出——高危逻辑可能隐藏在升级脚本、初始化脚本、配置转换脚本、日志上传模块、诊断工具或供应商遗留代码中。

AI 审计真正有效的方向，不是让模型自由发挥，而是把 AI 放进一条可控、可重复、可度量的安全审计流水线中。

从"聊天式审计"到"流水线式审计"

面向卫星互联网设备，AI 代码审计更合理的形态，是构建一个本地化、自动化的审计治理框架。它不依赖 AI 自己决定看哪些文件，而是由系统主动拆解代码、组织上下文、分发任务、收集结果，再由人工进行复核。

这套方法的关键不是模型单次回答有多精彩，而是让模型在正确的位置、处理正确的问题、输出标准化结果。审计对象可以按文件、模块、入口点、接口、权限边界、升级链路、证书链路、远程控制链路进行拆分。

这样做有三个优势：

1. 1. 覆盖率更高：系统强制遍历所有高风险文件，而不是让 Agent 自己选择

2. 2. 上下文更清晰：每次只审一个文件或一个模块，模型更容易理解输入来源、危险函数和权限校验

3. 3. 结果更便于复核：每个任务都输出统一格式，后续可以聚合、排序、去重和人工验证

六步审计框架

步骤一：固件解包与资产识别

第一步不是直接问 AI，而是先把设备代码资产整理清楚：

• • 固件解包

• • 文件系统提取

• • 二进制识别

• • 脚本文件识别

• • Web 目录识别

• • 配置文件识别

• • 证书密钥文件识别

• • 启动脚本分析

• • 服务进程列表整理

• • 开放端口与监听服务识别

这一阶段的目标是建立一张"代码资产地图"：

步骤二：攻击面分层建模

把代码资产按攻击面分层。卫星互联网设备至少可以分为六层：

步骤三：逐文件审计

对于大型设备代码库，直接整包审计效率低。更可行的方法是逐文件、逐模块审计。对每一个 PHP、Python、Lua、Shell、Go、C/C++ 文件，都可以让 AI 输出标准化审计结果：

{
  "file_function": "文件功能判断",
  "external_inputs": "外部输入来源",
  "dangerous_functions": "危险函数调用",
  "permission_checks": "权限校验点",
  "file_operations": "文件读写行为",
  "command_executions": "命令执行行为",
  "potential_vulnerabilities": "可能漏洞类型",
  "confidence": "置信度",
  "manual_review_needed": "需要人工复核的点"
}

这种方式的价值在于强覆盖。设备风险往往不在显眼的核心程序中，而在不起眼的诊断脚本、升级脚本、日志脚本、调试工具和供应商遗留模块中。逐文件审计能降低漏看关键文件的概率。

步骤四：按漏洞类型设计专项审计任务

通用 Prompt 只能发现表层问题。更有效的方法是围绕漏洞类型设计专项审计任务。

文件读取与路径穿越审计：检查用户输入是否进入文件路径拼接、配置读取、日志下载、诊断包导出和升级包读取流程。

命令注入审计：检查 Shell 脚本、系统命令调用、网络配置变更、ping/traceroute/nslookup 诊断功能以及 iptables、ip route 等命令拼接。

OTA 升级安全审计：检查升级包下载地址、签名校验、哈希校验、版本回滚、临时目录权限和升级脚本执行权限。

还可以针对认证与会话、证书与密钥、远程运维 Agent、IPv6 暴露面、日志诊断功能分别建立审计任务。这样 AI 不再泛泛地看代码，而是带着明确问题看代码。

步骤五：结构化输出与风险聚合

AI 审计结果不能只是一段自然语言总结。更好的方式是要求模型输出结构化报告：

{
  "vulnerability_type": "漏洞类型",
  "affected_module": "影响模块",
  "input_source": "输入来源",
  "propagation_path": "传播路径",
  "dangerous_operation": "危险操作",
  "exploitation_condition": "利用条件",
  "confidence": "置信度",
  "review_suggestion": "复核建议"
}

随后，系统可以对结果进行去重、排序、聚合和打分。同一类命令执行风险出现在多个脚本中，可以按调用链和入口点合并；硬编码密钥问题可以按文件路径和密钥类型归类；OTA 风险可以按下载、校验、解包、执行、回滚几个阶段分组。

结构化输出的价值在于，它把 AI 从"回答问题的助手"变成了"安全审计流水线中的一个处理节点"。

步骤六：人工复核与动态验证

AI 给出的结果应该被视为候选线索，而不是最终结论。最终判断仍然需要人工复核和动态验证。

复核时需要确认：代码是否真实可达？接口是否需要认证？权限条件是否成立？运行环境是否匹配？参数是否可控？影响是否可扩大？设备版本是否受影响？

必要时，还需要在合法授权环境中，通过仿真、测试设备、QEMU、容器化环境或真实实验环境进行验证。

工具负责覆盖，AI 负责理解，人工负责判断，实验负责验证。

本地 AI 的现实价值

卫星互联网设备固件、私有代码、配置文件、证书材料和测试样本通常具有较高敏感性，不适合直接上传到云端模型。本地 AI 模型因此具备现实价值。

本地 AI 不一定比云端最强模型更聪明，但有几个优势：

对于卫星互联网设备，版本差异尤其关键。漏洞往往不是突然出现的，而是在某个版本中引入，在后续版本中修复，或者从一个设备型号迁移到另一个型号。AI 审计流水线可以持续对比：哪些文件新增了远程管理逻辑？哪些接口新增了参数？哪些命令调用发生变化？哪些证书或密钥被替换？哪些防火墙规则被放宽？哪些 OTA 校验逻辑发生调整？

最值得关注的六类风险

OTA 升级链路

OTA 是设备安全的核心链路。升级包校验、签名验证、下载地址、回滚机制或升级脚本执行逻辑一旦存在问题，影响严重。AI 审计应优先关注升级包从下载、校验、解包到执行的完整流程。

远程运维通道

卫星互联网设备依赖远程维护。远程 Agent、云端指令、日志回传、配置下发、故障诊断和设备锁定，都可能成为高价值攻击面。审计重点放在指令来源校验、消息签名、重放保护、权限边界和异常指令处理。

Web 管理后台

设备仍然存在传统 Web 安全问题：认证绕过、命令注入、任意文件读取、默认口令、弱会话管理、接口未授权访问。AI 可用于快速梳理路由、参数、权限校验和危险函数调用。

证书与设备身份

设备身份是卫星互联网接入体系的基础。私钥硬编码、证书共用、密钥明文存储、Token 可预测、TLS 校验关闭，都可能影响终端认证和设备可信边界。

IPv6 与网络暴露面

卫星互联网广泛使用 IPv6。终端、路由器、管理接口、调试服务是否暴露在公网，是必须检查的问题。AI 可以辅助分析防火墙规则、监听服务、路由策略、前缀配置和远程访问逻辑。

日志与诊断功能

诊断功能经常被低估。ping、traceroute、nslookup、日志下载、抓包、系统状态导出等功能，如果参数处理不当，容易引入命令注入、路径穿越或信息泄露。

AI 会放大研究能力，但不会替代研究人员

AI 不应该被神化。它更适合做高覆盖初筛、上下文整理和风险归类，而不是直接给出最终漏洞结论。

它能帮助研究人员快速扫过大量代码，找出可疑点；把复杂代码解释成自然语言，帮助理解模块功能；把可疑代码按命令注入、路径穿越、弱认证、硬编码密钥、危险升级逻辑等类型分类。

但 AI 也有局限：不一定理解完整业务流程，不一定知道设备真实运行环境，不一定能判断接口是否真实可达，不一定能区分测试代码和生产代码，不一定能准确判断权限边界，容易产生误报。

正确姿势不是让 AI 给最终结论，而是让 AI 给候选线索。最终仍然要靠人工验证、动态测试、环境复现和安全影响分析。

结语

未来的卫星互联网安全，不会只靠人工经验，也不会只靠传统规则扫描。更现实的方向是：

本地 AI 模型 + 固件分析工具 + 静态规则扫描 + 调用链分析 + 动态验证环境 + 人工复核

AI 的作用不是取代安全研究人员，而是让安全研究人员从重复劳动中解放出来，把精力放在真正关键的地方：理解系统架构、判断业务影响、设计验证方法、分析攻击路径、评估安全后果、形成可修复的工程建议。

对卫星互联网设备来说，安全审计的难度只会越来越高。终端数量、设备型号、业务场景、软件版本都在增加，人工审计压力持续上升。在这种背景下，AI 代码审计不是一个可有可无的辅助工具，会逐步成为卫星互联网安全研究的基础能力。

真正决定效果的，不是单个模型有多强，而是审计流程是否足够工程化。

原文链接

[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。