In today’s interconnected and rapidly evolving software landscape, vulnerabilities are an unavoidable part of development. A vulnerability is any weakness in a software system that can be exploited to compromise the integrity, confidentiality, or availability of the system or its data. As the complexity of applications grows, so does the attack surface. With dependencies on numerous external libraries, open-source packages, and container images, transitive CVEs become one of the most common vulnerability findings and worth focusing at.

Effective vulnerability (or in our case CVE) management is crucial to mitigating these risks. It involves a continuous, structured process of identifying vulnerabilities, assessing their severity and relevance, deciding on mitigations or suppressions, and tracking their resolution over time. Proper management not only protects systems from exploitation but also ensures compliance with security standards, contractual obligations, and internal company policies.

Why more efficient CVE Management?

Vulnerability management remains a difficult field across the software industry. From the developer perspective, there is currently no widely adopted standardized approach or tooling that covers all phases of the software development lifecycle consistently. Organizations often assemble incomplete toolchains and ad-hoc processes, leading to gaps, duplication, and inefficiencies. The lack of standardization complicates cross-team collaboration and governance, making it harder to maintain a consistent and sustainable security posture.

Developers most likely face vulnerabilities the first time when a CI/CD pipeline stops for a new release, because it for example found a critical vulnerability (CVE with a score of 9+) in a third-party dependency of the software artifact. Depending on company policies, this behaviour is common to prevent the introduction of new CVEs before the software can even be deployed (also called “security gate”).

At this point, the developers face two options:

1. Check if the dependency has a newer version and upgrade to fix the CVE. This is not always possible.
2. Assess the CVE with a security chief and decide whether it is a false positive or the vulnerability in question is not reachable and therefore can be suppressed. This usually involves documenting the assessment and configuring the CI/CD pipeline to ignore the CVE.

There are several challenges that we and our customers faced with such processes:

• Tool fragmentation without integration: The teams and stakeholders use different tools for vulnerability scanning, analysis, approval and documentation of assessments but they all work on their own data.
• Intransparency: Without a centralized view, we cannot easily track open, suppressed, or resolved vulnerabilities.
• Compliance unclear: As a consequence, we often cannot know whether we are compliant with regards to corporate policies and internal SLAs, thus cannot create the required reports to document the level of compliance. We did not know if all active suppressions have been approved or when exceptions were no longer needed in the pipeline configuration.
• Duplication of work: Identical vulnerabilities in multiple artifacts and teams are often assessed and handled separately, leading to wasted effort.

We see an opportunity to introduce a more integrated, efficient, and scalable process that supports not only developers but a broader set of stakeholders.

What is our goal?

To tackle the named challenges, we set out to research available tools and approaches for vulnerability management, with a particular focus on CVEs (Common Vulnerabilities and Exposures) in third-party components. We aim to use these tools to design a more efficient CVE management process covering the entire lifecycle (develop, build, deploy, run). When managing CVEs we:

• Track CVEs and their state (e.g. open, suppressed, fixed), covering de-duplication across software artifacts or versions.
• Assess vulnerability impact based on different factors like EPSS, usage context, risk exposure, VEX-encoded prior assessments, and available mitigations.
• Suppress CVEs based on that assessment, within or across teams.
• Define security gates for CI/CD environments to prevent software artifacts with unacceptable levels of CVEs to be deployed.
• Generate reports to document compliance, enable audits, and increase visibility for internal stakeholders.

Since the field of vulnerability management is extensive, this blog post only tackles a specific scope which we will outline below:

Perspective: We approach the problem from the perspective of software engineering teams responsible for building, packaging, and even deploying their own products – not from an IT operations or infrastructure security viewpoint. Beyond developers, the solution should also serve and benefit other key roles in the company, including:

• Security teams who require a global view of vulnerabilities and risk exposure across all software artifacts.
• Product managers and project leads who need transparency into security risks that could affect delivery timelines and product quality.
• Compliance officers who must track adherence to internal policies, external regulations, and contractual obligations.
• DevOps and release engineers who are responsible for integrating security checks into CI/CD pipelines without disrupting delivery workflows.

Vulnerabilities: Finding CVEs in third-party dependencies falls under Software Composition Analysis (SCA). We will not cover vulnerabilities in our own source code (which would fall under SAST, or Static Application Security Testing) or vulnerabilities discovered at runtime (typically addressed through DAST or IAST techniques).

Finding the right tools

