Container security testing checklist: What to test from build to runtime

What is container security testing?

Container security testing is the process of identifying vulnerabilities and verifying security controls across the container lifecycle, from source code and image creation through deployment and ongoing operation. It combines several complementary techniques:

• Vulnerability scanning identifies known security issues in operating system packages, application dependencies, and other software components.
• Configuration and policy assessment checks Dockerfiles, Kubernetes manifests, workload permissions, network restrictions, and related settings against security requirements.
• Software supply-chain verification checks the origin, integrity, and inventory of container images and their components.
• Runtime security monitoring looks for suspicious behavior and security-relevant changes in running workloads.
• Application security testing examines the behavior of running web applications and APIs to identify vulnerabilities that image and infrastructure scanners cannot detect.

Each technique answers different questions. An image scanner can identify a library affected by a known CVE, but it cannot generally determine whether an application exposes a SQL injection vulnerability through an API endpoint. Similarly, DAST can test that endpoint but does not establish whether every package in the underlying container image is up to date.

A practical container security testing process combines the results rather than relying on any single technique.

Container security testing checklist

Use this checklist when reviewing an existing environment or designing security checks for a CI/CD pipeline. The verification methods are starting points – the specific tools and policies will depend on your container runtime, orchestration platform, and application architecture. Mark each check as complete only after reviewing the relevant evidence and recording any findings or exceptions.

For each check, record the affected asset, finding, severity, owner, remediation status, and any approved exception. A failed check should lead to a specific action, not simply another entry in a report.

The sections below explain the main testing techniques and where they fit.

Test Dockerfiles and container images before deployment

The image build is the earliest opportunity to identify many container security issues. Problems introduced here can propagate into every environment that uses the affected image.

Verify Dockerfile and image hardening

Start by reviewing how images are constructed and which privileges their processes require. Check that base images are maintained, unnecessary packages are excluded, and production containers do not run as root unless there is a justified requirement. Multi-stage builds can help keep build tools and intermediate artifacts out of production images.

Image tags also need attention. A tag such as latest is mutable, meaning subsequent builds may retrieve different content. Pinning an image to a digest identifies the exact artifact used, although the pinned version must still be reviewed and updated when vulnerabilities are discovered.

Consider this simplified Dockerfile for a static web application served by an unprivileged Nginx image:

# syntax=docker/dockerfile:1
FROM node:24-bookworm-slim AS build
WORKDIR /src
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM nginxinc/nginx-unprivileged:stable
COPY --from=build /src/dist/ /usr/share/nginx/html/
EXPOSE 8080

This example assumes a frontend project that produces a dist directory. The build stage installs dependencies and creates the application assets, while the final stage contains the web server and generated files rather than the Node.js build environment.

This example illustrates a multi-stage build, not a production-ready configuration. Both base images use mutable tags, so production builds should pin approved images to verified digests (@sha256:...) for reproducibility. Pinned images still need regular vulnerability reassessment and updates. Teams should also inspect the resulting image to verify its user identity, permissions, filesystem requirements, and installed components. For example:

docker image inspect myapp:tested --format '{{.Config.User}}'

The command reports the image’s configured user. An empty value is not evidence of non-root execution, and the effective identity may also be affected by deployment settings. Verify the actual workload configuration as well.

Scan image components and dependencies

Container image scanning identifies known vulnerabilities in software packaged into the image, including operating system packages and supported application dependencies.

A typical image scan should provide the affected package, installed version, vulnerability identifier, severity, and available fix information. Where possible, findings should also be associated with the exact image digest.

For example, Trivy can scan a locally available image:

trivy image --scanners vuln myapp:tested

The result provides a starting point for remediation, but reported severity alone is not enough to determine the right response. Teams should also consider whether a fix is available, whether the affected component is used, the relevant threat intelligence, and the importance of the affected workload.

Images also need to be rescanned after publication. An image that passed its original build checks may contain a component for which a vulnerability is disclosed weeks later.

Check for secrets and insecure build practices

Credentials should not be embedded in Dockerfiles, copied into image layers, or passed into builds using sensitive ARG or ENV values.

Removing a secret in a later Dockerfile instruction does not reliably eliminate it from earlier layers or build metadata.

