Effective Vulnerability Management Program

This is the article I wish I could’ve read when I was a junior engineer. Back then, I was buried in CVEs, chasing down untagged resources, and wondering why every (dev level) patch cycle felt like Groundhog Day. If that sounds familiar, you’re in the right place.

Step 1: Management Buy-In

Leadership buy-in is a known prerequisite to building any cyber program that can be seen as impacting developer or SRE velocity. Instead of repeating what any other security blog explains really well, I will share a few of the tips that worked in the organizations I worked for.

Always build your processes around the users who consume them, not only for the auditors or for yourself. This sounds simple, yes it is often not adopted or not maintained to ensure continuous improvement. This helps ensure the processes will be adopted and used in a lasting way.

• The KPI you create needs to make sense and provide actionable insights. Don’t just show red vulnerability graphs. Look at their source. Use tools like Wiz to analyze detection_method and uncover common sources of issues — like outdated OS versions or unpatched code dependencies.

• Identifying common root causes and providing an action plan (example in Step 4) make sure you eliminate entire classes of vulnerabilities at once, and help with leadership buy-in.

• Security solutions where details about findings are clearly reported, such as CNAPP solutions, should be easily accessible by the team who need the context to treat the risk from the findings (using least privilege access and tailoring to own resources of course!)

Tagging resources for accountability is mandatory, and it needs to be easy and agile - more on this in Step 2.

Step 2: Guardrails, Not Only Policies

Mandates from organizational policy are the foundational layer. They need to be complemented by measurable, trackable, and agreed upon requirements.

Examples of Effective Guardrails:

• Asset Inventory and Accountability - Tag your resources: Use Kubernetes labels, Azure tags, Google Cloud labels—whatever your cloud flavor—to identify ownership and accountability. When a critical vulnerability hits (hello, exploit in the wild!), you’ll know who to call. Provide clear guidelines that asset owner need to follow to set the accountabilitxy for any new or existing project. New repositories are created from the same template?

• Track KPIs that matter: Onboarding to the CI/CD security scanner solutions, CNAPP solution, and adherence to regular patching cycles

• If you have a Security Champions program, one should be elected in the product team as a pre go-live requirement. This of course needs to be known and communicated so it does not come as a surprise in the 11th hour before go-live

Step 3: Empower Security Champions and Developers

Security isn’t a silo—it’s a team sport. Empower your developers and security champions with knowledge, tools, and a seat at the table. How?

• Document the process: Make it easy to read and follow.
• Regular meetings: Show how hackers think. Walk through real-world exploits. Make it engaging, not scary. Listen to their concern and do not be tempted to just dismiss them because you “know better”.
• Train them: Teach them how to use tools like Burp Suite. Explain how severity levels are determined. Help them understand the “why” behind the “fix this.”

Step 4: Patch Like You Floss

Patching should be regular, like flossing. Two Types of Patch Strategies:

• You can procure hardened images from vendors such as ChainGuard, Docker or Wiz (WizOS).
• And / Or use tools like Renovate to automate dependency updates (or bump PR creation) if you prefer to not use the hardened image service due to having one more critical vendor to manage the risk from.

As Cailyn Edwards, Co-Chair of Kubernetes SIG Security and Senior Security Engineer put it in this episode of the cloud security podcast, you need to choose your battles based on your risk appetite and balancing other risks to see if you should adopt vendor provided hardened images, or patch yourself with tools such as Renovate.

In many cases both can be used as developers install dependencies on top of application images (even images that come with Node runtime need a few more npm packages).

The goal? Reduce the volume of findings and the avoid “cumulation of risk”

Risk Treatment: The Art of Saying “No” (Sometimes)

Not every vulnerability needs to be patched immediately. Some can be accepted, mitigated, or deferred—with justification. Build a risk treatment framework:

• Accept: Low severity, no exploit, behind multiple layers of defense, for which the cost of fixing is much greater than the likelihood of an expoit and its impact.
• Mitigate: Reduce the likelihood and/or impact from an exploit: Add WAF rules, 24x7 monitoring.
• Remediate: Eliminate the risk by treating the root cause
• Defer: With a plan and a timeline. Make sure this process is documented and transparent.

Final Thoughts

Scaling vulnerability management in an agile org isn’t about locking things down—it’s about enabling teams to move fast and stay secure. With buy-in, clear guardrails, meaningful metrics, and empowered developers, you can build a program that’s not just scalable, but successful.

And hey, if you can get developers to tag their resources and patch their dependencies without a fight? You deserve a medal. Or at least a coffee 🙂