What breaks when teams only scan application code and ignore images and infrastructure?

Why Code-Only Scanning Misses the Real Attack Surface

Scanning application code is necessary, but it is not enough to describe how software behaves once it is built, packaged, and deployed. Images and infrastructure carry the runtime assumptions that code scanners cannot see: base-image packages, exposed ports, filesystem permissions, cloud permissions, network paths, and secret handling. When those layers are ignored, teams can approve a build that looks clean while still shipping exploitable runtime exposure. For a practical identity-linked example, the OWASP Non-Human Identity Top 10 shows how machine credentials and trust relationships often sit outside application code even though they govern production access. In practice, many security teams discover these gaps only after a release candidate reaches deployment review, rather than through intentional pre-release control coverage.

How the Gaps Show Up in Production

Code scanning answers one question: does the application source contain known weaknesses? Image and infrastructure scanning answer different questions: what does the runtime environment inherit, what does it expose, and what permissions does it receive? Those layers are not interchangeable. A container image can include outdated libraries or shell tools that never appear in the app repository. Infrastructure-as-code can define public exposure, weak storage settings, or permissive IAM roles even when the application itself is well written.

That difference matters because production failure is often created by the combination of layers, not by code alone. A harmless-looking service becomes high risk when it is deployed in an image with known vulnerabilities, granted broad network reach, or allowed to access secrets that were never meant to be long-lived. Teams also miss operational issues such as drift between source and runtime, insecure defaults in templates, and misconfigurations introduced by platform tooling rather than developers.

• Image scanning helps identify inherited dependencies and insecure base layers before deployment.
• Infrastructure scanning helps identify exposed services, weak storage controls, and overly broad access settings.
• Code scanning still matters, but it only covers one part of the delivery chain.

In mature environments, these checks are usually treated as complementary control points, not as substitutes. The workflow breaks down when teams assume source code is the single source of truth for security and ignore the runtime artefacts that actually govern exposure. That guidance becomes unreliable when build pipelines rebase images automatically, platform teams manage infrastructure separately from developers, or ephemeral environments change faster than scan coverage can follow.

Where Teams Misjudge the Boundary Between Application and Runtime Risk

Tighter scanning coverage often increases pipeline complexity, requiring teams to balance broader visibility against longer feedback loops and more ownership across development, platform, and operations. The biggest mistake is treating all findings as if they belong to the same remediation path. A vulnerable code path may belong to the product team, while an exposed cloud resource or insecure image package may belong to platform engineering, security engineering, or infrastructure owners. That distinction changes who must fix it, how fast it must be fixed, and what can safely be deferred.

There is also a genuine consensus gap in how organisations prioritise image and infrastructure findings relative to application defects. Some teams rank runtime exposure above source issues because it affects deployed systems immediately. Others prioritise exploitable application defects first because they are easier to validate in business context. Both approaches can be defensible, but only if the organisation defines which layer owns which class of risk and how exceptions are approved.

Ignoring images and infrastructure also hides second-order problems such as secret sprawl, weak segregation between environments, and inherited trust in third-party build artefacts. These issues are especially important where deployment automation, cloud provisioning, or identity-bound access is involved, because the security boundary often lives outside the code repository. The answer stops being simple when teams split development, platform, and release responsibility across different toolchains and no one is accountable for the full runtime picture.

Risk and Threat Considerations

The material risk is incomplete exposure assessment: attackers do not need application source alone if they can exploit a vulnerable base image, misconfigured infrastructure, or over-permissive runtime access. Code-only scanning can create a false sense of coverage while leaving the deployed system open to privilege abuse, external exposure, or lateral movement through inherited components and trust relationships.

Failure mechanism: the weakness materialises when security checks stop at source files and never inspect packaged artefacts, infrastructure definitions, or cloud permissions. Recognised mechanisms include vulnerable OS packages in images, public-facing resources created by templates, secrets embedded in infrastructure files, and excessive permissions granted to workloads or associated identities.

Impact: teams discover risk too late, after build promotion or deployment, when remediation is more disruptive and blast radius is larger. The consequence can be exposed services, compromised credentials, unstable releases, or control gaps that persist across multiple environments.

Practitioner Guidance

What to prioritise: Treat image and infrastructure coverage as first-class controls, not as optional hardening. If a finding affects how the workload runs, who can reach it, or what it can access, it belongs in the release decision, even when the application code is clean.

What to verify: Confirm that the pipeline scans the artefacts that actually ship, including base images, IaC, and deployment templates. The important check is not whether a scanner exists, but whether it sees the same runtime reality that production will inherit.

Ownership: Assign remediation by layer, not by generic severity alone. Product teams usually own application defects, while platform or cloud owners often own image provenance, network exposure, and infrastructure misconfiguration.

Practitioner takeaway: Code scanning is necessary for software quality, but runtime security depends on the image and infrastructure layers that define exposure after deployment.

Related resources from NHI Mgmt Group

• What breaks when teams scan container code but not the built image?
• What breaks when teams rely on scan volume instead of exploitability to prioritise application security work?
• What breaks when security teams cannot identify the last code contributor for a new application or vulnerability?
• Why do teams need to scan the running application instead of only reviewing source code when using AI coding agents?