For build-time credentials, Docker BuildKit supports secret mounts that make sensitive files temporarily available during a build instruction. For example, a project that installs private npm packages can mount an authenticated .npmrc file directly:

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci

Supply the secret when invoking the build:

docker build \
  --secret id=npmrc,src="$HOME/.npmrc" \
  -t myapp:tested .

BuildKit makes the mounted file available during the RUN instruction without copying it into the resulting image layer. Unlike writing a token into npm configuration and deleting it afterward, this approach avoids creating a temporary credential-bearing configuration file in the layer’s writable filesystem.

The build must still be checked for accidental credential exposure through logs, generated files, or other artifacts. The mounted .npmrc should contain only the credentials required for the build, and those credentials should be managed and rotated according to organizational policy.

Secret scanning should cover source repositories, Dockerfiles, build outputs, and images. Any exposed credential must be revoked or rotated as appropriate, not merely deleted from the latest source revision.

Verify registry and software supply-chain security

A hardened image provides limited assurance if an attacker can replace it in a registry or if the deployment process accepts artifacts from untrusted sources.

Registry and supply-chain testing should establish which images are approved, who can publish or retrieve them, and whether deployed artifacts match those produced by trusted build processes.

Check registry access and image integrity

Review registry permissions using least privilege. Build identities should receive only the permissions needed to publish their artifacts, while production workloads should generally use read-only access to approved image repositories. Privileged registry accounts should have appropriate authentication, access review, and audit controls.

Image signing adds another verification mechanism. Sigstore cosign, for example, can be used to verify signatures against a defined trust policy. A key-based verification workflow can use:

cosign verify \
  --key cosign.pub \
  registry.example.com/team/app@sha256:<digest>

Here, <digest> represents the complete image digest obtained from the registry. The public key must come from a trusted source.

A successful verification provides evidence that the artifact matches the expected signature and trusted signing key. It does not prove that the image contains no vulnerabilities. Signature verification should therefore complement, not replace, vulnerability scanning.

Generate and maintain software inventories

A software bill of materials (SBOM) identifies components and dependencies associated with a software artifact. For container security, an SBOM can help teams identify affected images when a new vulnerability is disclosed, even if those images have not been rebuilt recently. An effective workflow associates the SBOM with an immutable image digest and preserves enough component identity and version information to support later analysis. Where supported, teams should also verify build provenance – evidence describing how an artifact was produced, including its build identity and source materials.

Together, component inventories, vulnerability scans, signatures, and provenance provide different kinds of supply-chain evidence. None should be treated as a substitute for the others.

Check Kubernetes deployment and workload security

Kubernetes introduces another set of security decisions after the image has been built. The same image may be deployed with different permissions, network access, and secret-handling configurations across environments. Testing should therefore examine both the deployment definitions and the effective configuration of running workloads.

Validate pod and container security settings

Kubernetes Pod Security Standards define three policy levels: Privileged, Baseline, and Restricted. Pod Security Admission can enforce, audit, or warn about violations using these standards.

For workloads that can meet the Restricted profile, important controls include preventing privilege escalation, requiring non-root execution, applying an appropriate seccomp profile, and dropping unnecessary Linux capabilities. Compliance must be assessed against the complete Pod specification and the Pod Security Standards version enforced by the cluster.

For example, a Linux container security context might include:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop:
      - ALL

Note that this is a container-level configuration fragment, not a complete Pod manifest. The application must be compatible with the specified user and filesystem restrictions, including having suitable writable volumes where required. The read-only root filesystem setting provides additional hardening but is not itself a requirement of the Kubernetes Restricted Pod Security Standard.

Testing should verify both the intended policy and the actual workload configuration. For example, enabling a policy in audit mode does not mean Kubernetes will reject a noncompliant deployment.

Test access controls and network isolation

Kubernetes role-based access control (RBAC) determines which actions identities can perform against cluster resources. Review RoleBindings and ClusterRoleBindings, especially those associated with application service accounts. Pay particular attention to broad permissions, access to Secrets, and the ability to create or modify privileged workloads.

NetworkPolicies can restrict communication between workloads and other network destinations, but the details matter. The following policy denies both ingress and egress for all pods in the namespace where it is applied:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

