Surviving the vulnpocalypse with Kusari

Every week I talk to CISOs and other leaders and every week they tell me some variation of the same thing: it’s harder and harder to keep up with security. The latest generation of frontier models make it easier and cheaper for attackers to find and exploit vulnerabilties. We built Kusari to give security teams the upper hand in the "vulnpocalypse."

Developers, with the help of their favorite AI assistant, are producing software at an ever-faster pace. Attackers, also with the help of their favorite AI assistant, are finding vulnerabilities at an ever-faster pace. These new vulnerabilities — often in old software — go beyond simple bugs by combining multiple exploits into a complex attack chain.

All of this churn creates opportunities for supply chain attacks, giving attackers an incredible force multiplier. With AI models like Claude Mythos showing an even greater skill in exploiting software, things won’t be slowing down any time soon. It’s no wonder that security leaders are losing sleep.

It’s easy to despair that your team will be crushed under the weight of this “vulnpocalypse”. Even if the individual vulnerabilities that AI models unleash aren’t particularly scary in isolation, the sheer volume can overwhelm developers. But this doesn’t have to spell disaster if teams are prepared. Kusari has tools that make prioritizing and remediating vulnerabilities easy.

Prioritizing vulnerabilities

Vulnerability prioritization is a skill teams can develop with discipline, practice, and a good framework. Not every vulnerability is equally important, so it’s critical for teams to focus on the most important work. “Important” is context-dependent, but there are a few general rules to follow.

Focus on data integrity. This may be controversial, especially for applications where downtime has a directly-attributable revenue loss, but it’s the right approach for long-term customer relationships. Your users will forgive you if they can’t access the site for a few hours. They will hold a grudge forever if a cyber attack deletes pictures of Grandma or siphons money from their accounts.

Prioritize production environments. Development and testing environments are important. If they are compromised or unavailable, that can ultimately slow your team’s overall velocity and lead to customer impacts. But production is the breadwinner.

Mitigate what you can and fix the rest. Some vulnerabilities can be mitigated relatively quickly. If you can prevent harm with a simple firewall change or configuration setting, then do that so you can focus on fixing the more complicated issues. When you’re able, you can come back to fix the mitigated vulnerabilities.

In your dependencies

Most of the software in your application isn’t yours. It’s open source libraries and frameworks that you are probably using on an as-is basis. It follows that most of the vulnerabilities you have to deal with also come from somebody else’s software. How do you prioritize these?

Focus on the reachable vulnerabilities. Just because a vulnerability exists in one of your dependencies, that doesn’t mean it affects your software. Often a vulnerability is in a particular function that you don’t call or in a configuration that you don’t use. If an attacker can’t reach a vulnerability, does it really exist?

Maximize your impact. All other things being equal, a vulnerability that exists in 20 of your applications presents a greater risk than a vulnerability that exists in one application. Fixing the widespread vulnerabilities first gives you the biggest return.

In your software

Even though most vulnerabilities are in code your team didn’t write, some may be. All of the advice above still applies to internal code. In addition, you can apply additional consideration for the code you control. These will be more important if you offer a bug bounty or other program to reward responsible vulnerability disclosure.

A proof of concept is worth a thousand words. It’s not enough that a vulnerability could hypothetically exist. There’s little cost in throwing a vulnerability report at the wall and seeing what sticks. When someone comes with a reproducible demonstration of the vulnerability, you know to take it seriously.

Downrank vulnerabilities that are documented behavior. Software sometimes has an “expert” mode that give the user more power or customization, with a tradeoff that it may increase the risk of use. An application that runs without authentication makes sense for local development. If you say “this mode is not for production use” and someone uses it in production, that’s not really a vulnerability.

Preventing vulnerabilities

As you get a handle on the new and existing vulnerabilities, you find you have the space to shift from a reactive to a proactive mode. I like to think of this as going from fire fighting to fire prevention. The easiest vulnerabilities to fix are the ones that never exist.

Only use necessary dependencies. Freely-available open source libraries have made it easy for small teams to produce incredible software. But every dependency adds risk. Sometimes it makes more sense to fork a dependency and use that internal version. For trivial tasks, the less risky move may be re-implementing the library internally.

Use dependency cooldowns. The latest software isn’t always the greatest. So many of the supply chain attacks this year could have been avoided by waiting a few days to update a dependency to a new version. This gives researchers a chance to find malware and for maintainers to clean up the damage before it spreads.

Replace end-of-life dependencies. A software package that has no known vulnerabilities today may have some tomorrow. If a dependency has reached end-of-life, it won’t get fixes when those vulnerabilities are discovered. Continuing to use end-of-life versions of your dependencies is akin to betting that they’ll never have vulnerabilities discovered. In the fullness of time, that’s a losing bet.

Let Kusari help

You don’t have to solve this problem alone. Kusari supercharges your ability to prioritize and fix vulnerabilities across your entire software portfolio.

Kusari Reachability Analysis automatically analyzes your code to find out which vulnerabilities are reachable and which aren’t. When a vulnerability isn’t reachable, Kusari produces a Vulnerability Exploitability eXchange (VEX) document that you can provide to customers or regulators.

Kusari Score takes into account both a vulnerability’s technical severity and breadth in your environment. This score, based on our deep software supply chain experience, gives you an easy priority ranking.

Kusari AutoFix will automatically apply and verify updates for dependencies to fix vulnerabilities and ensure that new ones are not introduced.

Kusari Platform makes it easy to find end-of-life dependencies in your software so you can replace them before they cause problems.

Kusari Inspector gives your developers immediate security feedback in pull requests to prevent new security concerns from entering your code base.

Ready to get a good night’s sleep? Schedule a demo to see how Kusari helps you avoid the vulnpocalypse.