{"id":1127,"date":"2026-02-22T09:25:35","date_gmt":"2026-02-22T09:25:35","guid":{"rendered":"https:\/\/devopsschool.org\/blog\/uncategorized\/container-scanning\/"},"modified":"2026-02-22T09:25:35","modified_gmt":"2026-02-22T09:25:35","slug":"container-scanning","status":"publish","type":"post","link":"https:\/\/devopsschool.org\/blog\/container-scanning\/","title":{"rendered":"What is Container Scanning? Meaning, Examples, Use Cases, and How to use it?"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition<\/h2>\n\n\n\n<p>Container scanning is the automated inspection of container images and running containers to detect vulnerabilities, insecure configurations, secrets, and policy violations before or during runtime.<\/p>\n\n\n\n<p>Analogy: Container scanning is like an airport security scanner for luggage \u2014 quickly checking contents against a set of known threats and rules before passengers board.<\/p>\n\n\n\n<p>Formal technical line: Container scanning analyzes the filesystem layers, package manifests, configuration metadata, and runtime behavior of container images to produce a set of findings that map to CVEs, misconfigurations, and policy violations.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is Container Scanning?<\/h2>\n\n\n\n<p>What it is \/ what it is NOT<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>It is an automated analysis step that inspects container artifacts for known vulnerabilities, misconfigurations, secrets, and compliance issues.<\/li>\n<li>It is NOT a full replacement for runtime defense controls, network segmentation, or host security monitoring.<\/li>\n<li>It is NOT a static magic bullet; scanning outputs require triage, prioritization, and remediation processes.<\/li>\n<\/ul>\n\n\n\n<p>Key properties and constraints<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Source types: image registries, CI-built images, local tarballs, running containers.<\/li>\n<li>Inputs available: layers, package manifests, SBOMs, container configuration (Dockerfile\/HAR), runtime metadata.<\/li>\n<li>Detection types: CVE discovery, configuration checks, policy enforcement, secret detection, license checks.<\/li>\n<li>Limitations: signature-based gaps, unknown zero-day vulnerabilities, false positives\/false negatives, scanning speed trade-offs.<\/li>\n<li>Compliance tie-in: maps findings to standards like CIS Benchmarks, but exact mappings vary by tool.<\/li>\n<li>Scale constraints: scanning frequency vs throughput, registry stress, parallel scan limits, caching requirements.<\/li>\n<li>Automation: integrates into CI\/CD pipelines and registry webhooks to gate images.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Early: incorporated into development pipelines to fail builds or create tickets when critical findings appear.<\/li>\n<li>Middle: registry policy enforcement to block push or mark images untrusted.<\/li>\n<li>Late: pre-deployment gates, admission controllers on Kubernetes, and runtime scanning for drift.<\/li>\n<li>Continuous: scheduled scans for drift and regression, integration with ticketing, and automated remediation where safe.<\/li>\n<\/ul>\n\n\n\n<p>A text-only \u201cdiagram description\u201d readers can visualize<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Developer commits code -&gt; CI builds image -&gt; SBOM and image sent to scanner -&gt; scanner returns findings -&gt; CI gates or allows -&gt; image pushed to registry -&gt; registry-level scan triggers -&gt; admission controller checks image before deploy -&gt; runtime scanner monitors running containers -&gt; alerts and dashboards feed incident workflow.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Container Scanning in one sentence<\/h3>\n\n\n\n<p>Container scanning is the automated inspection of container artifacts to detect known vulnerabilities, misconfigurations, secrets, and policy violations across build, registry, and runtime phases.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Container Scanning vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from Container Scanning<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>Static Application Security Testing \u2014 SAST<\/td>\n<td>Focuses on source code patterns not container artifacts<\/td>\n<td>People think SAST finds runtime CVEs<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>Dynamic Application Security Testing \u2014 DAST<\/td>\n<td>Tests running application behavior, not image contents<\/td>\n<td>Confused with runtime container scanning<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>Software Composition Analysis \u2014 SCA<\/td>\n<td>Analyzes dependencies and licenses; container scanning includes SCA data<\/td>\n<td>SCA is sometimes treated as full container scan<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>Runtime Application Self-Protection \u2014 RASP<\/td>\n<td>Monitors application behavior at runtime, different telemetry<\/td>\n<td>Mistaken for runtime container scanning<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>Host Intrusion Detection \u2014 HIDS<\/td>\n<td>Monitors host OS activity, not container image contents<\/td>\n<td>People conflate HIDS with image scanning<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>Vulnerability Management<\/td>\n<td>Program-level process including scoring and triage, broader than scanning<\/td>\n<td>Scanning is one input to vulnerability management<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>Image Signing<\/td>\n<td>Ensures provenance and integrity, not vulnerability detection<\/td>\n<td>Signing is treated as a security validation instead of scanning<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>Admission Controller<\/td>\n<td>Enforces policies at deploy time, might use scanning data<\/td>\n<td>Controllers use scan results but are not scanners<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>Runtime Scanning<\/td>\n<td>Scans running containers for changes, narrower than build-time image scans<\/td>\n<td>Term used interchangeably with image scanning<\/td>\n<\/tr>\n<tr>\n<td>T10<\/td>\n<td>SBOM Generation<\/td>\n<td>Produces bill of materials, scanning uses SBOM to find issues<\/td>\n<td>SBOM is an output, not the scan itself<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does Container Scanning matter?<\/h2>\n\n\n\n<p>Business impact (revenue, trust, risk)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduces risk of breaches that cause data loss, regulatory fines, and reputational damage.<\/li>\n<li>Prevents high-severity CVEs from reaching production, protecting customers and partners.<\/li>\n<li>Helps meet compliance and audit requirements which can be prerequisites for contracts.<\/li>\n<li>Avoids emergency patching cycles that disrupt planned launches and revenue streams.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact (incident reduction, velocity)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Detects issues earlier in the pipeline, reducing mean time to remediate.<\/li>\n<li>Improves developer velocity when integrated with clear triage and automated fixes.<\/li>\n<li>Reduces incident toil by preventing avoidable runtime compromises.<\/li>\n<li>Empowers shift-left security, enabling teams to fix issues before production.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing (SLIs\/SLOs\/error budgets\/toil\/on-call)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs: time-to-remediate high severity findings, percentage of images scanned pre-deploy.<\/li>\n<li>SLOs: maintain &gt;95% of critical images scanned pre-deploy, or median remediation time under X days.<\/li>\n<li>Error budget: use to balance feature delivery vs remediation effort.<\/li>\n<li>Toil: manual triage of noisy scan outputs increases toil; automation reduces it.<\/li>\n<li>On-call: actionable findings should generate tickets, not pages. Only production-impacting runtime alerts should page.<\/li>\n<\/ul>\n\n\n\n<p>3\u20135 realistic \u201cwhat breaks in production\u201d examples<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Outdated base image contains critical CVE leading to remote code execution on a service.<\/li>\n<li>Secret (API key) baked into image layer leaked, allowing attackers to access downstream services.<\/li>\n<li>Misconfigured container capability granting root-like privileges causing container breakout.<\/li>\n<li>Unapproved package licenses embedded in images causing legal compliance issues.<\/li>\n<li>Image pushed with vulnerable dependency chain causing cascading failures when exploited.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is Container Scanning used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How Container Scanning appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>CI\/CD<\/td>\n<td>Pre-build and post-build image scans and SBOM generation<\/td>\n<td>Scan results, build status, scan duration<\/td>\n<td>Trivy, Snyk, Clair<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>Registry<\/td>\n<td>On-push scans and image metadata storage<\/td>\n<td>Scan events, image tags, policy status<\/td>\n<td>Not publicly stated<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>Kubernetes<\/td>\n<td>Admission controllers enforce scan-based policies<\/td>\n<td>Admission logs, pod create failures<\/td>\n<td>Policy controllers<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>Runtime<\/td>\n<td>Agent-based or agentless runtime scans for drift<\/td>\n<td>Runtime alerts, file integrity logs<\/td>\n<td>Runtime scanners<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>Dev workstation<\/td>\n<td>Local image and dependency scans in developer flow<\/td>\n<td>Local scan reports, SBOMs<\/td>\n<td>CLI scanners<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>Incident response<\/td>\n<td>Forensics on compromised images and layers<\/td>\n<td>Forensic artifacts, timeline events<\/td>\n<td>Forensic tools<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>Observability<\/td>\n<td>Enriched telemetry and dashboards with scan data<\/td>\n<td>Dashboard panels, alerts, trends<\/td>\n<td>SIEMs, APMs<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>Serverless\/PaaS<\/td>\n<td>Scanning deployment bundles and layers<\/td>\n<td>Build logs, deployment failures<\/td>\n<td>Platform-integrated scanners<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>L2: Registry integrations vary by vendor; many registries offer webhook and policy APIs.<\/li>\n<li>L3: Admission controllers use image metadata, signatures, or registry scan results.<\/li>\n<li>L4: Runtime scanning may detect elevated processes, changed binaries, or unexpected network calls.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use Container Scanning?<\/h2>\n\n\n\n<p>When it\u2019s necessary<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You deploy container images to production environments accessible to customers.<\/li>\n<li>Your organization must meet regulatory compliance or contractual security requirements.<\/li>\n<li>You run third-party images or maintain a large dependency surface.<\/li>\n<li>Images run privileged workloads or handle sensitive data.<\/li>\n<\/ul>\n\n\n\n<p>When it\u2019s optional<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Small internal tools with limited blast radius may have relaxed scanning cadence.<\/li>\n<li>Disposable development images used in experiments, provided a safe rollback exists.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not block developer velocity for low-severity, noisy findings without a remediation path.<\/li>\n<li>Avoid running heavy scanners on every single developer local build; use lightweight checks locally and thorough scans in CI.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If images run in production AND expose network services -&gt; enforce pre-deploy scans and registry policies.<\/li>\n<li>If images are internal prototypes AND ephemeral -&gt; run lightweight scans and periodic full scans.<\/li>\n<li>If using managed platform with integrated scanning -&gt; align with platform recommendations before adding duplicate scanning.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder: Beginner -&gt; Intermediate -&gt; Advanced<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: CLI scanner in CI that fails on critical CVEs; SBOM generation enabled.<\/li>\n<li>Intermediate: Registry-level enforcement, triage workflows, periodic scheduled scans, SLIs defined.<\/li>\n<li>Advanced: Runtime scanning and behavioral detection, automated remediation patches, risk-based prioritization, integration with ticketing and SLOs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does Container Scanning work?<\/h2>\n\n\n\n<p>Step-by-step: Components and workflow<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Image build outputs image layers and metadata from the build tool.<\/li>\n<li>SBOM is generated from package manifests and layers.<\/li>\n<li>Scanner retrieves image\/layers and SBOM and matches package\/version data to vulnerability databases.<\/li>\n<li>Scanner applies policy rules for configuration checks, secret detection, license checks, and severity mapping.<\/li>\n<li>Results emitted as structured reports with CVE IDs, severity, file paths, and remediation suggestions.<\/li>\n<li>CI gates, registry policies, or admission controllers consume results to block, warn, or tag images.<\/li>\n<li>Findings feed ticketing systems, dashboards, and may trigger automated remediation flows.<\/li>\n<\/ol>\n\n\n\n<p>Data flow and lifecycle<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Sources: source code, package manifests, container build output, SBOM.<\/li>\n<li>Processing: scanning engines, vulnerability DB mapping, policy engines.<\/li>\n<li>Sinks: registry metadata, CI status, admission controllers, ticketing, dashboards.<\/li>\n<li>Lifecycle: initial scan at build -&gt; registry scan on push -&gt; pre-deploy check -&gt; runtime scan on container start -&gt; scheduled re-scan for new CVEs.<\/li>\n<\/ul>\n\n\n\n<p>Edge cases and failure modes<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>False positives: scanner flags benign items like test keys or local configs.<\/li>\n<li>Incomplete SBOMs: opaque language ecosystems or multi-stage builds hide dependencies.<\/li>\n<li>Rate limits: registries or vulnerability services rate-limit frequent scanning.<\/li>\n<li>Inconsistent baselines: different scanners report different severities for same CVE.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for Container Scanning<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>CI-first pattern\n&#8211; Use case: organizations prioritizing shift-left.\n&#8211; Where to use: greenfield product teams.\n&#8211; Pattern: integrate scanner into CI to block builds on critical findings and produce SBOMs.<\/p>\n<\/li>\n<li>\n<p>Registry-gate pattern\n&#8211; Use case: centralized governance for many teams.\n&#8211; Where to use: large organizations with shared registries.\n&#8211; Pattern: run on-push scans in registry and enforce image policies via tags or approvals.<\/p>\n<\/li>\n<li>\n<p>Admission-control pattern\n&#8211; Use case: Kubernetes clusters needing runtime gating.\n&#8211; Where to use: clusters with strict compliance needs.\n&#8211; Pattern: admission controller queries registry scan results or runs quick checks before allowing pod creation.<\/p>\n<\/li>\n<li>\n<p>Runtime-observability pattern\n&#8211; Use case: high-risk workloads or long-lived services.\n&#8211; Where to use: public-facing services and critical infra.\n&#8211; Pattern: deploy runtime agents that detect changes and correlate with image scan baseline.<\/p>\n<\/li>\n<li>\n<p>Hybrid orchestration pattern\n&#8211; Use case: mixed serverless and containerized workloads.\n&#8211; Where to use: platforms with both FaaS and container services.\n&#8211; Pattern: scan deployment bundles, containers, and integrate findings into a centralized dashboard.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>Scan timeouts<\/td>\n<td>Scans fail intermittently<\/td>\n<td>Network or service throttling<\/td>\n<td>Retry with backoff and caching<\/td>\n<td>Increase in scan duration metrics<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>False positives<\/td>\n<td>High noise in results<\/td>\n<td>Loose detection rules or generic patterns<\/td>\n<td>Tune rules and suppress noise<\/td>\n<td>Spike in low-severity findings<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Missed CVEs<\/td>\n<td>New CVEs not detected<\/td>\n<td>Outdated vulnerability DB<\/td>\n<td>Ensure updater and multiple feeds<\/td>\n<td>New CVE not mapped in results<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>SBOM gaps<\/td>\n<td>Incomplete dependency list<\/td>\n<td>Multi-stage builds hide layers<\/td>\n<td>Generate SBOM at each stage<\/td>\n<td>Discrepancy between SBOM and runtime packages<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>Registry overload<\/td>\n<td>Push latency on image push<\/td>\n<td>Parallel scans on push hooks<\/td>\n<td>Queue scans and offload to workers<\/td>\n<td>Registry push latency increase<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>Unactionable pages<\/td>\n<td>On-call fatigue<\/td>\n<td>Alerts for non-production issues<\/td>\n<td>Route to ticketing or low-priority channel<\/td>\n<td>High alert to incident conversion ratio<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for Container Scanning<\/h2>\n\n\n\n<p>Glossary of 40+ terms (term \u2014 1\u20132 line definition \u2014 why it matters \u2014 common pitfall)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Image layer \u2014 Filesystem delta applied during build \u2014 Identifies where artifacts live \u2014 Pitfall: multi-stage builds hide layers<\/li>\n<li>Container image \u2014 Packaged application and OS artifacts \u2014 Primary scan target \u2014 Pitfall: untagged images complicate tracking<\/li>\n<li>Base image \u2014 Underlying OS layer for builds \u2014 Often the largest source of CVEs \u2014 Pitfall: using latest tag blindly<\/li>\n<li>SBOM \u2014 Software Bill of Materials listing packages \u2014 Improves traceability for vulnerabilities \u2014 Pitfall: incomplete SBOMs from tools<\/li>\n<li>CVE \u2014 Common Vulnerabilities and Exposures identifier \u2014 Standardizes vulnerability references \u2014 Pitfall: not all CVEs have fixes<\/li>\n<li>Vulnerability database \u2014 Repository mapping packages to CVEs \u2014 Core lookup for scanners \u2014 Pitfall: outdated DBs miss new CVEs<\/li>\n<li>Severity \u2014 Ranking of vulnerability impact \u2014 Helps prioritize remediation \u2014 Pitfall: severity doesn&#8217;t equal exploitability<\/li>\n<li>Exploitability \u2014 How easy it is to exploit a CVE \u2014 Critical for risk-based prioritization \u2014 Pitfall: overlooked mitigations reduce risk<\/li>\n<li>SCA \u2014 Software Composition Analysis for dependencies \u2014 Extracts package-level info from images \u2014 Pitfall: language-specific blind spots<\/li>\n<li>Secret scanning \u2014 Detects embedded secrets in images \u2014 Prevents credential leaks \u2014 Pitfall: false positives from public test keys<\/li>\n<li>Misconfiguration checks \u2014 Validates container settings against policies \u2014 Prevents privilege escalations \u2014 Pitfall: overly strict policies block deploys<\/li>\n<li>Admission controller \u2014 Cluster component that enforces policies at pod creation \u2014 Enforces scan results \u2014 Pitfall: misconfigured controllers cause outages<\/li>\n<li>Registry policy \u2014 Rules enforced at registry level on push or pull \u2014 Central control for images \u2014 Pitfall: too-strict blocking impacts teams<\/li>\n<li>Runtime scanning \u2014 Checks running containers for drift and new threats \u2014 Complements build-time scanning \u2014 Pitfall: runtime agents add resource overhead<\/li>\n<li>Image signing \u2014 Cryptographic verification of image provenance \u2014 Prevents tampering \u2014 Pitfall: signing doesn&#8217;t mean vulnerability-free<\/li>\n<li>Notary \u2014 Image signing framework \u2014 Provides verification infrastructure \u2014 Pitfall: operational complexity in key management<\/li>\n<li>Policy engine \u2014 Evaluates scan results against rules \u2014 Automates decisions \u2014 Pitfall: policy sprawl without ownership<\/li>\n<li>False positive \u2014 Flag that is not an actual issue \u2014 Increases triage work \u2014 Pitfall: raising too many false positives causes ignored alerts<\/li>\n<li>False negative \u2014 Missed real issue \u2014 Dangerous if trusted blindly \u2014 Pitfall: over-reliance on single scanner<\/li>\n<li>Forensics \u2014 Post-incident artifact analysis \u2014 Determines impact of compromised images \u2014 Pitfall: lack of preserved artifacts<\/li>\n<li>Drift \u2014 Difference between image baseline and running container \u2014 Indicates compromise or change \u2014 Pitfall: lack of drift detection leads to blind spots<\/li>\n<li>Image provenance \u2014 Metadata of who built and signed an image \u2014 Critical for auditing \u2014 Pitfall: missing provenance in CI pipelines<\/li>\n<li>Meta-data tags \u2014 Labels and annotations on images \u2014 Help policy decisions \u2014 Pitfall: inconsistent tagging schemes<\/li>\n<li>Vulnerability score \u2014 Numeric measure of CVE severity like CVSS \u2014 Aids triage and prioritization \u2014 Pitfall: scores can be misinterpreted<\/li>\n<li>Remediation guidance \u2014 Suggested fixes for findings \u2014 Accelerates mitigation \u2014 Pitfall: automated patches may break apps<\/li>\n<li>Automated remediation \u2014 Programmatic fixes based on findings \u2014 Reduces toil \u2014 Pitfall: risk of breaking changes if not tested<\/li>\n<li>Dependency scanning \u2014 Checks package dependencies inside images \u2014 Finds transitive vulnerabilities \u2014 Pitfall: large graphs cause overload<\/li>\n<li>License check \u2014 Detects problematic open-source licenses \u2014 Prevents legal exposure \u2014 Pitfall: false alarms on license expressions<\/li>\n<li>SBOM attestation \u2014 Verifies SBOM integrity and origin \u2014 Improves trust in supply chain \u2014 Pitfall: attestation approaches vary<\/li>\n<li>CWE \u2014 Common Weakness Enumeration for bug classes \u2014 For mapping systemic issues \u2014 Pitfall: CWE mapping can be generic<\/li>\n<li>CI\/CD pipeline \u2014 Automated build\/test\/deploy flow \u2014 Natural place for scanning \u2014 Pitfall: long scans slow pipelines<\/li>\n<li>Remediation ticketing \u2014 Automated creation of work items for fixes \u2014 Ensures ownership \u2014 Pitfall: noise without prioritization<\/li>\n<li>Quiet period \u2014 Delay between scan and block to reduce flakiness \u2014 Helps avoid build churn \u2014 Pitfall: delays reduce immediate safety<\/li>\n<li>Rate limiting \u2014 Protects registries and scanner APIs \u2014 Prevents outages \u2014 Pitfall: too aggressive limits delay scans<\/li>\n<li>Threat intel feed \u2014 External indicators that correlate with findings \u2014 Enriches prioritization \u2014 Pitfall: noisy feeds increase false positives<\/li>\n<li>Container runtime \u2014 Engine that runs containers (runc, containerd) \u2014 Runtime constraints affect security \u2014 Pitfall: runtime bugs can enable escapes<\/li>\n<li>Capability drop \u2014 Removal of Linux capabilities from containers \u2014 Reduces attack surface \u2014 Pitfall: breaking apps that rely on dropped capabilities<\/li>\n<li>Immutable infrastructure \u2014 Philosophy of replacing rather than patching running units \u2014 Aligns with image scanning workflows \u2014 Pitfall: expensive for stateful apps<\/li>\n<li>Supply chain security \u2014 Controls across build-to-deploy process \u2014 Scanning is a key part \u2014 Pitfall: focusing only on images and not build systems<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure Container Scanning (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Percent images scanned pre-deploy<\/td>\n<td>Coverage of pre-deploy scanning<\/td>\n<td>Count images scanned \/ images deployed<\/td>\n<td>95%<\/td>\n<td>Tagging inconsistencies<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Time to remediate critical CVEs<\/td>\n<td>Speed of fixing high-risk issues<\/td>\n<td>Median time from detection to fix<\/td>\n<td>14 days<\/td>\n<td>Prioritization variance<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>Critical findings per image<\/td>\n<td>Risk density in images<\/td>\n<td>Number of critical findings per image<\/td>\n<td>&lt;= 0.1<\/td>\n<td>False positives inflate metric<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>Scan success rate<\/td>\n<td>Reliability of scanning pipeline<\/td>\n<td>Successful scans \/ total attempts<\/td>\n<td>99%<\/td>\n<td>Timeouts and rate limits<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>Scan duration<\/td>\n<td>Operational cost and latency<\/td>\n<td>Median scan time per image<\/td>\n<td>&lt; 2 minutes in CI<\/td>\n<td>Deep scans can be longer<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>Registry policy enforcement rate<\/td>\n<td>Effectiveness of registry gating<\/td>\n<td>Blocked images \/ pushed images<\/td>\n<td>100% for critical blocks<\/td>\n<td>Overblocking impacts delivery<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>Runtime drift detections<\/td>\n<td>Detection of unauthorized changes<\/td>\n<td>Drift alerts \/ runtime instances<\/td>\n<td>0 for critical drift<\/td>\n<td>Agent coverage affects data<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>SBOM coverage<\/td>\n<td>Proportion of images with SBOMs<\/td>\n<td>Images with SBOM \/ total images<\/td>\n<td>100% for prod images<\/td>\n<td>Tooling varies by language<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>False positive rate<\/td>\n<td>Noise from scanner outputs<\/td>\n<td>FP findings \/ total findings<\/td>\n<td>&lt; 10%<\/td>\n<td>Subjective triage affects FP labeling<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Alert to incident conversion rate<\/td>\n<td>Actionability of alerts<\/td>\n<td>Incidents opened \/ alerts fired<\/td>\n<td>Low for non-prod alerts<\/td>\n<td>Poor routing inflates paging<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>M2: Starting target depends on team size and risk profile; 14 days is a pragmatic baseline for critical CVEs, adjust per risk.<\/li>\n<li>M4: Include retries and backoff accounting to avoid penalizing transient failures.<\/li>\n<li>M9: Establish a process for labeling and learning to reduce false positives over time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure Container Scanning<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Trivy<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Container Scanning: Vulnerabilities, misconfigurations, SBOM generation, secret scanning.<\/li>\n<li>Best-fit environment: CI pipelines, local developer checks, registries.<\/li>\n<li>Setup outline:<\/li>\n<li>Install CLI or run as container in CI.<\/li>\n<li>Configure vulnerability DB update cadence.<\/li>\n<li>Generate SBOM and export JSON reports.<\/li>\n<li>Integrate with CI gate to fail builds based on policy.<\/li>\n<li>Strengths:<\/li>\n<li>Fast scans and multi-check capabilities.<\/li>\n<li>Easy to run locally and in CI.<\/li>\n<li>Limitations:<\/li>\n<li>DB update cadence matters.<\/li>\n<li>Potential for false positives on heuristics.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Snyk<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Container Scanning: Vulnerabilities in dependencies and images, license issues, fix suggestions.<\/li>\n<li>Best-fit environment: Developer-centric teams with subscription-based tooling.<\/li>\n<li>Setup outline:<\/li>\n<li>Connect to CI and container registry.<\/li>\n<li>Configure policies and alerts.<\/li>\n<li>Use developer plugin or IDE integration.<\/li>\n<li>Strengths:<\/li>\n<li>Good developer UX and suggested fixes.<\/li>\n<li>Integrates across code, containers, and infra.<\/li>\n<li>Limitations:<\/li>\n<li>Commercial licensing for advanced features.<\/li>\n<li>Varying scan depth by plan.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Clair<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Container Scanning: Image layer analysis and CVE mapping.<\/li>\n<li>Best-fit environment: Registry-level scanning integrations.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy as service and connect to registry.<\/li>\n<li>Schedule scans on push hooks.<\/li>\n<li>Consume JSON findings for policy engines.<\/li>\n<li>Strengths:<\/li>\n<li>Designed for registry integration.<\/li>\n<li>Open architecture for custom pipelines.<\/li>\n<li>Limitations:<\/li>\n<li>Requires operational maintenance.<\/li>\n<li>Integrations may need custom glue.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Notary\/Signatory (Image signing)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Container Scanning: Image provenance and integrity assertions.<\/li>\n<li>Best-fit environment: Organizations with strict supply-chain controls.<\/li>\n<li>Setup outline:<\/li>\n<li>Establish signing keys and workflows.<\/li>\n<li>Integrate signing into CI post-build.<\/li>\n<li>Configure verification in registries and admission controllers.<\/li>\n<li>Strengths:<\/li>\n<li>Strong provenance guarantees.<\/li>\n<li>Limitations:<\/li>\n<li>Key management and operational overhead.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Runtime scanner (generic)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Container Scanning: Drift, file integrity, unexpected processes in running containers.<\/li>\n<li>Best-fit environment: High-risk runtime workloads.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy lightweight agents.<\/li>\n<li>Define baseline from image scan.<\/li>\n<li>Alert on deviations.<\/li>\n<li>Strengths:<\/li>\n<li>Detects post-deploy compromises.<\/li>\n<li>Limitations:<\/li>\n<li>Agent overhead and coverage limitations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for Container Scanning<\/h3>\n\n\n\n<p>Executive dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Percentage of production images scanned pre-deploy (trend).<\/li>\n<li>Number of critical findings across prod per week.<\/li>\n<li>Mean time to remediate critical findings.<\/li>\n<li>Top affected services by risk score.<\/li>\n<li>Why: Provides leadership visibility into supply chain risk and remediation capacity.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Active runtime drift detections and their severity.<\/li>\n<li>Recent failed admission controller checks blocking deploys.<\/li>\n<li>Alerts triggered in last 6 hours grouped by service.<\/li>\n<li>Why: Helps responders quickly triage potentially compromised or blocked deployments.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Last scan logs and error traces per pipeline.<\/li>\n<li>Scan duration and queue depth.<\/li>\n<li>Per-repository SCAN success rate and previous findings.<\/li>\n<li>SBOM vs runtime package delta visualizer.<\/li>\n<li>Why: Helps engineers investigate scan failures and discrepancies.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What should page vs ticket:<\/li>\n<li>Page: Runtime drift detection indicating possible compromise, production outage caused by image policy enforcement.<\/li>\n<li>Ticket: New critical scan finding for a non-production image, registry scan failure for a single non-prod repo.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>Allocate error budget usage for delayed remediation windows. If remediation burn rate exceeds 2x expected, trigger exec review.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Deduplicate findings across image tags and layers.<\/li>\n<li>Group alerts by service and criticality.<\/li>\n<li>Suppress low-severity or acknowledged findings via expiration-based suppression.<\/li>\n<li>Use risk-scoring to prioritize actionable items.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Inventory of registries and images.\n&#8211; Defined severity and policy mapping for vulnerabilities.\n&#8211; CI\/CD pipeline access and ability to add build steps.\n&#8211; Ownership for remediation triage.\n&#8211; Baseline SBOM generation tooling.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Define what artifacts will be scanned and when.\n&#8211; Insert SBOM generation at build time.\n&#8211; Configure scan result exporters to central storage and ticketing.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Configure scanners to produce structured output (JSON, SARIF).\n&#8211; Store results in a searchable store or vulnerability management database.\n&#8211; Retain historical scan data for audits and trend analysis.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define SLOs like percent images scanned pre-deploy and median remediation time for critical CVEs.\n&#8211; Tie SLOs to operational processes and runbooks.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Build executive, on-call, and debug dashboards.\n&#8211; Include trend panels, top offenders, and per-repo drilldowns.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Define alert rules by severity and environment.\n&#8211; Route critical runtime alerts to on-call and non-critical findings to ticket queues.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Create runbooks for remediation of common findings.\n&#8211; Automate trivial remediations where safe (e.g., rebuild with patched base image) with staged rollout.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Run game days simulating an image with a critical CVE to validate detection, alerts, and remediation.\n&#8211; Validate admission controller blocking does not cause cluster instability.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Track false positive rates and reduce noise.\n&#8211; Update vulnerability feeds, tune policies, and provide developer training.<\/p>\n\n\n\n<p>Checklists<\/p>\n\n\n\n<p>Pre-production checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CI has SBOM generation enabled.<\/li>\n<li>CI pipelines call scanner with policy thresholds.<\/li>\n<li>Scan outputs are stored centrally.<\/li>\n<li>Tests to ensure scans do not block ephemeral dev workflows.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Registry scan on-push configured.<\/li>\n<li>Admission controller enforcement tested in staging.<\/li>\n<li>Runtime agents deployed where needed.<\/li>\n<li>Ticketing and triage workflows in place.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to Container Scanning<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identify affected images and tags.<\/li>\n<li>Freeze image promotion and isolate affected services.<\/li>\n<li>Collect SBOMs, layer digests, and runtime artifacts.<\/li>\n<li>Rotate any exposed credentials and secrets.<\/li>\n<li>Plan and execute patch\/rebuild, then redeploy and validate.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of Container Scanning<\/h2>\n\n\n\n<p>1) Enterprise compliance attestation\n&#8211; Context: Company must pass security audits for customer contracts.\n&#8211; Problem: Lack of evidence for image compliance.\n&#8211; Why scanning helps: Produces auditable scans and SBOMs mapped to controls.\n&#8211; What to measure: SBOM coverage, policy enforcement rate.\n&#8211; Typical tools: Enterprise scanners, SBOM generators.<\/p>\n\n\n\n<p>2) Developer shift-left workflow\n&#8211; Context: Teams commit code and expect fast feedback.\n&#8211; Problem: Vulnerabilities discovered late in pipeline.\n&#8211; Why scanning helps: Early detection in CI reduces rework.\n&#8211; What to measure: Percent images scanned pre-deploy, scan duration.\n&#8211; Typical tools: CLI scanners integrated into CI.<\/p>\n\n\n\n<p>3) Registry governance\n&#8211; Context: Many teams pushing images to central registry.\n&#8211; Problem: Inconsistent policies and risky images present.\n&#8211; Why scanning helps: On-push enforcement standardizes compliance.\n&#8211; What to measure: Block rate, number of flagged images.\n&#8211; Typical tools: Registry scanners and policy engines.<\/p>\n\n\n\n<p>4) Runtime compromise detection\n&#8211; Context: Customer-facing services at risk of exploitation.\n&#8211; Problem: Image-level checks miss runtime changes.\n&#8211; Why scanning helps: Baselines from scans enable drift detection.\n&#8211; What to measure: Runtime drift detections, time to investigate.\n&#8211; Typical tools: Runtime agents plus image scanners.<\/p>\n\n\n\n<p>5) Third-party image vetting\n&#8211; Context: Teams use public images for quick start.\n&#8211; Problem: Unknown vulnerabilities in upstream images.\n&#8211; Why scanning helps: Identifies risky base images before use.\n&#8211; What to measure: Findings per third-party image, license issues.\n&#8211; Typical tools: Scanners with SCA features.<\/p>\n\n\n\n<p>6) Automated patching workflow\n&#8211; Context: High-volume microservices needing low toil.\n&#8211; Problem: Manual patching overhead.\n&#8211; Why scanning helps: Detects vulnerable images and triggers rebuild\/pull requests.\n&#8211; What to measure: Automated remediation success rate.\n&#8211; Typical tools: Vulnerability management and CI automation.<\/p>\n\n\n\n<p>7) Incident forensics\n&#8211; Context: Investigating a compromise.\n&#8211; Problem: Determining which images were affected.\n&#8211; Why scanning helps: Historical scan data and SBOMs support root cause.\n&#8211; What to measure: Time to evidence collection.\n&#8211; Typical tools: Forensic analysis plus scan archives.<\/p>\n\n\n\n<p>8) License and IP risk control\n&#8211; Context: Legal needs to validate OSS usage.\n&#8211; Problem: Unexpected license obligations.\n&#8211; Why scanning helps: License scanning finds problematic dependencies.\n&#8211; What to measure: Number of images with flagged licenses.\n&#8211; Typical tools: SCA-focused scanners.<\/p>\n\n\n\n<p>9) Edge\/IoT image vetting\n&#8211; Context: Pushing images to constrained devices.\n&#8211; Problem: Vulnerabilities lead to widespread compromise.\n&#8211; Why scanning helps: Vet images before device rollouts.\n&#8211; What to measure: Critical findings on rollout images.\n&#8211; Typical tools: Lightweight scanners and SBOMs.<\/p>\n\n\n\n<p>10) Serverless packaging checks\n&#8211; Context: Functions packaged as container images.\n&#8211; Problem: Serverless code inherits vulnerable dependencies.\n&#8211; Why scanning helps: Scans function bundles similarly to images.\n&#8211; What to measure: Findings per function package.\n&#8211; Typical tools: CI scanners and platform-integrated checks.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes admission control blocking vulnerable images<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Multi-tenant Kubernetes cluster with many developer teams.\n<strong>Goal:<\/strong> Prevent deployments of images with critical CVEs.\n<strong>Why Container Scanning matters here:<\/strong> Blocks high-risk images before they cause production incidents.\n<strong>Architecture \/ workflow:<\/strong> CI builds image -&gt; Scanner produces result and SBOM -&gt; Registry stores scan metadata -&gt; Admission controller queries registry on Pod creation -&gt; Block if critical.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Integrate scanner in CI and generate SBOM.<\/li>\n<li>Configure registry on-push scans to store metadata.<\/li>\n<li>Deploy admission controller configured to call registry API.<\/li>\n<li>Define policy thresholds and exemptions.<\/li>\n<li>Test in staging with simulated vulnerable images.\n<strong>What to measure:<\/strong> Percent images scanned pre-deploy, admission controller block rate, time to unblock false positives.\n<strong>Tools to use and why:<\/strong> CI scanner for SBOM, registry scanner, admission controller for enforcement.\n<strong>Common pitfalls:<\/strong> Admission controller misconfig causing deploy outages, stale registry metadata.\n<strong>Validation:<\/strong> Deploy simulated vulnerable image and verify blocked by controller; confirm benign images pass.\n<strong>Outcome:<\/strong> Reduced deployment of critical-vulnerable images; clear failure mode and remediation pathway.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless PaaS function packaged as container image<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Organization using managed PaaS where functions are packaged as OCI images.\n<strong>Goal:<\/strong> Ensure serverless images do not contain critical vulnerabilities.\n<strong>Why Container Scanning matters here:<\/strong> Functions run with network access and may process sensitive data.\n<strong>Architecture \/ workflow:<\/strong> Local build -&gt; CI scan -&gt; Platform registry receives image -&gt; Platform deploys if scan passes.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Add scanner to CI to run image scans and SBOM generation.<\/li>\n<li>Configure platform integration to reject images without SBOM or with critical findings.<\/li>\n<li>Provide dev documentation for remediation steps.<\/li>\n<li>Schedule periodic rescan after new CVE disclosures.\n<strong>What to measure:<\/strong> SBOM coverage for functions, average remediation time for findings in functions.\n<strong>Tools to use and why:<\/strong> CLI scanner in CI and platform&#8217;s registry scan integration.\n<strong>Common pitfalls:<\/strong> Platform constraints on image size or scan time; lack of runtime agent for transient functions.\n<strong>Validation:<\/strong> Create a function with a known vulnerable dependency and ensure pipeline blocks.\n<strong>Outcome:<\/strong> Serverless functions meet baseline security requirements before runtime.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident-response postmortem of leaked secret in image<\/h3>\n\n\n\n<p><strong>Context:<\/strong> An API key leaked through a container image pushed to public registry.\n<strong>Goal:<\/strong> Determine scope and rotate compromised secrets.\n<strong>Why Container Scanning matters here:<\/strong> Secret scanning can detect embedded secrets and trigger rotation.\n<strong>Architecture \/ workflow:<\/strong> Scan detected secret during scheduled registry scan -&gt; Incident triage -&gt; Revoke and rotate key -&gt; Rebuild images without secrets -&gt; Update security policy.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Run exhaustive secret scan across registry.<\/li>\n<li>Identify images and tags containing leaked secret.<\/li>\n<li>Revoke leaked credentials and issue new ones.<\/li>\n<li>Rebuild with secret injection out-of-band or via runtime secrets.<\/li>\n<li>Notify stakeholders and record in postmortem.\n<strong>What to measure:<\/strong> Time to detect leak, time to rotate secret, number of affected images.\n<strong>Tools to use and why:<\/strong> Secret scanning tool in registry and CI; ticketing for remediation.\n<strong>Common pitfalls:<\/strong> Overtrusting public registry deletions; missing cached image copies.\n<strong>Validation:<\/strong> Confirm no remaining image contains secret via rescan.\n<strong>Outcome:<\/strong> Secrets rotated, remediation tracked, policy updated to prevent future leaks.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost vs performance trade-off in scan cadence<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Large monorepo and hundreds of images; full scans consume resources.\n<strong>Goal:<\/strong> Balance scan thoroughness with cost and build latency.\n<strong>Why Container Scanning matters here:<\/strong> Frequent full scans increase CI cost; infrequent scans increase risk.\n<strong>Architecture \/ workflow:<\/strong> Lightweight fast scans in CI, scheduled full deep scans off-peak with prioritization.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Configure CI to run fast vulnerability checks and SBOM generation.<\/li>\n<li>Schedule full deep scans nightly with caching and parallelism.<\/li>\n<li>Use risk-scoring to prioritize full scans for high-value images.<\/li>\n<li>Monitor scan queue and optimize concurrency.\n<strong>What to measure:<\/strong> Cost per scan, scan backlog, detection latency for critical CVEs.\n<strong>Tools to use and why:<\/strong> Fast CLI scanners in CI, scalable scanner service for deep scans.\n<strong>Common pitfalls:<\/strong> Missing critical CVEs due to delayed deep scans; over-indexing cost metrics.\n<strong>Validation:<\/strong> Compare findings discovered by fast vs deep scans and tune cadence.\n<strong>Outcome:<\/strong> Optimized cadence minimizing cost while preserving detection for high-risk images.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<p>List of mistakes with Symptom -&gt; Root cause -&gt; Fix (15\u201325 items, including 5 observability pitfalls)<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Symptom: Excessive low-severity alerts -&gt; Root cause: Default scanner rules not tuned -&gt; Fix: Tune rules, add suppression with expiry.<\/li>\n<li>Symptom: Critical CVE missed -&gt; Root cause: Vulnerability DB out of date -&gt; Fix: Ensure updater service is running and use redundant feeds.<\/li>\n<li>Symptom: CI build slowed significantly -&gt; Root cause: Full deep scans in every build -&gt; Fix: Use lightweight pre-checks and offload deep scans.<\/li>\n<li>Symptom: Admission controller blocking production deploys -&gt; Root cause: Misconfigured policy or stale scan metadata -&gt; Fix: Create emergency bypass and fix policy logic.<\/li>\n<li>Symptom: On-call overloaded with non-actionable pages -&gt; Root cause: Misrouted alerts for non-prod findings -&gt; Fix: Route to ticketing for non-prod; only page on runtime incidents.<\/li>\n<li>Symptom: High false positive rate -&gt; Root cause: Heuristic-based secret checks and generic patterns -&gt; Fix: Add tokenized allowlists and context-aware checks.<\/li>\n<li>Symptom: SBOMs missing dependencies -&gt; Root cause: Multi-stage build layers not captured -&gt; Fix: Generate SBOM per stage and stitch them.<\/li>\n<li>Symptom: Registry push latency spikes -&gt; Root cause: Scans occurring synchronously on push -&gt; Fix: Queue scans asynchronously and mark image as pending.<\/li>\n<li>Symptom: Tickets piling without ownership -&gt; Root cause: No triage owner defined -&gt; Fix: Assign ownership and SLAs for remediation.<\/li>\n<li>Symptom: Scans fail intermittently -&gt; Root cause: Rate limits or network blips -&gt; Fix: Implement retries with exponential backoff and circuit breakers.<\/li>\n<li>Observability pitfall: No historic scan data -&gt; Root cause: Only storing latest result -&gt; Fix: Archive scan results for trend analysis.<\/li>\n<li>Observability pitfall: Lack of per-service dashboards -&gt; Root cause: Centralized aggregated view only -&gt; Fix: Create per-service drilldowns for ownership.<\/li>\n<li>Observability pitfall: Scan logs not correlated with builds -&gt; Root cause: Missing trace IDs in scan output -&gt; Fix: Stamp scans with CI\/build identifiers.<\/li>\n<li>Observability pitfall: No correlation between runtime alerts and image baseline -&gt; Root cause: No unique image digest linking -&gt; Fix: Enforce image digest usage and metadata propagation.<\/li>\n<li>Symptom: Secret leaks continue -&gt; Root cause: Secrets baked into images via build-time variables -&gt; Fix: Move secrets to runtime secret stores and CI injection.<\/li>\n<li>Symptom: Automated fixes breaking apps -&gt; Root cause: Blind auto-patching without compatibility tests -&gt; Fix: Automate PRs and run CI test suites before merge.<\/li>\n<li>Symptom: High licensing risk flagged -&gt; Root cause: Transitive dependencies with problematic licenses -&gt; Fix: Restrict allowed licenses and use curated base images.<\/li>\n<li>Symptom: Scanners disagree on severity -&gt; Root cause: Different DB mappings and score systems -&gt; Fix: Use a canonical scoring or risk-scoring aggregation.<\/li>\n<li>Symptom: Image provenance unclear -&gt; Root cause: Untracked CI builders and unsigned images -&gt; Fix: Enable image signing and provenance metadata.<\/li>\n<li>Symptom: Agents cause runtime overhead -&gt; Root cause: Heavy-weight runtime agents on constrained nodes -&gt; Fix: Use sampling or lightweight agents and limit to high-risk workloads.<\/li>\n<li>Symptom: Duplicate findings across tags -&gt; Root cause: Per-tag scans without layer deduplication -&gt; Fix: Deduplicate by content digest and coalesce findings.<\/li>\n<li>Symptom: Incomplete remediation data -&gt; Root cause: No remediation guidance in reports -&gt; Fix: Choose tools that provide fix paths or automated PRs.<\/li>\n<li>Symptom: Poor scan coverage in edge devices -&gt; Root cause: Resource limitations or network constraints -&gt; Fix: Pre-validate images before rollout and use cached results.<\/li>\n<li>Symptom: Unclear ownership in postmortems -&gt; Root cause: No documented remediation workflow -&gt; Fix: Add security lead to runbooks with clear RACI.<\/li>\n<li>Symptom: Performance regression after patch -&gt; Root cause: No performance testing for automated fixes -&gt; Fix: Include perf tests in remediation pipelines.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Security owns global policy and vulnerability program.<\/li>\n<li>Teams own remediation for their services and remain responsible for triage.<\/li>\n<li>Define on-call rotations for runtime alerts; scan findings route to engineering tickets unless critical runtime impact.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbooks: step-by-step remediation for common findings.<\/li>\n<li>Playbooks: higher-level incident response steps for complex compromises.<\/li>\n<li>Keep both versioned and accessible in the operations repository.<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments (canary\/rollback)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use canary releases for patched images to detect regressions.<\/li>\n<li>Automate rollback triggers for performance regressions or critical errors.<\/li>\n<li>Apply progressive rollout tied to SLO monitoring.<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Automate low-risk remediations via PRs and CI validation.<\/li>\n<li>Use deduplication and risk-scoring to reduce noise.<\/li>\n<li>Automate SBOM generation and metadata propagation.<\/li>\n<\/ul>\n\n\n\n<p>Security basics<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Remove secrets from images; use runtime secret stores.<\/li>\n<li>Pin base images and control update windows.<\/li>\n<li>Enforce least privilege for containers (drop capabilities).<\/li>\n<li>Sign images and verify at deploy time.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Triage new critical findings and assign owners.<\/li>\n<li>Monthly: Review SBOM coverage and adjust risk scoring.<\/li>\n<li>Quarterly: Audit registry policies and validate admission controllers in staging.<\/li>\n<\/ul>\n\n\n\n<p>What to review in postmortems related to Container Scanning<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Detection latency: when was issue introduced vs detected.<\/li>\n<li>Efficacy of scans: false negatives or positives.<\/li>\n<li>Automation effectiveness: did remediation automation help or hinder.<\/li>\n<li>Policy impact: did enforcement cause unexpected downtime.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for Container Scanning (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>CLI scanner<\/td>\n<td>Local and CI image scanning<\/td>\n<td>CI systems, SBOM outputs<\/td>\n<td>Fast and developer friendly<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>Registry scanner<\/td>\n<td>On-push image scanning<\/td>\n<td>Container registries, webhooks<\/td>\n<td>Centralized enforcement<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>Admission controller<\/td>\n<td>Pre-deploy policy enforcement<\/td>\n<td>Kubernetes API, registry<\/td>\n<td>Blocks or warns at pod create<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>Runtime agent<\/td>\n<td>Monitors running containers<\/td>\n<td>SIEM, APM<\/td>\n<td>Detects drift and behavior<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>SBOM generator<\/td>\n<td>Produces bill of materials<\/td>\n<td>Build tools, artifact stores<\/td>\n<td>Required for supply chain audits<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>Vulnerability DB<\/td>\n<td>Maps packages to CVEs<\/td>\n<td>Scanners, risk engine<\/td>\n<td>Keep updated frequently<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Ticketing integration<\/td>\n<td>Creates remediation work items<\/td>\n<td>Issue trackers, PagerDuty<\/td>\n<td>Automates ownership handoff<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>Image signing<\/td>\n<td>Signs images for provenance<\/td>\n<td>CI, registry, admission<\/td>\n<td>Requires key management<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>Policy engine<\/td>\n<td>Evaluates scan results<\/td>\n<td>CI, registry, admission<\/td>\n<td>Centralizes policy decisions<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>Forensics tools<\/td>\n<td>Analyzes compromised images<\/td>\n<td>Logs, artifact repos<\/td>\n<td>Useful post-incident<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is the difference between image scanning and runtime scanning?<\/h3>\n\n\n\n<p>Image scanning inspects the image artifact for known issues; runtime scanning observes running containers for drift and suspicious behavior.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can container scanning prevent zero-day exploits?<\/h3>\n\n\n\n<p>No; scanning is effective for known vulnerabilities. Zero-day protection requires defense-in-depth and runtime detection.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How often should I scan images?<\/h3>\n\n\n\n<p>Scan at build time, on-push to registry, and schedule periodic rescans; frequency depends on risk and resource constraints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do I need SBOMs for container scanning?<\/h3>\n\n\n\n<p>SBOMs are highly recommended as they improve visibility and tie package versions to vulnerabilities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should scanning block deployments?<\/h3>\n\n\n\n<p>Block only for critical, high-confidence findings; route non-critical findings to tickets to preserve developer velocity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I reduce scan noise?<\/h3>\n\n\n\n<p>Tune rules, deduplicate findings, suppress acknowledged issues with expiry, and implement risk-scoring.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is image signing enough for security?<\/h3>\n\n\n\n<p>No; signing verifies provenance but does not check for vulnerabilities or misconfiguration.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I handle secrets in images?<\/h3>\n\n\n\n<p>Remove secrets from images and use runtime secret stores or injection mechanisms in CI\/CD.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What metrics matter most for SREs?<\/h3>\n\n\n\n<p>Percent images scanned pre-deploy, time to remediate critical findings, and runtime drift detection rate.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can automated remediation break apps?<\/h3>\n\n\n\n<p>Yes; always validate automated fixes via CI tests and canary rollouts before full deployment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I prioritize which vulnerabilities to fix?<\/h3>\n\n\n\n<p>Prioritize by exploitability, impact, exposure, and service criticality using risk-scoring.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Are free scanners good enough?<\/h3>\n\n\n\n<p>Free scanners are useful for basic coverage, but enterprise features like scale, policy management, and remediation workflows may require paid tools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to handle multi-stage builds for scanning?<\/h3>\n\n\n\n<p>Generate SBOMs for each stage and ensure scanners examine final artifact and intermediate stages as needed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is the role of admission controllers?<\/h3>\n\n\n\n<p>They enforce policies at deploy time using scan results and attestation to block risky images.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to integrate scanning with incident response?<\/h3>\n\n\n\n<p>Ensure scan data and SBOMs are archived and available to incident responders as part of the evidence set.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can serverless functions be scanned?<\/h3>\n\n\n\n<p>Yes, when packaged as images or deployment bundles; scan CI artifacts and function packages.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to manage vulnerability DB updates?<\/h3>\n\n\n\n<p>Automate updater processes and consider multiple feeds for redundancy.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does scanning find secrets reliably?<\/h3>\n\n\n\n<p>Secret scanning helps but is imperfect; use multiple mechanisms and avoid baking secrets into images.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Container scanning is a foundational control in modern cloud-native security and SRE practice. It reduces risk by detecting known vulnerabilities, misconfigurations, and secrets across build, registry, and runtime phases. To be effective it must be integrated into CI\/CD, registry policies, admission control, and runtime observability with clear ownership, triage workflows, and thoughtful automation.<\/p>\n\n\n\n<p>Next 7 days plan (practical checklist)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Inventory registries and list top-10 production images.<\/li>\n<li>Day 2: Add lightweight scanner to CI for pre-deploy checks and SBOM generation.<\/li>\n<li>Day 3: Configure scheduled deep scans for production images overnight.<\/li>\n<li>Day 4: Create a triage playbook and assign remediation owners.<\/li>\n<li>Day 5: Build basic dashboards for percent scanned and critical findings.<\/li>\n<li>Day 6: Test admission controller logic in staging with simulated vulnerable images.<\/li>\n<li>Day 7: Run a mini-game day simulating a secret leakage and validate runbooks.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 Container Scanning Keyword Cluster (SEO)<\/h2>\n\n\n\n<p>Primary keywords<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>container scanning<\/li>\n<li>image scanning<\/li>\n<li>container vulnerability scanning<\/li>\n<li>SBOM for containers<\/li>\n<li>CI container scanning<\/li>\n<\/ul>\n\n\n\n<p>Secondary keywords<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>registry image scan<\/li>\n<li>runtime container scanning<\/li>\n<li>admission controller vulnerability check<\/li>\n<li>container image SBOM<\/li>\n<li>secret scanning in images<\/li>\n<\/ul>\n\n\n\n<p>Long-tail questions<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>how to scan container images in CI<\/li>\n<li>best container scanning tools for kubernetes<\/li>\n<li>how to automate container vulnerability remediation<\/li>\n<li>what is SBOM and why it matters for containers<\/li>\n<li>how to prevent secrets in docker images<\/li>\n<li>how to integrate image scanning with registry policies<\/li>\n<li>how to measure container scanning effectiveness<\/li>\n<li>how to reduce false positives in container scanners<\/li>\n<li>how to scan serverless functions packaged as images<\/li>\n<li>how to detect runtime drift in containers<\/li>\n<\/ul>\n\n\n\n<p>Related terminology<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>software composition analysis<\/li>\n<li>image signing and provenance<\/li>\n<li>admission controller enforcement<\/li>\n<li>vulnerability management for containers<\/li>\n<li>CVE mapping for container packages<\/li>\n<li>scan cadence and performance<\/li>\n<li>SBOM attestation<\/li>\n<li>risk scoring for vulnerabilities<\/li>\n<li>CI\/CD security gates<\/li>\n<li>runtime agents for container monitoring<\/li>\n<li>container security best practices<\/li>\n<li>automated remediation PRs<\/li>\n<li>canary deployments for patched images<\/li>\n<li>vulnerability DB update cadence<\/li>\n<li>container image layer analysis<\/li>\n<li>secret detection for container images<\/li>\n<li>license scanning in container images<\/li>\n<li>multi-stage build SBOM<\/li>\n<li>supply chain security for containers<\/li>\n<li>deduplication of scan findings<\/li>\n<li>false positive suppression strategies<\/li>\n<li>drift detection from image baseline<\/li>\n<li>observability for container scans<\/li>\n<li>on-push registry scan webhook<\/li>\n<li>admission controller deny list<\/li>\n<li>container capability hardening<\/li>\n<li>least privilege containers<\/li>\n<li>immutable infrastructure and images<\/li>\n<li>security playbooks for container incidents<\/li>\n<li>incident runbooks for compromised images<\/li>\n<li>triage workflows for scanner outputs<\/li>\n<li>alerting thresholds for container events<\/li>\n<li>executive dashboard metrics for container security<\/li>\n<li>developer workflows for fixing image vulnerabilities<\/li>\n<li>registry policy configuration checklist<\/li>\n<li>scanning cost optimization<\/li>\n<li>deep scan vs fast scan tradeoffs<\/li>\n<li>SBOM generation tools<\/li>\n<li>CVSS and container risk assessment<\/li>\n<li>automated ticketing from scan results<\/li>\n<li>key management for image signing<\/li>\n<li>forensics for container compromise<\/li>\n<li>performance impact of runtime agents<\/li>\n<li>secure defaults for base images<\/li>\n<li>feature flags for rolling out patched images<\/li>\n<li>scanning serverless deployment bundles<\/li>\n<li>top container scanning metrics to track<\/li>\n<li>how to reduce scan noise in CI<\/li>\n<li>admission control rollback strategies<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-1127","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1127"}],"version-history":[{"count":0,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1127\/revisions"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}