vigilante-issue-implementation-on-docker

Vigilante Docker Issue Implementation

Focus

• Read the prompt for detected tech stacks, process hints, and Docker security guidance before changing code.
• Follow current Dockerfile best practices for image minimization, build efficiency, and secret-safe builds.
• Keep changes scoped to the issue and do not broaden into unrelated infrastructure redesign.

Dockerfile Best Practices

• Base images: pin base images to specific versions or digests rather than mutable tags like latest. Prefer minimal base images (Alpine, distroless, scratch) to reduce attack surface. When the repository already uses digest-pinned or distroless images, preserve that convention.
• Build structure: use multi-stage builds to separate build dependencies from the final runtime image. Set an explicit WORKDIR rather than relying on the default. Combine related RUN commands to minimize layers. Order instructions from least to most frequently changing to maximize build cache efficiency. Copy dependency manifests and install dependencies before copying application source.
• Package management: minimize installed packages and remove package manager caches in the same RUN layer (e.g., apt-get install -y --no-install-recommends ... && rm -rf /var/lib/apt/lists/*). Do not install debug tools, editors, or shells in production images unless the repository explicitly requires them.
• .dockerignore: ensure .dockerignore excludes build artifacts, test fixtures, secrets, and version-control metadata that should not enter the build context.

Secret-Safe Builds

• Never pass secrets through ARG or ENV instructions — they persist in image history and layer metadata.
• Use BuildKit secret mounts (--mount=type=secret) for build-time secrets when the build requires credentials.
• Do not copy secret files (.env, credentials, tokens, private keys) into the image.
• Ensure .dockerignore excludes sensitive files and directories.

Runtime Security

• Run containers as a non-root user when practical — add a USER instruction after installing packages.
• Prefer read-only root filesystems where the application supports it.
• Expose only the ports the application requires.
• Do not use --privileged or add unnecessary Linux capabilities unless the issue specifically requires it.