AutoCore Container and Image Security
Documents verified container hardening, runtime identities, health checks, and limits.
The reviewed production images use multi-stage builds, a slim Node base, a non-root node user, tini as PID 1, health checks, and compose resource limits. Unverified hardening controls remain explicitly unclaimed.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Build | Build stages prune workspace dependencies and separate build artifacts from the runtime image. |
| Runtime | The application runs as the node user with tini; Dockerfiles currently use Node 20 bookworm slim. |
| Health | API, web, and Admin have health checks; the worker health behavior is more limited. |
| Limits | Production compose defines resource limits and JSON logging boundaries. |
| Not established | Read-only root filesystem, dropped capabilities, rootless Docker, admission policy, and signed-image enforcement were not verified. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.