← Back to VulnScope

Yashesh D. Shah

Melbourne, Victoria, Australia

I have spent about fifteen years in application security and vulnerability management, across loyalty, financial services and investment banking. VulnScope came out of the part of that work that never quite had a good answer.

Why I built VulnScope

Running a vulnerability management program means facing a queue that is always longer than the capacity to clear it. The scanners are not the hard part — consolidating findings from half a dozen tools into one place is a solved problem, and I have done that migration more than once. The hard part is what comes next: of several thousand open findings, which ones genuinely matter here, and can you defend that answer to an engineering lead whose sprint you are about to interrupt?

A CVSS score is a property of the vulnerability. It is identical for every organisation on earth. Your risk is not — it depends on whether the affected asset is internet-facing, holds cardholder data, sits in PCI scope, and whether anyone is exploiting the flaw today.

Commercial platforms do this well, and I use them daily. I built VulnScope to work through the reasoning from primary sources rather than accept a vendor's number — to join the CVE feed to business context, add the exploitation signals CVSS omits (CISA KEV, EPSS), and resolve each finding to a documented action using CISA's published SSVC decision model rather than a proprietary score. The result is a recommendation you can show an auditor and explain line by line.

It is a demonstration of an approach, not a product, and it does not try to replace the platforms it borrows ideas from. What it does show is that the prioritisation logic those tools apply is understandable, reproducible, and mostly buildable on public standards.

Get in touch

Happy to talk about vulnerability management, prioritisation models, or anything on this site — including where you think it is wrong.