Unpacking the Kusari “Effort to Fix” Capability
Get a clear understanding of the work involved in remediating a vulnerability so you can schedule it in your sprint without blocking feature work.
Parth Patel
Jeff Mendoza
February 18, 2025
“How much work will that take?” is a common question when planning any kind of work, including software development. This is true not just for creating new features, but also for remediating vulnerabilities and other bugs. It’s not that more difficult work is unimportant — it might be the most important — but your developers only have so many hours in the day. Knowing the effort involved in remediating a vulnerability helps you schedule the work and determine how it can be allocated as part of the sprint without causing a roadblock on feature work.
How the Kusari Platform calculates effort to fix
The Kusari Platform calculates the effort to fix by comparing the current version to the fixed version. Based on Semantic Versioning, effort to fix treats major version changes as high effort, minor version changes as medium effort, and patch version changes as low effort. This also takes into account how deep the vulnerability is in your dependency graph — whether it’s a direct or indirect dependency. Providing you this holistic view allows you to understand the order in which fixes need to occur — and at what layer — so that you can respond most effectively.
Patch version upgrades should be trivial, as they don’t change APIs – the way the software interfaces with other software or humans. On the other end of the spectrum, major version upgrades can contain significant changes to the software. If the upgrade changes an API that your software relies on, you might need to spend significant time changing your software to work correctly with the fixed version.
The goal for the Kusari Platform is to provide you with the information that you need to fix the vulnerability quickly or automate the fix for you. But before that can happen, trust must first be built in the system. So we currently provide remediation information and automatically create tickets in Jira or other ticketing systems based on the Kusari Score to help you organize your sprint. Once we have gained the customer’s trust, we can offload the management of low effort vulnerabilities and provide a detailed path forward for medium to high effort to fix.
How to use effort to fix
Instead of trying to calculate a specific number of person-hours to remediate the vulnerability, the Kusari platform uses high/medium/low categories. This presents a more trustworthy estimate. The actual number will depend on the details of a particular vulnerability, how deeply embedded the dependency is in your application, the skills of your team, and many other factors.
You can use the effort to fix analysis to help schedule the work you need to do. Pretend that you know from experience that low effort fixes take 1 hour, medium effort fixes take 4 hours, and high effort fixes take 10 hours. If you have 2 low effort fixes, 2 medium effort fixes, and 1 high effort fix for a single developer, you could have them do the two mediums on Monday, the two low on Tuesday, and the high Tuesday and Wednesday. That’s only one way to arrange those particular bricks, of course.
The effort to fix value pairs well with the Kusari Score. When you have vulnerabilities with the same or similar Kusari Score, you can prioritize fixing the lower effort vulnerabilities first in order to reduce your overall vulnerability count more quickly.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more?