AO coverage. Addresses all five Vulnerability Scan objectives: the scan frequency is defined; systems are scanned at that frequency; applications are scanned at that frequency; systems are scanned when new vulnerabilities are identified; and applications are scanned when new vulnerabilities are identified. The systems-versus-applications split is where we previously failed — host scanning was mature and application scanning was ad hoc — so the standard treats them as two separate programs with separate schedules.

Defined frequencies, by asset class. The vulnerability management standard tabulates them rather than stating a single company-wide interval. Hosts: Tenable agents report every 24 hours on every endpoint, server, and build runner; a credentialed network scan of each internal enclave subnet runs weekly to catch anything without an agent; the external perimeter is scanned weekly from outside; and a quarterly unauthenticated internal scan runs specifically as a coverage check against the agent data. Network devices and the two hypervisors are scanned weekly with device credentials. Applications: dependency and container image scanning run on every pull request and every build, with a nightly rescan of the image digests actually deployed in production, because an image that passed at build time accumulates new CVEs while it sits in the registry. Authenticated dynamic scanning of the portal with Burp Suite Professional runs quarterly and additionally before any release that changes authentication, authorization, or file upload handling.

Event-driven scanning. New-vulnerability triggers are defined in the same standard: addition of a CVE to the CISA KEV catalog for technology in our inventory, a vendor advisory rated critical for a product in the boundary, an EPSS score crossing our threshold for an already-known finding, or a credible report from a customer. A trigger produces a targeted scan — hosts, applications, or both, depending on where the affected technology lives — within 48 hours, scoped by an inventory query rather than by memory of where the software is installed. Before that scan runs, plugin and signature feed currency is confirmed; a scan against a plugin set that predates the advisory finds nothing and reports success, which is the failure mode this step exists to prevent.

Authentication, because unauthenticated scans under-report. Scan credentials are dedicated accounts held in the secrets vault, restricted to the scanning subnet by logon rights and firewall policy, and excluded from interactive use. Every scan report is checked for authentication success per target, and a host that fell back to unauthenticated becomes a ticket rather than a green result. Container and dependency scanning likewise runs against lockfiles and manifests rather than inferring from tags.

Coverage assurance. Scan targets are reconciled weekly against the inventory of record. Three conditions open a ServiceNow ticket automatically: an inventoried asset with no scan result in the defined interval, an agent that has not checked in for seven days, and a scanned address that is not in the inventory. That last one has found more real problems than the first two, since an unknown responding host is either a shadow system or an inventory error and both matter.

Specialized assets. The firmware lab hosts and the two bench instruments are not actively scanned; active scanning has crashed this class of device for us before. They are documented as excluded, sit on an isolated segment with no CUI at rest, and are covered instead by vendor advisory monitoring against a manually maintained software list, plus a package review at each quarterly offline update.

Maintenance. Monthly review of scan job success rates and skipped targets. Quarterly review of the frequency table against the current architecture, which is what caught the nightly registry rescan gap when we moved from long-lived VMs to short-lived pods. Annual validation that the credentialed scan profile still has the access it needs after operating system hardening changes.

Accepted gaps. SaaS services inside the boundary cannot be scanned by us; we consume the provider's third-party assessment and penetration test summary annually and record that as a different kind of assurance rather than counting it as a scan. Static analysis covers the portal and the two actively developed services but not four legacy internal repositories, which are dependency-scanned only. Both are open POA&M items with dates.

• Vulnerability management standard with the frequency table by asset class and the defined new-vulnerability triggers
• Tenable scan schedule and policy export, plus agent check-in coverage report
• Sample credentialed host scan report showing per-target authentication success
• CI pipeline configuration showing dependency and image scanning, and the nightly deployed-digest rescan job
• Most recent authenticated Burp Suite report for the portal and the pre-release scan tied to an auth-affecting change
• Out-of-cycle scan ticket triggered by a KEV addition, with the plugin feed date and the inventory-scoped target list
• Weekly inventory-to-scan reconciliation output and tickets raised for uncovered or unknown assets