SBOM-Based Container Deployment Risk Assessment under Incomplete Runtime Observations
本文提出了一种基于自适应 SBOM 的方法，通过整合多种证据源来分类漏洞适用性并优先考虑检查成本，从而在运行时观测不完整的情况下评估容器部署风险，与基准方法相比，实现了更高的决策完成率并降低了等待时间。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
在现代数字世界中，软件很少是从零开始构建的。相反，开发者就像一位大师级厨师利用预制食材组装复杂菜肴一样，通过组合库、框架和他人创建的工具来组装应用程序：为了追踪这些“食材”，一种被称为软件物料清单（SBOM）的新标准充当了详细的库存清单。这份清单对于安全性至关重要，因为如果发现某个食材存在已知缺陷，SBOM 可以帮助识别哪些应用程序包含了该缺陷。然而，仅仅知道某种食材的存在只是成功的一半。如果一个库中存在缺陷，只有当软件在运行时确实使用了那部分特定的代码时，该缺陷才会变成危险。如果代码处于休眠状态，从未被程序调用，那么该缺陷就是无害的。安全团队面临的挑战在于，他们无法始终完美地观察软件运行；有时监控工具会错过事件，或者测试场景无法覆盖软件可能被使用的所有路径。这留下了一个缺口，使得团队可能无法确定一个缺陷是危险的还是安全的，从而被迫在阻断必要的更新或承担被入侵的风险之间做出选择。
研究人员朴秉灿（Byeongchan Park）和金淳集（Sun-Jip Kim）通过创建一种决定是否部署软件容器（一种包含应用程序及其所有成分的自包含软件包）的新方法，解决了这种不确定性。他们的方法将信息的缺乏视为不是猜测的理由，而是暂停并收集更具体证据的理由。他们构建了一个结合了库存清单、静态分析（即检查代码结构）以及运行时观察（即观察软件在实际运行中的表现）的系统。至关重要的是，该系统认识到，仅仅因为在测试期间没有看到某个危险函数，并不意味着该函数可以被安全忽略。该系统并没有在证据不足时强行给出“是”或“否”的答案，而是将风险分类为：确认危险、在特定范围内确认安全，或未解决。当风险处于“未解决”状态时，系统不会简单地批准部署，而是将请求置于挂起状态。
他们创新的核心在于一种策略，即如何投入有限的时间和计算能力来解决这些不确定性。想象一下，一个拥有严格更新截止日期的安全团队。他们有一份潜在缺陷清单，但彻底检查每一个缺陷需要耗费太长时间。研究人员的方法就像一个智能向导，根据各项检查对得出最终结论的贡献程度，来决定优先执行哪些检查。它优先考虑那些最有可能将“未解决”的风险转化为明确的“安全”或“危险”定论的操作，而不是仅仅按照随机顺序或仅按严重程度进行检查。该系统会随着新数据的进入不断重新评估其选择，确保每一秒的检查预算都花在对最终决策最重要的检查上。
为了测试这种方法，研究人员使用源自 40 个 Java 项目特定漏洞案例的一百个不同软件部署场景构建了一个真实的模拟环境。他们为其中 90 个案例创建了“地面真值”（ground truth），这意味着独立于他们的新系统，他们确切地知道哪些部署是安全的，哪些是危险的。随后，他们让该系统承受各种形式的不完全信息，例如缺失的测试负载、缩短的观察窗口以及丢失的数据事件。他们将这种自适应方法与几种其他策略进行了比较，包括简单的基于列表的检查，以及一种基于解决成本进行检查优先级的方案。结果显示，该方法在规定时间内达到正确最终决策的能力更为出色。在 120 秒的预算内，新方法实现了 78.4% 的平衡正确决策率，而排名第二的方法为 76.3%。
或许更重要的一点是，新方法减少了处于未解决“挂起”状态的案例数量。虽然其他方法会让 22% 的决策处于未决状态，但所提议的方法将其降低到了 20%。这意味着更多的软件更新可以在不造成不必要延迟的情况下安全进行，同时仍保持极低的错误率。该系统错误批准危险部署的概率仅为 1.2%，而错误拦截安全部署的概率仅为 2%。这些数字表明，通过仔细安排检查顺序，并在证据不足时拒绝做出决策，安全团队可以更有效地应对不完全数据的迷雾。这项研究证实，一种结构化的、基于证据的方法可以区分出真正无害的缺陷与仅仅是未被观察到的缺陷，从而允许组织即使在无法洞察软件行为的所有细节时，也能充满信心地推进工作。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。