How can you interpret vulnerability scan results?

Understanding what, and how much, your vulnerability scanning tools have been configured to scan is a firm prerequisite to consider before you even take the first glance at your reports. Configuring a vulnerability scanner in a way that is effective and persistent is not a trivial task. Rather than assume that everything has been setup well, investigate. What integrations are available? Are the connectors enabled? Does the data ingest the way you expect? Skip these steps and rest assured that your scan results are at best inaccurate and possibly even meaningless.

This is true, we literally was just told by a vendor that we should not use their default filter when scanning our code, instead we should have used one of their custom profiles that is more atoned to our industry and tech stack.

When deciding which tool to be used, we need to identify what type of solution we need to do the job, as depending on the type of tool, is the type of data output that it will be given to us. We have several type of scans Our choice will depend on our needs. Each type will provide us a report that can cover specific aspects of the required scope (a single VM, an micro-service, a network segment, etc). All the mentioned resources have possible "cracks", however the behavior and outcome of each one of them is different. We need to understand that each of this situation have a "weight" and possible impact on the regular work of any organization, so we need to review and be able to calculate the possible scenarios and attached risks to them.

Your first stop after getting your coffee and starting your playlist should be your dashboards. Not the least of which is your vulnerability scanner dashboard. Start by reviewing how many assets were scanned. If this number isn't familiar to you, if it's inconsistent, if there's no predictable rhythm to it, go back to your configurations and connectors and figure out what's wrong. Next, take a look at the graphs that give a high level view of broad trends, such as total vulnerabilities found and average age of vulnerabilities over time. This trend doesn't always need to look like a perfectly diagonal line approaching zero all the time. Instead, use this trend to gauge how effective you and your team are from quarter to quarter.

Prioritize high-risk vulnerabilities and assess top vulnerable hosts, especially with sensitive data. Examine open ports for potential risks. Address easily exploitable vulnerabilities, even if low-severity. Document actions for audits. After remediation, always re-scan. Active engagement with these insights ensures robust defense.

When you get into the fine-grained details of your scan reports, you'll find dozens of data points for each asset and several different ways to view every report, by vulnerability, by asset, by severity, and so on. Get familiar with these views and the data points they present, some will fit your personal preferences better than others. You'll be using these to drive your remediation efforts, so be sure to review new scan results regularly.

I always use the below approach to eliminate false positives or verify- Cross-Validation: Compare scan results with other tools. If multiple tools flag the same vulnerability, it’s likely genuine. Manual Testing: Deploy controlled exploits on detected vulnerabilities. If they're exploitable, they're real.

Don't forget to get your product team leads involved in this step. And don't just take their word for it, watch their actions, they speak louder than words!

How do you measure the effectiveness of your vulnerability management program? If you're currently using "total vulnerabilities closed" as your primary metric, you will probably discover that it's not as descriptive as you might think at first glance. For one thing, it doesn't communicate hours of hard work invested in remediation because not all vulnerabilities are created equal. Instead, you'll need to track a combination of metrics in relation to each other. One of those might be total vulnerabilities closed, but it'll have significantly less weight than metrics related to finally remediating critical vulnerabilities tied to exploits on platforms like Cobalt Strike and Metasploit.

Do not print out the cookie-cutter descriptive executive report, trust me on this. You're going to want to type up your own report document to describe the graphs and charts that come out of the vulnerability scanning tool. Each new report should be an incrementally refined version of the last previous report. Refine reports that you send to decision makers. Ask what works and what doesn't, and use that to tie your vulnerability scanning efforts to business objectives.