A lot of ISSOs come into the role from a documentation or compliance background, and then a vulnerability scan report lands on their desk with hundreds of findings, a column full of acronyms and severity scores, and an expectation that they’ll know what to do with it. If that’s you, you’re not alone, and the gap is smaller than it looks.
This guide covers what ACAS and Nessus actually do, how to read a scan result without getting lost in the noise, and how scan findings connect to the POA&M and STIG work you’re already doing.
What ACAS and Nessus Actually Do
ACAS is the DoD’s standard vulnerability scanning suite, built around Tenable’s Nessus scanning engine along with additional components for managing scan results across an enterprise. At its core, a Nessus scan connects to systems on the network and checks them against a huge library of known vulnerabilities and misconfigurations, then reports back what it found.
There are two broad types of scans that matter for how you interpret results. A credentialed scan logs into the target system and inspects it from the inside, checking installed software versions, configuration settings, and patch levels directly. An uncredentialed scan only sees what’s visible from the network, probing open ports and services without logging in. Credentialed scans are far more accurate and produce far fewer false positives, because they’re looking at the actual system state rather than guessing from the outside.
Real-World Example: The Scan That Looked Worse Than It Was
A scan report came back showing dozens of critical findings on a set of servers, which immediately set off alarm bells. When the team dug in, it turned out the scan had run without credentials for that segment, because of a service account password that had recently rotated and hadn’t been updated in the scanner’s configuration.
Without credentials, the scanner could only guess at what software versions were running based on banners and network responses, and it guessed wrong for a number of services, flagging old, vulnerable versions that had actually been patched months earlier. Once the credentials were fixed and the scan re-run, the vast majority of those critical findings disappeared. The systems hadn’t gotten more secure. The scan had just gotten more accurate.
Before reacting to a scary scan result, check whether the scan was credentialed. It changes how much you should trust the findings.
Reading a Finding: What the Fields Actually Mean
Each finding in a scan result typically includes a plugin ID (Nessus’s internal identifier for the specific check that triggered), a CVE number if the finding corresponds to a known published vulnerability, a severity rating, and a CVSS score that quantifies how severe that vulnerability is considered to be in general.
The severity rating and CVSS score describe the vulnerability in the abstract, not necessarily its impact on your specific system. A critical CVSS score on a service that’s only reachable from an isolated internal segment with no path to sensitive data is a different real-world risk than the same score on something internet-facing. This is part of why a POA&M entry’s severity should reflect an assessment of the finding in context, not just a copy of the scanner’s raw score, something covered in more depth in the POA&M management guide.
How Scan Findings Connect to STIGs
Vulnerability scans and STIG compliance checks overlap but aren’t the same thing. A vulnerability scan looks for known software vulnerabilities, missing patches, and certain misconfigurations. A STIG check verifies compliance with a much broader set of configuration requirements, many of which aren’t vulnerabilities in the CVE sense but are hardening requirements: password policy settings, audit logging configuration, unnecessary services being disabled, and so on.
In practice, both run against the same systems, and both feed the same POA&M. A useful mental model: vulnerability scans tend to catch “this specific known flaw exists,” while STIG checks tend to catch “this system isn’t configured the way DoD requires it to be,” even if no specific flaw has been identified yet. Both matter, and an ISSO needs to track findings from both without treating them as duplicates or assuming one covers the other.
Real-World Example: The Finding That Kept Coming Back
A particular finding kept reappearing on monthly scans even after the engineering team confirmed they’d applied the relevant patch each time. After a few cycles of this, someone checked the scan’s scope configuration and found that the scan was targeting an IP range that included a few decommissioned hosts still responding on the network, alongside the active ones that had actually been patched.
The finding wasn’t wrong. It was accurately describing systems that were technically still part of the scanned range but no longer part of the system as it was actually documented in the SSP. The fix was updating the scan scope to match the current system boundary, not chasing a patch that had already been applied.
This kind of mismatch between scan scope and documented system boundary is worth checking whenever a finding seems to persist despite remediation. The scan might be scanning something that isn’t quite your system anymore.
A Practical Approach to Reviewing Scan Results
Before diving into individual findings, check the scan metadata: was it credentialed, does the scope match your current system boundary, and when did it run relative to your last patch cycle. These three things determine how much weight to give the results before you’ve looked at a single finding.
When triaging findings, group by host and by plugin rather than working through a flat list. A single misconfiguration can generate the same finding across dozens of hosts, and fixing it once at the source (a baseline image, a group policy setting) closes all of them at once, which is a very different remediation effort than fixing dozens of individual findings one at a time.
Finally, compare new findings against the previous scan. A finding that’s new since last time deserves more immediate attention than one that’s been open and tracked for months, even if the severity score is the same, because a new finding might indicate a recent change introduced a regression.
Final Thoughts
A scan report can look overwhelming, but most of what makes it manageable isn’t deep technical scanning expertise. It’s knowing to check whether the scan was credentialed, whether the scope matches your system, and how to group findings by root cause instead of treating each line as its own problem. Once those habits are in place, scan results stop being a wall of red and start being a structured list of things that either need fixing or need the scan itself corrected.
The technical depth comes with time. The triage habits are what keep a scan report from becoming an unmanageable backlog in the meantime.
Leave a Reply