--submit失败因需连接kubescape后端做合规比对，网络策略、代理或dns问题会导致超时；离线时须显式设--submit=false，nsa与mitre框架严重等级语义不同不可跨框架比较。
为什么 --submit 会失败，但本地扫描却正常？
因为 --submit 不是单纯上传结果，它会尝试连接 Kubescape 的后端服务（默认 https://kubescape.io）做合规比对和报告生成。一旦网络策略拦截、代理未配置、或集群内 DNS 解析失败，就会卡在 Failed to submit results 或直接超时。
常见错误现象：Post "https://kubescape.io/api/v1/submit": dial tcp: lookup kubescape.io on [::1]:53: read udp [::1]:50724->[::1]:53: read: connection refused
- 确认是否在离线环境运行 —— 离线时必须显式禁用提交：
--submit=false，否则默认开启且必败 - 检查
KUBESCAPE_API_URL环境变量是否被误设为不可达地址（比如指向内部 mock 服务但没跑起来） - 若走代理，需同时设置
HTTPS_PROXY和NO_PROXY（尤其要包含.io域名，否则可能被跳过）
NSA 和 MITRE 框架报告里，同一规则为啥显示不同严重等级？
NSA 和 MITRE ATT&CK 是两套独立的映射逻辑：NSA 报告聚焦 Kubernetes 最佳实践（如 Pod 安全策略、Secret 管理），MITRE 则把扫描项映射到攻击生命周期阶段（如 T1068 权限提升）。它们不共享评分模型，也不强制对齐严重性字段。
典型表现：CIS-1.2.1 在 NSA 报告中标为 high，但在 MITRE 报告中对应规则可能只标 medium，因为后者更看重该控制点是否直接支撑某类战术达成。
- 不要跨框架比较
severity字段值 —— 它们语义不同，NSA.severity是风险影响分，MITRE.severity是战术覆盖权重 - 真正该关注的是
controls数组里的controlID和frameworkName，这才是定位依据 - 导出 JSON 后，MITRE 结果藏在
results.frameworks[?(@.name=='MITRE')]路径下，不是顶层severity
怎么让 kubescape scan --framework 只输出 NSA 或只输出 MITRE？
--framework 参数本身不支持单选过滤，它只是指定扫描依据（即按哪套控制项跑检查），但报告默认仍会合并输出所有启用的框架结果。想隔离视图，得靠后续解析或提前关掉另一个框架。
- 禁用 MITRE 输出（只留 NSA）：
kubescape scan --framework=nsa --submit=false --format=json | jq '.results.frameworks[] | select(.name=="NSA")' - 禁用 NSA 输出（只留 MITRE）：
KUBESCAPE_FRAMEWORKS=mitre kubescape scan --framework=mitre --submit=false—— 注意这里必须用环境变量KUBESCAPE_FRAMEWORKS控制加载，仅靠--framework不生效 - 参数
--framework=nsa和--framework=mitre实际上都会触发两套规则执行，区别只在「默认展示哪些框架的结果」
本地解析 JSON 报告时，failedControls 和 excludedControls 容易混淆
failedControls 是真实触发失败的规则项；excludedControls 是因配置排除（如 --exclude-controls）、权限不足（如没 RBAC 读取某些资源）或框架不匹配而跳过的规则 —— 它们根本没被执行，也不计入评分。
一个典型坑：excludedControls 里出现大量 CIS-5.1.5，你以为是漏扫，其实是当前账号没权限 list networkpolicies，Kubescape 自动跳过而非报错。
- 检查
excludedControls的reason字段，常见值有missing-permissions、unsupported-k8s-version、excluded-by-user -
failedControls的status字段才是判断是否真失败的关键，值为failed才需修复；excludedControls的status恒为excluded - 如果想强制执行所有控制项（哪怕缺权限），加
--fail-on-score 并配合 <code>--verbose查看跳过原因
框架映射不是静态查表，而是运行时动态关联 —— 同一 CIS 规则在不同 Kubescape 版本中可能归属不同 MITRE tactic，别硬背 ID 对应关系。每次升级后建议重跑一次 baseline 并 diff frameworks 字段变化。
