本文针对星载（onboard）卫星飞行系统中日益广泛使用的开源软件（OSS）开展了一次实证性安全分析。研究背景在于：现代卫星任务为加速研发，大量采用可复用框架、共享库与社区维护组件，但这些组件被引入到补丁更新代价极高、失效可能直接影响任务运行的航天环境中，从而把常规软件供应链风险带入了高可靠性领域。作者收集了 126 个公开卫星相关代码仓库，构建并执行了一条多工具组合的自动化分析流水线，涵盖四个环节：(1) 生成软件物料清单（SBOM）以识别组件构成；(2) 软件成分分析（SCA）以匹配已知漏洞与依赖风险；(3) 静态应用安全测试（SAST）扫描自研源码；(4) 基础设施即代码（IaC）配置审查与密钥/凭据扫描。为控制噪声，作者又施加了基于规则的清洗、面向星载范围的过滤以及基于指纹的去重，最终得到包含 2,827 条安全发现的数据集。结果表明：安全发现分布广泛但高度不均衡；中等严重度占 49%，中等及以上合计占 72%。作者采用基于 CWE 的分类体系，把全部发现归入八个弱点族，其中内存安全与代码质量类占比最高，其次是输入验证与注入类。从代码归属看，81.4% 的发现位于项目自研代码中，外部依赖代码仍是不可忽视的来源。作者明确强调，这些发现并不证明针对具体任务的真实可利用性，其价值在于对开源星载软件生态中反复出现的安全模式给出实证刻画，量化其普遍程度，并帮助任务方确定最应优先投入安全审查的领域。该工作适合航天软件工程、供应链安全与嵌入式安全方向的读者参考。

该论文聚焦软件供应链（SSC）安全中的透明度问题，指出现代软件实践依赖的 SBOM（软件物料清单）及其工具虽然被引入作为确保供应链透明度的基础组件，但存在严重局限性：其漏洞检测与解释能力不足以说明可沿整条供应链传播的漏洞可利用性效应。为了弥补这一空白，作者提出一种以“传播”为中心的 SSC 安全研究方法，并引入一个四阶段传播模型：阶段1为结构性暴露（Structural Exposure），阶段2为漏洞类别存在性（Vulnerability Class Presence），阶段3为代码可达性（Code Reachability），阶段4为污点路径分析（Taint Path Analysis）。研究选取 Log4j 漏洞作为测试用例，使用三个开源项目对四款开源 SBOM 工具开展实证评估。结果表明，当前 SBOM 工具仅系统性地支持阶段1和阶段2，而阶段3和阶段4所要求的代码级分析与数据流追踪能力在现有 SBOM 生态中完全缺失。作者因此主张，只有将传播效应置于 SSC 安全研究的中心，才能阻止网络风险演化为系统性风险，并为未来现代 SSC 安全工具的研究与设计提供方向。本文适合软件供应链安全研究者、安全工具开发者以及负责供应链风险评估的蓝队工程师阅读。

该论文对来自 Wild SBOMs 数据集的 78,612 个真实世界的软件物料清单（SBOM）文件进行了大规模实证研究，首次刻画了其中声明的依赖图结构。研究发现，这些 SBOM 可分为三类：52.9% 的 SBOM 未声明任何边（不符合 NTIA 最低元素要求）；8.8% 虽然声明了依赖块但大多数组件孤立（退化状态，对于组件数≥50 的此类 SBOM，中位孤儿比例为 93%，且作者生成的 11 个 Syft 容器镜像 SBOM 孤儿比例达 95%-98%）；38.3% 形成了良好连接的图。边的生成完全由生成工具决定，而非被描述的软件（不同工具的零边率从 0% 到 100%）。用于声明图不完整性的规范级机制（CycloneDX compositions）仅被 0.10% 的 SBOM 使用。作者指出，在前两类状态下，常见的消费者推断“无路径即不可达”是一种不合理的封闭世界结论。在生产级漏洞优先级排序系统中，用退化检测器保护下的显式“未知”级别替换原有的否决逻辑，可将 KEV 召回率从 0.600 提升至 0.950（控制重评分），在端到端运行时达到 0.957，且不会造成警报泛滥。论文发布了流式扫描器和完整的每个 SBOM 拓扑数据集。

该研究论文探讨了软件物料清单（SBOM）在增强软件供应链安全方面的潜力。研究背景指出，软件供应链攻击日益频繁，如SolarWinds事件，凸显了透明度和可追溯性的缺失。核心问题是如何利用SBOM来识别和缓解供应链中的漏洞和风险。研究方法包括对现有SBOM标准（如SPDX和CycloneDX）的分析，以及案例研究评估SBOM在漏洞响应、许可证合规性和依赖关系追踪中的实际效果。主要贡献是提出了一个框架，将SBOM集成到DevOps流程中，实现自动化的安全审计和风险评估。实验证明，该方法能显著缩短漏洞发现到修复的时间，并提高供应链整体的可见性。适合安全架构师、DevOps工程师和合规管理人员阅读。

现代软件开发高度依赖来自公共仓库的第三方组件，这扩大了软件供应链攻击面。为了应对这一风险，美国联邦倡议推动了软件物料清单（SBOM）作为标准化机制，通过描述软件组件、依赖关系及其关联来提升透明度。然而，基于元数据或文件系统工件构建的SBOM无法捕获运行时加载和执行的组件，尤其是在Python等动态生态系统中。此外，通过插桩生成运行时SBOM需要提前部署监控并保持系统可观测，这在生产环境和事件响应场景中难以满足。相比之下，易失性内存为恢复运行中应用程序的实际运行时状态提供了可靠来源，无需事先插桩。本文提出了MEM-SBOM，首个直接从Python应用程序运行时状态生成SBOM的内存取证框架。它从解释器内部结构恢复模块、解析包版本、分析字节码以构建依赖图并识别易受攻击的函数。我们将MEM-SBOM实现为一套Volatility 3插件，并针对51个真实世界Python应用进行了评估。结果显示，它实现了100%的提取准确率，识别出Streamlit是唯一调用tornado依赖中易受攻击例程的应用，并恢复了现有SBOM工具遗漏的所有运行时包，提供了更准确的依赖图和更好的漏洞评估。这些能力使MEM-SBOM成为软件供应链安全和事件响应的实用基础，通过对系统上实际执行的内容提供取证可靠的运行时视图。