A vulnerability scanner finishes with zero critical CVEs. The CI pipeline turns green and the image is deployed.
That is useful, but it does not establish that the application is safe in production.
Image scanners help identify known vulnerabilities in packages and components they can inspect. They cannot prove that a running process has only the permissions it needs, that its credentials are scoped correctly, that its network egress is restricted or that an application-level authorization flaw cannot be exploited.
Security engineering needs several controls that answer different questions.
Start by asking what was actually scanned
A scanner may operate on a source repository, dependency manifest, built container image or running workload. These surfaces overlap, but they are not interchangeable.
An image scan can inventory operating-system packages and language dependencies included in the image. It can miss dependencies downloaded at runtime, dynamically loaded components or flaws not covered by the scanner's vulnerability database. It can also flag libraries that are present but not exploitable through the deployed application path.
A high-confidence result therefore includes the image digest, scanner version, database freshness, scan scope and exceptions. "No critical vulnerabilities found" is a statement about that scan and its data, not a proof that no exploitable defects exist.
Image provenance is a separate control
Even a current dependency set does not prove that an image came from the intended source and build pipeline.
Production teams should be able to answer which repository commit, build workflow and dependencies produced a deployed image, and how the deployment verifies it was the expected artifact.
A software bill of materials, immutable image digests and signed provenance can help, but only when the verification and policy are actually enforced at the deployment boundary. Merely producing attestations in CI without checking them is documentation, not protection.
Third-party images introduce another question: who can update the upstream repository, and what happens when the expected image digest changes?
Runtime identity can turn one bug into many systems at risk
A workload may run with broad Kubernetes API privileges or unnecessary cloud IAM permissions. If compromised, it can potentially reach more than the intended application data.
Review service account tokens and cloud identity bindings as carefully as package versions. A namespace boundary alone does not grant least privilege. Kubernetes RBAC, workload identity, admission controls and cloud permissions together define what a compromised process can access.
A production deployment should not rely on the absence of a known CVE to compensate for over-privileged credentials.
A useful test is to deploy a disposable test workload with the intended service identity and attempt only authorized API calls. Also confirm that access to unrelated Secrets or cloud resources is denied.
Kubernetes NetworkPolicy is not automatically enforced
A NetworkPolicy resource describes desired network permissions, but the underlying networking implementation must enforce it.
If the cluster has a policy engine that supports the rules, a default-deny approach can reduce unintended Pod-to-Pod communication and egress. However, applying a blanket deny policy to production can block DNS, monitoring and legitimate service dependencies if allow rules are incomplete.
For a controlled test, compare connection behavior before and after applying policies in a disposable namespace. Test the paths that should be allowed and denied. Do not rely only on a valid YAML manifest.
See the Kubernetes NetworkPolicy documentation for enforcement prerequisites and the limitations of standard policy semantics.
Secrets and external dependencies also matter
A container image does not normally contain its Kubernetes Secret values, but the running workload may have access to them. Credentials can also leak through logs, process arguments, debug endpoints and overly broad service roles.
Review how Secrets are issued, rotated, mounted and revoked. Verify how the application responds to rotation; replacing a Secret object does not guarantee a long-running process reloads it.
Consider external dependencies as part of the risk model. If a workload can initiate arbitrary outbound connections, a single compromised service may be able to contact destinations unrelated to business functionality.
Security controls should be tested against expected workload behavior rather than based only on generic scanner defaults.
Prepare to investigate runtime anomalies
The pipeline should generate an audit trail of what was built and deployed. Runtime observability should be able to answer when a suspicious process appeared, which identities and services it used, and which changes preceded it.
When a real incident is suspected, preserve necessary evidence before destroying the affected environment if it is safe to do so, and contain active harm without unnecessary delay. Do not assume that deleting a Pod is complete remediation: a compromised source image, leaked credential or persistent misconfiguration can recreate the same problem.
For a deeper operational response guide, see the separate BBB-approved security article Suspicious Process in Production? Preserve Evidence, Then Contain the Network once that article has a verified public URL.
Reported AI-orchestrated intrusion workflows make these identity, detection and recovery controls more urgent; they do not change the need to verify each control independently.
A defensible release security gate
A useful release process asks multiple independent questions:
- Did the expected source produce the deployed artifact, with immutable identity and verified provenance?
- Were known vulnerabilities checked using current data and an agreed exception policy?
- Are runtime identities restricted to the APIs and cloud resources the workload actually needs?
- Are required network paths allowed while unrelated ingress and egress are denied?
- Does the system have observability and a tested response path for suspicious behavior?
Each control has limitations, and none is a substitute for the others. Together, they create a stronger release decision than a single green scanner badge. This is the release gate we build in DevSecOps work for Kubernetes and CI/CD pipelines. Apply the same scrutiny to the GitHub Actions runner security boundary that produced the image.
If the deployment's security posture depends on assumptions no one has exercised, start with a bounded, reproducible review of the image supply chain, runtime identity and network enforcement. That is one way Big Bad Byte's DevOps engineering helps teams make production security measurable, and it fits into a written infrastructure audit when you need the wider picture first.