ISM-1876 · September 2026
Mitigating known vulnerabilities
Guidelines for system management / System maintenance / Mitigating known vulnerabilities
Official control wording
Patches, updates or other vendor mitigations for vulnerabilities in online services are applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist.
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: ML1 · ML2 · ML3. A profile marking does not establish maturity attainment.
// Latticework implementation guidance · partial coverage
Connect image admission metadata to a real remediation timeline
Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.
Implementation steps
- Inventory affected services and dependencies and record their exposure. Triage vendor advisories and exploitation status against the exact deadline in this control.
- Rebuild and deploy the remediated image, then verify the affected dependency version. Use build-age and build-date gates as supporting guardrails; image age alone does not establish patch inclusion.
Evidence to retain
- Keep advisory release time, severity/exploit assessment, affected component versions, build provenance and verified deployment time.
- Link each PolicyReport to the image digest and actual scan/remediation records. Retain approved exceptions and unpatched exposure explicitly.
What the mapped checks can establish
Admission-time image age is supporting evidence only; criticality, exploit status and the 48-hour remediation clock require vulnerability pipeline data.
Responsibility boundary
Pipeline team: build provenance and deployment timeline. Workload team: dependency remediation and validation. Organisation: prioritisation, exposure decisions and exceptions.
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-image-age-gate
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-1876. 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.