Container & Docker Security Audit

A read-only registry token (ECR / ACR / GAR / GHCR / Docker Hub / Harbor / Artifactory / Quay) for image pulls and a read-only SCM token (GitHub App, fine-grained PAT, GitLab project token, or Azure DevOps PAT) for Dockerfile reads - both scoped to the minimum permissions and time-limited to the audit window. Images are pulled into an isolated, network-restricted sandbox; we never push images, modify tags, or commit anything. Application source code is never cloned off your infrastructure - only Dockerfiles and build configuration are read.

Trivy, Grype, Clair, Snyk Container, Anchore, Docker Scout, and AWS Inspector for vulnerability and misconfiguration scanning; Hadolint, Dockle, Conftest, Checkov, and KICS for Dockerfile linting and policy; Gitleaks, TruffleHog, and Trivy secret detection for credential leakage; Syft for SBOM generation in CycloneDX and SPDX formats; Cosign and Rekor for signing and transparency-log verification. Findings are benchmarked against the CIS Docker Benchmark, NIST SSDF (SP 800-218), Executive Order 14028, OWASP Container Security Top 10, and SLSA Build levels 1-3.

Those tools produce raw findings; this audit interprets them. A senior security engineer triages every finding for actual exploitability against your stack, removes false positives (e.g. CVEs in unused libraries that are not reachable), combines results across Trivy, Grype, Clair, Snyk Container, Anchore, Docker Scout, Hadolint, Dockle, and Syft with manual review of build pipelines, registry policy, signing posture, and admission control - into a prioritised, line-level remediation plan with a quantified base-image migration roadmap, rather than a 10,000-line raw vulnerability dump.

Yes - that is one of the highest-ROI parts of the audit. We map every base image to its CVE count, support lifecycle, and image size, and identify exactly which workloads benefit most from a swap to Alpine, distroless (gcr.io/distroless), Chainguard Wolfi / Chainguard Images, or scratch. The migration plan includes the exact Dockerfile changes, expected CVE reduction, build-time and runtime impact, and the workloads where staying on Debian / Ubuntu / UBI is the right call (e.g. specific glibc dependencies).

Yes. We generate SBOMs in CycloneDX and SPDX formats with Syft, validate in-toto attestations and SLSA Build level 1-3 provenance, and map your build pipeline to NIST SSDF (SP 800-218) and the supply-chain requirements of US Executive Order 14028. The report tells you exactly what you need to add to be SLSA Build level 2 or 3 compliant for federal or enterprise procurement, and includes Cosign / Sigstore signing rollout and admission-control (Kyverno, OPA/Gatekeeper, Connaisseur, Ratify) deployment plans.

Yes. The audit reviews seccomp profiles, AppArmor / SELinux profiles, dropped Linux capabilities, read-only root filesystem adoption, runAsNonRoot enforcement, gVisor and Kata Containers usage, and runtime detection coverage with Falco, Tracee, and Sysdig. The runtime backlog is delivered alongside the build-time remediations so platform teams can sequence quick Dockerfile wins ahead of cluster-wide Pod Security Admission and admission-controller rollouts.

No. The audit is fully read-only. Image pulls happen at a controlled rate against the registry endpoints you authorise; we never push, retag, delete, or modify policy. Where your CSPM / CWPP / SIEM (Wiz, Orca, Prisma Cloud, Lacework, CrowdStrike, Defender) might flag the read activity we can pre-coordinate with your detection team - but in practice the calls look identical to a normal CI pull.

Typical turnaround is 1-2 business days from the moment read-only access is granted, plus a 45-minute live findings walkthrough at a time that suits your security and platform leads. Larger estates with hundreds of images across multiple registries can take a little longer; we confirm the timeline as soon as we see the scope.