Skip to content

Images, patching and privilege

Source: Azure Compute Standards, sys_kb_id=937eb90b3b650f107f43b50236e45a16.


  1. Monthly patch cycle.
  2. Scan vendor images before entry.
  3. Images and base layers must NOT run as privileged.

Rule 3 applies to container base layers as well as VM images. In Kubernetes terms: securityContext.privileged: true is a violation, and it compounds with the AKS rules on CAP_SYS_ADMIN and read-only root filesystems.

Image type Requirement
Microsoft marketplace, unmodified Qualifies as security-approved automatically
Microsoft marketplace, modified Becomes a custom image — see below
Custom image Periodic security review plus monthly patch and recapture
Any vendor image Scanned before entry

The plugin’s PreToolUse hook enforces an allowlist at hooks/approved-base-images.txt, which currently contains only:

Entry Why
mcr.microsoft.com/ The narrowest reading of “unmodified Microsoft images qualify”
scratch An empty base layer
commented placeholders For the internal registry, once it is confirmed

Confirm the real list with Infra CloudOps and AppSec, then edit that file. Until then, the hook will block common public images such as node:24. The off-switch is PATTERSON_ENGINEERING_HOOKS=off.

Container scanning uses Trivy or Checkmarx (CI/CD Pipeline Standards). Trivy is approved with no approval needed; the Approved Software standard notes “Checkmarx will replace this tool”. Vulnerability scanning across the estate is Qualys, running nightly and creating ServiceNow tickets (Monitoring & Alerting standard).

[TBD: the standard does not state a severity threshold that blocks an image from entry.]


Source of truth: plugins/patterson-engineering/skills/azure-compute-standards/references/images-and-patching.md in the patterson-corp repository.