Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Scanning at trackr (hub)

Scanning is the part of an ATO package an assessor can actually re-run. Narrative prose in an SSP describes intent; a scan produces evidence with a timestamp, a plugin ID, and a pass/fail that someone can argue about. That is why the scanning posture on a DoD or FedRAMP system gets disproportionate scrutiny, and why “we scan monthly” is a sentence an assessor will immediately try to disprove by asking which scanner, against what content, covering what percentage of the asset inventory.

A schematic routing diagram with five labeled lanes feeding scan results into a central authorization boundary.

This section splits into five families of scan, and they answer different questions. Mixing them up is the most common conceptual mistake I see in SSP language. A vulnerability scan tells you a host is running a CVE-vulnerable package. A compliance scan tells you a setting is off-baseline. Neither tells you your application has an injection flaw, and neither catches the malicious transitive dependency three levels down your package-lock.json. Different controls, different cadence, different owner.

The five families and where they land

The table is the map. Each row points at the subpages that go deep on the individual tools, plus the NIST SP 800-53 control family that makes the scan non-optional rather than nice-to-have.

Scan type What it answers Primary tools Control tie Who runs it / cadence
Vulnerability Known CVEs on running hosts and services ACAS, Nessus / Tenable RA-5 ISSO / scan operator, monthly minimum, weekly on High
Config / compliance Settings drift from the STIG or SCAP baseline SCAP, SCC, STIGs, Evaluate-STIG, STIG Manager, OpenSCAP CM-6 System admin / ISSM, per release and on change
SAST Flaws in first-party source code SonarQube, Fortify, GitHub Advanced Security, Checkmarx SA-11 Dev team, every build / PR
SCA / container / cloud Vulnerable dependencies, image layers, cloud misconfig Snyk, Trivy, Anchore / Iron Bank, Wiz SA-15, SR DevSecOps pipeline, every build + continuous
DAST Runtime flaws against the deployed app Burp Suite, OWASP ZAP SA-11 AppSec / pentest, per release or milestone

Read the control column as the thing that forces the scan into your plan, not as a clean one-to-one. RA-5 wants known vulnerabilities flagged and remediated; ACAS exists because DISA needed an enterprise way to satisfy it. CM-6 wants config settings established and enforced; the whole STIG and SCAP apparatus is the DoD’s answer. SA-11 is developer security testing, which is where both your SAST and your DAST evidence go. SCA and container scanning have grown up enough that they now lean on SA-15 (a defined development process) and the SR supply-chain family, because a CVE in a base image you pulled from a public registry is a supply-chain problem before it is a vulnerability-management one.

Vulnerability and config: the DoD core

On a DoD system the vulnerability and config families are the ones with the longest paper trail. ACAS is the program name; the engine underneath is Tenable, and Tenable has been busy renaming things. SecurityCenter became Tenable.sc, and as of the current branding it is Tenable Security Center. The cloud side, Tenable.io, is now Tenable Vulnerability Management. Nessus is still the scan engine doing the actual work. If your documentation still says “SecurityCenter,” it predates 2018.

Config scanning is its own zoo of government tooling. SCC (SCAP Compliance Checker, currently in the 5.x line, NIWC Atlantic) runs the automated SCAP content; Evaluate-STIG (NSWC Crane, a PowerShell scanner, CAC-gated) has been eating share for the checks SCC’s content does not cover; STIG Manager (open source) handles the review and tracking workflow; and on the Linux side OpenSCAP with the SCAP Security Guide content does the same job SCC does for Windows-heavy shops. The STIG and SCAP pages cover the standards; the tool pages cover what each one actually runs.

Code, dependencies, and runtime

The software half of this section is where the currency churns fastest, so a few things worth getting right before you cite them in a document.

Fortify is OpenText now, not HP and not Micro Focus, and the product is branded OpenText Static Application Security Testing (Fortify) on a CalVer cadence (26.1 shipped January 2026). GitHub Advanced Security stopped being one bundle on 2025-04-01; it split into GitHub Secret Protection and GitHub Code Security, and Copilot Autofix lives under Code Security. SonarCloud is now SonarQube Cloud (self-hosted is SonarQube Server), and Sonar bolted SCA onto an Advanced Security add-on in 2025. Checkmarx ships Checkmarx One and reached FedRAMP Ready at High in September 2025.

Two facts that flipped recently and trip people up. Wiz is no longer “being acquired” by Google; that $32B deal closed on 2026-03-11, and Wiz is part of Google Cloud (brand retained, still multi-cloud). And OWASP ZAP is no longer at OWASP. The core team joined Checkmarx in September 2024 and the project is now ZAP by Checkmarx, still Apache-2.0 and open source. If you are routing DAST work, Burp Suite and ZAP are the two to look at, and which one wins depends mostly on whether you need authenticated-session crawling that Burp’s macros handle better.

Deeper: scanning is not assessment, and conflating them costs you. A green scan is an input to an SA-11 or RA-5 determination, not the determination itself. The assessor still has to judge whether the scan covered the full boundary, ran against current content, and that the open findings have a real POA&M behind them. A scan against 60% of the inventory with the other 40% quietly excluded is worse than no scan, because it manufactures a paper trail that says you looked. Coverage percentage and content date are the two numbers an assessor reaches for first, and a clean result on stale content fools nobody who knows where to look.

The container and supply-chain corner deserves its own caution. Anchore has underpinned Iron Bank (the Platform One hardened-container registry) scanning since 2020, and it is named in the DoD Container Hardening Guide. Trivy (open source, built by Aqua Security) shows up constantly in pipelines for the same job. Snyk’s family covers Code, Open Source, Container, and IaC, and reached FedRAMP Moderate. Pick by where the scan has to run: a build-time gate in your CI is a different tool decision than a continuous cloud-posture scan, and the Wiz versus build-time-scanner question is exactly that split.

If you are new to this section, start with whichever family your current finding came from. Most people land here because a scan flagged something and they need to know which control it maps to and who owns the fix.

Sources

Adjacent material on this site