Creating an Effective Vulnerability Management Program for Open Source Vulnerabilities

Introduction

Through conversations with security leaders, we’ve encountered countless approaches to managing vulnerabilities. In this post, we condense the best takeaways into a recommendation for how to setup a sustainable vulnerability management program. This post focuses primarily on vulnerabilities in open source components, but many of the principles apply to other types of vulnerabilities as well.

We begin by introducing the core of a vulnerability management program: the vulnerability management lifecycle. Then, we explore how to map a company’s risk tolerance to security policies that shape the program’s design. Finally, we provide a practical example of how such a program might be implemented in a typical organization.

Vulnerability Management Lifecycle

At the heart of an effective vulnerability management program lies the vulnerability management lifecycle, consisting of four key steps:

1. Scanning
2. Prioritization
3. Remediation
4. Verification

This four-step process ensures that vulnerabilities are identified and addressed in a systematic and repeatable process. The verification step is often just a repetition of the scan step where it is verified that the vulnerability is no longer found.

While the process may seem straightforward, each step can range from relatively simple to highly complex depending on your organization’s security needs and maturity level.

For example:

• A simple scanning approach might involve running a manual security scan using an open source tool like Dependency-Check on a monthly basis.
• A more advanced scanning setup could involve fully automated daily scans combined with guardrail checks triggered on every commit or build to prevent developers from introducing new vulnerabilities.

Vulnerability Management Lifecycle Goal

The success of a vulnerability management lifecycle isn’t measured by how many vulnerabilities it can detect and fix as quickly as possible. Instead, it’s about creating a process that aligns with the business’s risk tolerance while optimizing resource allocation.

While fixing every vulnerability immediately might seem ideal, this approach is often neither feasible nor cost-effective. Chasing every issue can divert resources from higher-impact security and engineering tasks.

To be effective, the lifecycle must be practical and sustainable for both security teams and developers—even during high-pressure periods. A well-designed process strikes a balance between addressing security risks and maintaining operational productivity.

Determining the Risk Tolerance

A company’s risk tolerance in vulnerability management depends on several factors, such as:

• Business Maturity: Is the company a startup or an established enterprise? Larger, mature companies are more likely cyberattack targets.
• Market Focus: Does it serve consumers, businesses, or both?
• Industry Regulations: Is the business operating in a highly regulated industry like finance, healthcare, or government?

Regulatory and compliance requirements often shape a company’s approach to vulnerability management just as much—or even more—than the actual risk of security incidents. Certifications and regulations like SOC 2, DORA, HIPAA, and FedRAMP frequently drive the design of security programs, influencing policies, processes, and tooling choices.

A good way to structurally determine the risk tolerance is to build a risk register that lists risks and determines what, if anything, should be done to mitigate them. Risks are typically also assigned an impact and a likelihood score to help rank them against each other. Some compliance platforms like Vanta provide templates for building a risk registry.

Defining Policies

To ensure a vulnerability management lifecycle stays aligned with the organization’s risk tolerance, it’s helpful to formalize the risk tolerance as policies. These policies outline how vulnerabilities should be identified, prioritized, and remediated.

As with other aspects of vulnerability management, policies can range in complexity, depending on the organization’s needs and maturity level.

Examples of basic policies:

• Generate a daily snapshot of all known vulnerabilities in our applications.
• Vulnerabilities with critical or high severity must be assessed within 30 days of discovery. If they are found to be likely exploitable, they must be fixed within an additional 30 days.

Examples of stricter policies:

• Vulnerabilities with critical severity must be remediated within 48 hours of discovery.
• All vulnerabilities in applications with internet exposure must be patched within one week.

Applying different security policies based on application type is a good efficiency measure. For example, internal applications that aren’t internet-facing may require less scrutiny than customer-facing systems.

Security policy design is rarely an exact science. It involves balancing the company’s risk tolerance with what’s feasible given available resources. Starting with lightweight policies helps avoid overwhelming developers, allowing the program to scale and adapt as the company grows or its risk tolerance evolves.

Designing the Vulnerability Management Program

With a well-defined set of policies in place, designing the actual vulnerability management program becomes much more straightforward. The policies act as clear goals that guide how the program should operate to meet the organization’s risk management objectives.

To design the program effectively, consider the four steps of the vulnerability management lifecycle—Scanning, Prioritization, Remediation, and Verification—and ask these questions for each step:

• Who is responsible for carrying out the task?
• When should the task be performed or triggered?
• How will the task be executed, tracked, and reported?

Often the who is mostly a matter of understanding the responsibility split between security and engineering. Commonly, security are responsible for scanning, prioritization and verification while the remediation task lies with engineering.

