ISM-1700 · September 2026
Vulnerability scanning
Guidelines for security assurance / Security assessments / Vulnerability scanning
Official control wording
A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products.
Applicability
These are ASD’s applicability markings. Select and tailor controls for your system’s risk, classification and operating context with the system owner and authorising officer.
ASD Essential Eight applicability: ML2 · ML3. A profile marking does not establish maturity attainment.
// Latticework implementation guidance · partial coverage
Prove scanner freshness and cadence outside admission labels
Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.
Implementation steps
- Configure vulnerability scanning for the affected services and dependencies at the cadence required by this control. Record the scanner identity, scope and database update process.
- Connect trusted scan results to image digests in the delivery pipeline and preserve raw reports. Treat a declared scan-passed label as a signal to verify against the pipeline evidence.
Evidence to retain
- Keep scheduled job histories, successful and failed runs, coverage inventory, scanner configuration and vulnerability database timestamps.
- Retain raw reports tied to image digests and remediation records. Reconcile missing services and stale scans; a successful admission result does not establish scan cadence.
What the mapped checks can establish
PolicyReports show a declared successful image scan at admission; they do not prove fortnightly cadence or dependency-level scan coverage.
Responsibility boundary
Pipeline team: scanner operation and trustworthy attestations. Workload team: coverage and remediation. Organisation: required cadence, scope and risk acceptance.
The public mapping’s detector allocation is provisional for both managed and self-managed clusters. Agree the responsibility matrix for the engagement; provider inheritance and whole-control ownership require a reviewed system boundary and applicable customer/provider evidence.
Mapped checks to inspect
- kyverno: ism-patch-applications-require-scan-passed
These identifiers are from the pinned public mapping. Kyverno mappings describe the policy configuration you must inspect; they do not mean a policy is installed or enforcing. A manifest scan cannot establish live runtime behaviour. Record the exact tool, policy and framework versions, settings, exclusions and execution time with each result.
Review the mapping and control-specific limitations at revision 07b348a. Supporting mapping excerpts (checks, evidence notes and responsibility allocations) are adapted from Latticework Systems’ public repository under Apache-2.0. ASD’s control wording stays under CC BY 4.0.
Official source
ASD’s ISM OSCAL v2026.09.4 · Original catalogue JSON · Pinned checksums and edition details
Control source identifier: ism-1700. Check the official release before relying on this snapshot for an assessment.
Official control wording and applicability: Australian Signals Directorate, © Commonwealth of Australia 2026. September 2026 ISM, OSCAL v2026.09.4, reproduced under CC BY 4.0. Formatting is adapted for this website.
Latticework Systems’ implementation guidance is our interpretation. Provenance and scope.