不断增长的漏洞积压，加上对修复哪些漏洞以及何时修复缺乏明确性，可能导致一系列包括浪费开发人员的时间，延迟上市时间，以及由于修复时间长而增加企业攻击面等问题。当代行业和环境要求快速、频繁地推出功能性和安全代码的压力一直存在，而这也倒是需要开发人员确保和解决的任务和问题也越积越多，随之造成了漏洞积压。解决漏洞积压最有效的方式就是精准有效地确定需要解决漏洞的优先级顺序。 虽然解决方式非常明确，但说起来容易做起来难。因为确定漏洞的优先级顺序不仅需要投入时间，同时还需要相关安全专业知识来评估和确定每个漏洞构成的威胁级别。在本篇文章中，我们整理了企业可以参考和采用的四个步骤，来帮助企业消除漏洞积压的问题。
软件安全和软件供应链风险管理中的一个关键部分就是软件物料清单（SBOM），SBOM 是包含用于构建软件的各种组件的成分的嵌套清单。根据 Ponemon 的调查结果显示，有 41% 的受访者表示他们的企业使用 SBOM，这些企业有两大特点，即对风险评估和合规有明确要求。虽然有70%的人表示 SBOM 进行连续自动更新很重要或非常重要，但实际上只有47%的人表示他们的SBOM具有持续更新功能。这是因为想要持续更新 SBOM 就需要在静态 SBOM的基础上进行手动、单点时间点扫描来了解环境中的变化，而这给 CISO 以及安全团队造成巨大的负担。使用静态 SBOM 会让内容可见范围受到限制，并且这通常仅在软件堆栈的特定部分中可用，这也将导致延迟和不确定性，从而加剧安全风险。
与静态 SBOM 不同，动态 SBOM 提供对所有软件组件的实时可见性。动态 SBOM 更进一步揭示了这些组件是否在运行时执行以及如何在运行时执行，同时 DevSecOps 团队可以识别与企业 SBOM 中的软件组件关联的已知漏洞。这帮助企业有效且准确地了解问题所在的位置，同时害提供了是否可能被攻击者利用的相关信息。
如今，许多企业都在部署和执行“安全左移”概念，“安全左移”提升了软件开发生命周期（SDLC）对安全性，通过在 CI/CD 流水线中构建之后立即验证漏洞，并将其与测试一起纳入SDLC 流程早期。确定漏洞的优先级至关重要，因为这将为解决对企业构成最大威胁的风险提供重要参考。
企业通常可以使用两种方法来：参考通用漏洞评分系统 （CVSS） 或采用漏洞扫描解决方案提供的优先级。不论企业选择哪种方式，需要确保将上下文应用于每个漏洞及其在 IT 环境中的位置。例如了解以下一系列问题：
资产上下文将提供企业的暴露级别、潜在业务影响、威胁上下文和漏洞严重性信息。总之，完整的优先级计划应当包括漏洞的评估阶段（包括正确识别资产），然后扫描漏洞，并报告结果。
一旦发现并优先处理了软件漏洞，那么接下来就需要制定一个完善的漏洞修复计划。这个计划将包括阻止、修补和删除某些组件。企业需要仔细慎重地制定该计划，因为在修补漏洞程序中可能需要停机或可能产生一些意外影响等。开发团队可能会发布一个临时修补程序，以便在需要更多时间来正确修复漏洞时提供变通条件。
企业的修复计划还应当包括所有 IT 资产的全面且不断更新的视图。这包括从硬件和软件，再到移动应用程序的所有内容。企业还需要对所有组件进行精细、详细的访问，以了解每个资产之间是如何互连的，以及该资产对其他系统的依赖性。在了解了每种资产在整个 IT 环境中所扮演的角色，就能够更好地了解该资产对企业的价值和重要性。这些上下文信息和详细数据为确定漏洞修复的优先级奠定了十分重要的基础。
最后一个步骤，确定 DevSecOps 的优先级，并在 SDLC 中更快地进行漏洞修复，防止漏洞积压。当 DevSecOps 被优先考虑时，安全检测与开发的结合将变得更加无缝且高效，而这也依赖于在 SDLC 早期实现运行时分析和自动化。这样就能为响应时间提供了速度和准确性，更好的漏洞可见性，并根据此来确定和修复漏洞。DevSecOps 可以通过识别在企业环境中不可利用的漏洞来减少高达 85% 的漏洞积压以及修补工作。这样开发人员就可以修复最重要的问题，而不是毫无目的地修复所有漏洞。实际上，45%的Ponemon调查受访者表示，减少修补漏洞的时间是采用 DevSecOps 的主要原因，另一方面原因，则是对风险的优先排序和补救采取重点突出的方法（33%）。
根据 Ponemon 的调查结果显示，69%的受访者表示，他们所在的企业已经将 DevOps 完全过渡到 DevSecOps，并且已经或者开始在 SDLC的每个阶段或都集成了安全性（29%）。 大量的漏洞积压工作会给 DevSecOps 团队带来太多麻烦。修复所有内容并不总是现实的、实用的或安全的。专注于解决亟待解决的问题更加重要，拥有成熟的 DevSecOps 程序应该是漏洞管理策略的重要组成部分。建议企业采取必要的步骤来推进他们的 DevSecOps 计划。