Considering the scope and our goal, we identified the following (non-exhaustive) list of suitable tools covering CVE management:

• SecObserve (https://maibornwolff.github.io/SecObserve)
• Snyk – Enterprise License (https://snyk.io)
• FOSSA – Business License (https://fossa.com)
• FlexNet Code Insight (https://www.revenera.com/software-composition-analysis/products/flexnet-code-insight)

The table below compares these 4 tools across different categories. We color coded each cell to express our rating in relation to the scope and goal described before.

• 🔴 Red: Not available / not useful
• 🟠 Orange: Restrictive / difficult to use
• 🟡 Yellow: Could be restrictive, depends on use case
• 🟢 Green: Readily available / good implementation

Brief tool summaries

The following slider will give an overview of the evaluated tools.

Drafting an efficient process with such tools

The features of those CVE management tools allow defining build and rollout processes that tackle some of the named challenges. Let’s assume a more conservative setup with stricter corporate policies where SecObserve fits with its integrated approvals.

The initiator of a build is a change, typically pushed by a developer. Changes may or may not introduce or fix CVEs. Avoiding CVEs surely is best, some of the tools can help with that. A specialized tool for avoiding transitive CVEs is Renovate that can automatically push changes to update dependencies.

All changes trigger the build pipeline where the packaged software artifact is first scanned for CVEs, e.g. by Trivy. The report (SBOM) is then imported into SecObserve to track all CVEs contained in this artifact version. Scanning containerized artifacts covers the code and the base image with its OS dependencies. Findings do not block non-productive rollouts, including testing activities. Only productive rollouts would enforce the artifact’s compliance based on the information in the CVE management tool. For example, „artifacts must not be rolled out when they include one or more unresolved CVEs with criticality HIGH or higher“.

This gives developers time to resolve findings from the first scan of their artifact version to the productive rollout. They analyze findings with the guidance provided by the tool, either fix the issues or propose suppressing the issue – either for the artifact individually or per rule for all versions / artifacts. With SecObserve, such assessment can require approval by a security chief. When all relevant issues are either fixed or assessed, productive rollouts become allowed.

Even after rolling out what seemed to be a safe artifact, security is not guaranteed. New issues may become known that the artifact may be affected by. While some tools support continuously scanning containers, Trivy Operator is a specialized scanner creating SBOM reports. Re-importing them to SecObserve nightly ensures having up-to-date CVE data even on deployed versions while respecting prior assessments.

Most tools were not able to fully support composed artifacts (e.g. based on a Helm chart) natively, including SecObserve. Such features can be achieved with scripting, acting on the contained atomic artifacts.

Figure 01: conservative CVE management with SecObserve

Using one of the other tools like FOSSA or Snyk allows for different features, potentially supporting your team earlier – at higher integration and license costs. Pick whatever fits best with your culture and budget.

Conclusion

A broad range of products and product types cover CVE management. Some offer additional CVE-related features (like auto-fixing, attack vector analysis) but typically require extensive integration (intrusion, sometimes) and focus on preventing and scanning for CVEs.

Specialized CVE management tools are more lightweight but seem sufficient to tackle the challenges we wanted to solve: They provide rich rule-based suppressions at various scopes, avoiding redundant assessment within teams or organizations. In a single tool, they provide (or enable) security gates to enforce CVE resolution before rollouts, with respect to the (security-chief approved) assessment. They can be loosely integrated with existing security tooling (e.g. Renovate, Trivy, Trivy Operator) and allow for a more transparent tracking of CVEs across versions.

Outlook and Next Steps

This blog post focuses on establishing a foundation for managing CVEs in third-party components. However, we recognize that this is only one part of a broader vulnerability management landscape. Future blog posts may explore the unrestricted capabilities of the tools we evaluate now. Additionally, we may choose to broaden the scope in several directions:

• Cloud-native vulnerability scanning, including infrastructure-as-code (IaC) templates, container registries, and runtime configurations next to CVEs.
• AI-assisted risk scoring, helping prioritize findings not only by CVSS scores but by actual exploitability, usage context, and business impact.
• Automated assessment, either with the help of AI or (in case of transitive dependencies) VEX. Though VEX seems fairly supported, very few vendors seem to provide that data and centralized hubs are not a thing yet.
• Developer enablement, by embedding recommendations, suppressions, and remediation guidance directly into IDEs or merge request workflows.

These areas would build on the foundation we lay now and move us toward a more proactive, streamlined, and integrated security posture.