This differs from a policy that specifies only Ingress, which does not itself restrict outbound connections. A default-deny policy like this will generally need carefully scoped allow rules for workloads that must communicate, potentially including DNS resolution, application dependencies, and ingress traffic.

NetworkPolicy enforcement depends on a compatible networking implementation. Teams should therefore test permitted and prohibited connections rather than assuming that a valid YAML manifest guarantees the intended isolation. NetworkPolicies are additive, so other applicable policies must also be considered.

Validate secrets handling and host exposure

Kubernetes Secrets provide a mechanism for supplying sensitive data to workloads, but creating a Secret does not automatically guarantee confidentiality.

Review which identities can read Secrets, how secret data is protected at rest, how credentials are supplied to applications, and whether rotation procedures work. Also inspect workloads for unnecessary host-level access, including hostPath mounts, host namespaces, privileged containers, and excessive capabilities. These settings can weaken isolation between containers and the underlying node.

Finally, verify that admission controls reject workloads that violate the organization’s deployment requirements. Testing an intentionally noncompliant manifest in a controlled environment can provide stronger evidence than reviewing policy definitions alone.

Assess security in running containers

Build-time and deployment checks provide a baseline, but running environments change. New vulnerabilities are disclosed, workloads are redeployed, permissions change, and unexpected behavior may appear after release. Runtime security assessment should therefore cover both the state of deployed workloads and their behavior.

Start by comparing running image digests and configurations against approved deployment records. This can reveal unauthorized changes, outdated versions, or workloads that bypassed the expected release process. 

Specialized runtime security tools can monitor events such as unexpected process execution, suspicious network connections, changes to sensitive files, or attempts to gain additional privileges. These observations serve a different purpose from vulnerability scanning. A runtime alert may indicate potentially malicious activity, while an image scan identifies a known vulnerable component whether or not exploitation has occurred.

Container environments also complicate investigation because workloads can be short-lived. Security-relevant logs and events should be collected centrally and retained according to operational and compliance requirements. Runtime security testing should verify that the relevant monitoring and logging controls are functioning, not simply that a monitoring agent has been installed.

Test the applications and APIs running in containers

Container and Kubernetes security checks cannot establish whether the software running inside a workload is secure. A container can follow restrictive deployment policies and still expose a web application with SQL injection, cross-site scripting, authentication weaknesses, or broken access controls. This is where application security testing adds a different type of evidence.

Test running web applications with DAST

Dynamic application security testing (DAST) interacts with a running application through its exposed interfaces, typically using HTTP requests and browser-based interactions. Rather than relying exclusively on source code or package inventories, DAST examines how the application responds to security tests. This can identify vulnerabilities that are not directly visible through container image scanning, including injection flaws and insecure application behavior.

Authenticated scanning is especially important for applications where sensitive functionality is available only after login. Scanning an unauthenticated landing page may leave most business-critical functionality untested. DAST should be configured for the application and environment, including authentication, scan scope, test accounts, and potentially disruptive operations. Staging environments are often suitable for more extensive testing, while production scanning requires appropriate safeguards.

DAST results also need interpretation. Some findings can be automatically confirmed, while others require additional investigation.

Include API discovery and security testing

Containerized applications frequently use microservices and APIs for communication between components. Some endpoints may be exposed through an API gateway, while others support internal services or administrative functions.

API security testing starts with knowing which interfaces exist. An inventory assembled only from published API specifications may miss undocumented, deprecated, or otherwise unmanaged endpoints. Discovery can draw on source code, network traffic, gateway information, and application scanning. 

Once identified, APIs should be tested for vulnerabilities affecting both the underlying application and the API interface itself. Important examples include:

• Broken object level authorization (BOLA), where a user can access an object belonging to another user.
• Broken function level authorization (BFLA), where an identity can invoke functionality it should not be permitted to use.
• Authentication and session-management weaknesses.
• Injection vulnerabilities through API parameters or request bodies.
• Excessive exposure of sensitive data through API responses.

Testing authorization requires appropriate identities, roles, and test data. A scanner cannot reliably assess every business-specific permission rule without enough information about the expected behavior. Stateful API testing can also help exercise workflows in which one request creates or modifies data used by subsequent requests.

Use runtime evidence to improve confidence

