Will restarting a container resolve its security issue?
A restart alone does not fix a vulnerable image, unsafe permission or exposed secret. The underlying condition and the deployed state need to be corrected and verified.
Planning reference / Specified scope
Cloud and container security assessment.
A container security assessment examines the relationship between workloads, the host, deployment infrastructure and cloud permissions. AI Defence is designed to review configuration and vulnerability evidence together, rather than treating an image scan as the complete security picture.
IN DEVELOPMENTThis page describes planned assessment scope. See capability availability.
Planning reference: this page explains the specified assessment direction. For functions inspected in code and their limits, see the current capability guide.
Check the runtime, not only the image
An image can have no known package finding while the running container has unnecessary privileges or sensitive host access. The specification therefore includes root containers, privilege levels, dangerous Linux capabilities, host mounts, Docker socket exposure and network isolation.
The inventory also records images, registries, stale images, provenance and embedded secrets. These checks help explain what is running and where it came from, while connecting runtime configuration to the repository and deployment process.
- Container and image vulnerabilities, plus excessively privileged workloads.
- Registry access, image provenance and secrets embedded during builds.
- Kubernetes and RBAC assessment where relevant and supported.
- Cloud IAM, security groups, public storage and metadata-service exposure.
Follow permissions across cloud boundaries
A workload may hold credentials or a machine identity that reaches other services. Reviewing that identity, its scope and the network paths available to it helps reveal why one exposed workload might affect more than its own container.
Provider-specific discovery needs authorised access and a supported connector. Kubernetes coverage or cloud IAM review is part of the intended scope, not a claim that every orchestration system or cloud provider already has a turnkey integration.
Harden through a deployment-aware workflow
Approved remediation might reduce privilege, remove an unsafe mount, restrict network exposure or update an image. The plan needs to account for persistent storage, workload dependencies, service accounts and recovery. Configuration changed only on a running instance may disappear on the next deployment.
Verification should therefore consider both the active workload and its durable deployment definition. It should confirm the risky permission or exposure has changed, the correct image is running and required service health remains intact. Continuous monitoring is designed to identify subsequent drift from that accepted state.
Questions answered
Are all cloud integrations available?
No general availability claim is made for the full cloud and Kubernetes scope. Confirm the required provider, collector permissions and supported checks with Altari.
Talk directly to Altari
Bring the environment.
Start with the right questions.
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.