Container security: the controls that matter before the fancy ones
Container security starts with four lines in a Dockerfile and a scan in CI. Most breaches involve failures at that level, not exotic escapes.
Reduce supply chain risk by installing fewer dependencies, evaluating each before adoption, committing lockfiles and installing with npm ci, enabling automated vulnerability alerts with a defined patch window, pinning or reviewing install scripts, and generating an SBOM so you can answer exposure questions quickly.
# Reproducible install from the lockfile — fails if it is out of sync
npm ci
# Block install scripts in CI, then run them only for packages you trust
npm ci --ignore-scripts
# Audit and see what is actually exploitable in your usage
npm audit --omit=dev| Severity | Response window | Action |
|---|---|---|
| Critical, reachable | Same day | Patch and deploy immediately |
| High, reachable | Within a week | Patch in the next release |
| High, not reachable | Next scheduled update | Document why it is not exploitable |
| Moderate / low | Batched monthly | Update with routine maintenance |
'Reachable' matters. A vulnerability in a build-time tool that never runs in production is a different risk from one in your request path. Note the reasoning — an unexplained ignored advisory looks identical to a neglected one six months later.
CI is the highest-value target because it holds deployment credentials. Restrict what CI can access, use short-lived federated credentials, and consider running installs with scripts disabled.
No. Many are in development dependencies or unreachable code paths. Triage by exploitability in your context, and document the ones you consciously accept.
They prevent surprise changes but also prevent automatic security patches. A lockfile plus automated update pull requests gives you reproducibility and a review step.
Audit what each is used for. Small utilities are often replaceable with a few lines or a native API. The bundle and the risk shrink together.
When a package manager resolves an internal package name to a public registry version of the same name. Prevent it by scoping internal packages and configuring registry resolution explicitly.
ROVQIX Engineering
Engineering team, ROVQIX
The ROVQIX engineering team builds and maintains web platforms, APIs and infrastructure for clients across SaaS, ecommerce and enterprise. These notes come out of real production work — deploys, incidents, migrations and audits.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Container security starts with four lines in a Dockerfile and a scan in CI. Most breaches involve failures at that level, not exotic escapes.
The question is not whether a secret will leak. It is whether you will know, and how long it takes to make the leaked one useless.
A pipeline that takes 25 minutes and fails randomly does not improve quality. It teaches the team to merge on red.
No spam. Just the occasional case study and craft breakdown.