Application testing can provide valuable evidence about whether a vulnerability can be exercised in a running environment. Invicti’s proof-based scanning can automatically confirm many supported vulnerability types using safe, non-destructive exploitation techniques. Confirmed findings include evidence that helps developers understand and remediate the issue. Runtime evidence can also inform prioritization when related findings from different testing techniques can be correlated. 

There are also some important limits. Not every vulnerability can be automatically confirmed, and a DAST scan does not prove that every vulnerable dependency in a container image is exploitable. For example, an image scanner might report a vulnerable Java library. A separate DAST finding could demonstrate an exploitable application endpoint. Those findings should only be treated as directly related when the available technical evidence supports that relationship.

Runtime-informed prioritization is most useful when combined with component inventories, application context, threat intelligence, and business impact.

Integrate container security testing into CI/CD

Container security testing becomes more manageable when checks run automatically at the stages where they can provide useful feedback. The objective is to identify issues early, prevent unacceptable risk from reaching production, and continue reassessing deployed applications as conditions change. 

Security checks at specific stages of the pipeline may include:

Not every security finding should trigger the same response. An actively exploited vulnerability affecting an internet-facing application may warrant immediate intervention. A vulnerable component that is not currently loaded or reachable may require a different remediation decision, although it should not automatically be dismissed. Security gates should therefore use defined policies that consider severity, exploitability evidence, asset criticality, available fixes, and organizational risk tolerance.

Where a release proceeds with a known issue, the exception should have an owner, justification, expiration or review date, and remediation plan. Testing should also continue after a fix. Rebuilding an image, changing a Kubernetes policy, or modifying application code does not by itself establish that the original vulnerability has been resolved. The relevant check should be rerun against the updated artifact or deployment.

Example: Combining container, Kubernetes, and API security findings

Consider a containerized customer account service running in Kubernetes. Security scanning generates the following findings:

• A container image scan identifies a Java dependency with a known vulnerability.
• A Kubernetes configuration assessment reveals that the service account has broader permissions than the workload requires.
• Authenticated API security testing identifies a broken object level authorization (BOLA) vulnerability that allows one test user to retrieve another user’s account information.

These findings represent three distinct security problems that require different remediation actions. The vulnerable dependency needs assessment against the affected version, available fixes, and relevant runtime or threat evidence. The excessive service account permissions require a Kubernetes configuration change. The API authorization flaw requires an application-level fix and retesting using different user identities.

Looking at these findings together gives security teams a more complete view of the service’s risk exposure. It also helps them assign remediation work to the right teams, distinguish confirmed application vulnerabilities from potentially vulnerable components, and track fixes across the container and application stack.

These findings should not be assumed to be directly related. An exploitable API vulnerability does not prove that a separate vulnerable dependency is exploitable. Any correlation between the findings must be supported by technical evidence.

Bringing these different types of findings into a shared security workflow is where application security posture management becomes particularly useful.

How Invicti connects container and application security findings

The example above illustrates a common challenge for AppSec teams: Different security tools identify different types of risk, but those findings still need to be assessed, prioritized, assigned, and remediated as part of a coordinated process. 

The Invicti AppSec platform brings together security testing and vulnerability management capabilities across the development lifecycle. Invicti Container Security supports image scanning across registries and Kubernetes clusters, including vulnerable component analysis, misconfiguration and secrets detection, and SBOM capabilities. SCA and source-level security testing provide additional visibility into dependencies and development-stage issues.

For running web applications and APIs, Invicti uses DAST and API security testing to identify vulnerabilities in exposed functionality. Proof-based scanning can confirm supported vulnerabilities, providing evidence to support remediation. ASPM brings findings from supported security tools into a common management workflow, with normalization, deduplication, risk prioritization, policy automation, and remediation tracking.

Test across the container lifecycle, manage risk in one place

Effective container security testing combines image and software supply-chain scanning, Kubernetes configuration assessment, runtime monitoring, and application security testing. Each technique identifies different risks, and findings need to be reassessed as software, deployments, and threats change.

Bringing these results into a common AppSec workflow helps teams prioritize remediation, assign ownership, and verify that issues have been resolved.

Explore Invicti Container Security to see how container scanning fits into a broader application security program, and request a demo to see the Invicti AppSec platform in action.