Safeguard
Application Security•

ASVS 5.0 V15.2.3: Ship Only What Production Needs

ASVS V15.2.3 says production must not expose test code, samples or dev tools. How to strip them at build time and prove it with an image scan.

Safeguard Security Team
2 min read

ASVS 5.0 V15.2.3 requires that the production environment includes only the functionality the application needs, with no test code, sample snippets or development features exposed. It is Level 2. The direct answer: build a production artifact that physically lacks the extras, then check the running system to prove it.

Why it matters

Debug consoles, sample admin pages, seeded test accounts and verbose actuator endpoints have all caused real incidents. They are usually not malicious code, just convenience that nobody removed. Anything present in the artifact can be reached by someone eventually.

How to implement it

Remove extras at build time rather than hiding them with flags. A multi stage container build is the cleanest way:

FROM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER nonroot
CMD ["dist/server.js"]

The final image has no compiler, no shell, no test folder and no dev dependencies. Also turn off framework debug features explicitly: set the debug flag to false, disable directory listings, and restrict management endpoints to an internal network.

Click through it at your own pace, or open it full screen.

How to test it

  1. List the files in the production image and search for test, spec, example, sample and fixture directories.
  2. Request common paths such as /debug, /admin/test, /actuator, /swagger, /.git/ and /phpinfo.php against the production host and expect 404 or 403.
  3. Check that seeded demo accounts do not exist.
  4. Scan the image and compare its package list to what the app actually needs.

Common mistakes

  • Using one image for dev and production and toggling behavior with an environment variable.
  • Leaving source maps and sample data in the public web root.
  • Exposing API documentation UIs on the public internet by accident.

Quick check

Is a feature flag that disables a debug page enough?

It is weaker than removal. A misconfigured flag brings the feature back. Prefer not shipping it at all.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.