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

Why This Matters for Security Teams

Scanning application code alone gives a false sense of coverage because most production risk is expressed outside the repository. Container images can carry vulnerable OS packages, hard-coded defaults, and inherited libraries; infrastructure-as-code can quietly create public exposure, weak encryption, or over-permissive cloud roles. The result is not just missed findings, but a mismatch between what the build pipeline checks and what the platform actually runs.

That gap matters because identity, runtime, and network posture are part of the attack surface. NHI Management Group’s Ultimate Guide to NHIs shows that 30.9% of organisations store long-term credentials directly in code and 96% store secrets outside dedicated secrets managers, which is a strong indicator that code scanning alone is not enough. The control plane must be reviewed with the same seriousness as the application layer, especially when cloud and CI/CD defaults can become production exposure in minutes.

Current guidance from the NIST Cybersecurity Framework 2.0 emphasises that asset visibility, configuration management, and access control are core security functions, not optional extras. In practice, many security teams discover the real blast radius only after a release freeze or incident review, rather than through intentional pre-production controls.

How It Works in Practice

Effective prevention requires three inspection layers: source, image, and infrastructure. Source scanning still matters for application vulnerabilities and leaked secrets, but it should be treated as only the first gate. Image scanning checks the packaged runtime for vulnerable base layers, stale packages, and misconfigured entrypoints. Infrastructure-as-code scanning then evaluates the environment that will host the workload, including network exposure, storage encryption, logging, IAM policy scope, and public access settings.

The practical issue is that each layer answers a different question. Source code tells you what developers intended. Images tell you what ships. Infrastructure-as-code tells you what the platform will provision. Teams that only inspect source often miss runtime inheritance, such as an application image pulling in an outdated OS package or a Terraform plan exposing a database to the internet. NHI Management Group’s Ultimate Guide to NHIs is especially relevant here because secrets, service accounts, and API keys frequently appear in config and deployment files long before they are visible in production monitoring.

• Scan application code for vulnerable libraries and embedded secrets.
• Scan container images for base image drift, OS CVEs, and insecure defaults.
• Scan IaC for permissive security groups, open storage, missing encryption, and overbroad IAM.
• Block release on high-severity findings that create exposure, not only on code defects.
• Re-scan on every build, image rebuild, and infrastructure change.

Control mapping should also reflect ownership. Development teams can remediate code issues, while platform teams usually own image hardening and cloud guardrails. The NIST Cybersecurity Framework 2.0 supports this division by tying risk treatment to continuously managed assets and configurations. These controls tend to break down when teams deploy ephemeral cloud resources through multiple pipelines because ownership becomes fragmented and policy enforcement arrives too late.

Common Variations and Edge Cases

Tighter scanning often increases build time and triage overhead, requiring organisations to balance delivery speed against the cost of missed exposure. That tradeoff becomes sharper in fast-moving environments where teams rebuild images frequently, generate IaC from templates, or use multiple repositories for application and platform code.

There is no universal standard for exactly where to enforce each check, but current guidance suggests prioritising controls where a defect becomes externally reachable. For example, a low-risk library issue in source may be less urgent than an IaC change that opens a database to the public internet or disables encryption on object storage. Similarly, some image findings are best handled by rebuilding from a hardened base rather than patching the application repo.

Edge cases also matter. Serverless workloads may reduce the importance of container image scanning but increase the need to inspect deployment templates, permissions, and event triggers. Managed services may remove some host-level concerns but still leave misconfigured access policies, secret handling, and logging gaps. The consistent principle is to scan the layer where the risk is introduced, not only where the code was written. The Ultimate Guide to NHIs is particularly useful when those deployments depend on service accounts and API keys that can persist far beyond the application release cycle.

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?