The when is usually guided by the requirements set by policies.

Finally, how is often a matter of selecting the right tooling.

Tools for the Vulnerability Management Lifecycle

A wide range of free and paid tools are available to support every step of the vulnerability management lifecycle. Choosing the right tools depends on the complexity of your security program and the policies you’ve defined.

Lightweight Programs:

If you’re running a lightweight vulnerability management program with minimal policies, open-source tools like Dependency-Check can cover basic scanning needs. You can pair these with a simple spreadsheet for tracking vulnerability prioritization and remediation.

Mature Programs:

For more complex environments, a commercial tool may be a better fit. These tools typically provide end-to-end support for all four steps of the vulnerability management lifecycle and can offer a significant return on investment, especially for organizations managing many applications and vulnerabilities.

Common Features of Commercial Tools:

• Reachability Analysis: Helps prioritize vulnerabilities by determining if vulnerable functions are actually invoked.
• 2-Way Ticketing Integrations: Automates parts of the remediation process by syncing with services like Jira or Linear.
• Automated Scanning: Continuously scans new repositories as they’re created.
• Compliance Integrations: Connects with services like Vanta or Drata to streamline compliance reporting.

If you opt for a commercial tool, ensure it supports the programming languages and package managers your teams use and integrates with your ticketing service. Insist of a free trial period to evaluate whether a tool meets your organization’s specific needs.

Example Vulnerability Management Program

Let’s explore how a structured vulnerability management program might look for a startup that has recently scaled to the point where formal security processes have become essential.

Company Context:

• B2B SaaS
• 20 developers
• A head of security

Company Risk Tolerance:

• Processes personally identifiable information (PII), making data leaks potentially business-critical and therefore need to invest the necessary resources into removing exploitable vulnerabilities in applications.
• Undergoes yearly SOC 2 audits as a key driver for securing new business contracts, and therefore needs a structured process for managing vulnerabilities in applications.

Policies:

• All applications must be scanned for known vulnerabilities on a daily basis.
• Vulnerabilities must be resolved based on severity (CVSS score):
  • Critical: At most 7 days
  • High: At most 30 days
  • Medium: At most 90 days
  • Low: No resolution required
• Remediation options:
  • Fix the vulnerability by updating or patching.
  • Document why the vulnerability won’t be addressed (e.g., low exploitability or compensating controls such as a firewall or user input sanitization).

Vulnerability Management Lifecycle

Scanning: Daily vulnerability scans are conducted using OWASP Dependency-Check, configured as a scheduled task in the CI/CD pipeline. The DevOps team is responsible for managing this process.

Prioritization: The head of security reviews all newly reported vulnerabilities. Relevant findings are converted into Jira tickets with high-level descriptions and remediation recommendations. These tickets are assigned to the appropriate development team. Vulnerabilities deemed irrelevant are dismissed with a clear justification documented.

As the company grows, the number of detected vulnerabilities typically increases as well. To manage this change, adopting automated prioritization methods such as reachability analysis becomes essential.

Remediation: Development teams are responsible for fixing vulnerabilities assigned to them through Jira. Tickets are assigned SLAs according to the policy timelines. If a team believes a vulnerability should be dismissed instead of fixed, they must provide proper justification for approval.

Verification: After fixes are deployed, the head of security verifies that vulnerabilities no longer appear in subsequent scans. If a vulnerability is dismissed, its justification must be approved by the head of security. Once the issue is resolved or properly dismissed, the corresponding Jira ticket is closed.

Conclusion

The goal of this post was to provide an overview of key considerations when designing a vulnerability management program and to help you structure the process effectively.

Success doesn’t come from creating the most ambitious program or using the most advanced tools. Instead, focus on designing a process that aligns with your business goals while remaining sustainable—even when security and development teams are overwhelmed with other priorities.

We’ve seen many organizations implement overly complex programs, only to face vulnerability fatigue as developers become swamped with remediation tasks competing with other tasks for attention. This often leads to missed SLAs, growing backlogs, increased friction between security and engineering, and a higher risk of important vulnerabilities going unaddressed.

When Volume Increases, Reachability Analysis is Required

In the example above, we outlined a structured vulnerability management program. As complexity and vulnerability volume increase, advanced prioritization becomes essential—this is where Coana plays a key role.

Coana’s vulnerability scanner helps you prioritize vulnerabilities in open source dependencies by identifying the more than 80% of vulnerabilities that are in unused parts of dependencies (learn more here).

Additionally, Coana supports key features for an effective vulnerability management program, including remediation tooling, two-way ticketing integrations, and automated scan deployments.

‍

‍