A customer recently told me: “We’re full up on bugs. Our problem isn’t discovery - it’s remediation.” It begs the question: have you discovered the right bugs? The ones that will impact your operations or revenue generation capabilities? Being “full up on bugs” doesn’t mean you should stop trying to find them. It’s time to focus on your triage and remediation processes so you can better understand which bugs need fixing, and how.

Building a light weight remediation process and using the insights from remediation activities can ultimately save engineering time and improve software quality. This post focuses on software remediation but applies equally with light translation to IT/network remediation.

The engineering time required to remediate vulnerabilities can be one of the biggest costs of a security assessment. But, investing in the remediation process and investigation can also be one of the biggest areas of value, leading to both fewer bugs introduced in the future, and faster and cheaper remediation. This process can help your team prioritize Software Development Lifecycle (SDLC) security improvements backed by data.

SDLC diagram with security activities

Here are some ways to get value from your remediation process and create a feedback loop with development teams, no matter if you’re using internal or external resources:

  • Build baseline metrics. Measure how long it takes (engineering or dev cycles) to remediate issues. This serves as your ROI indicator as you mature the remediation process.

  • Triage & prioritize vulnerabilities based on business impact. CVSS, as an example, doesn’t do this - a CVSS 9.0 can have less impact to your business than a well-placed CVSS 5.0. Great commentary from Denis Shostack here about what we want from a bug ranking system. We’ve used a Bug Bar internally, but in most places, DREAD will work as a starting place.

  • Pick out themes from the bugs you know about and figure out when (and why) the finding was introduced. The least expensive place to remediate issues is the SDLC stage in which they are introduced.

  • Learn and improve from what was found. The stage at which the bug was introduced prescribes the remedy. The frequency of architectural flaws can be reduced through threat modeling; conceptual coding flaws through security champions and active support, etc.

  • Use one time remediation activities to build the right security activities into your SDLC. Determine when (at which stage) the issue was introduced to determine the appropriate process to fix it. This is where you start to see ROI - eliminating bug classes and identifying bugs quickly after introduction.

While an abundance of discovered bugs can seem daunting, it represents an opportunity to refine the remediation process and enhance the overall quality of the software. Hopefully, these techniques can help you to remediate security bugs before you become “full up.” Remember, the goal isn’t merely to plug holes — it’s to reinforce the entire structure, ensuring that each fix contributes to a foundation that’s increasingly resilient against threats.

Something we missed? Ready to shift your security activities left? Give us a call. We look forward to your feedback.