In today\u2019s fast-paced world of software development, product teams are expected to move quickly: building features, shipping updates, and reacting to user needs in real-time. But moving fast should never mean compromising on quality or security.<\/p>\n
Thanks to modern tooling, developers can now maintain high standards while accelerating delivery. In a previous article, we explored how Testcontainers supports shift-left testing<\/a> by enabling fast and reliable integration tests within the inner dev loop. In this post, we\u2019ll look at the security side of this shift-left approach and how Docker can help move security earlier in the development lifecycle, using practical examples.<\/p>\n\n We\u2019ll use a simple demo project<\/a> to walk through our workflow. This is a Node.js + TypeScript API backed by PostgreSQL and tested with Testcontainers.<\/p>\n Movie API Endpoints:<\/p>\n Method<\/p>\n Endpoint<\/p>\n Description<\/p>\n\n POST<\/p>\n \/movies<\/p>\n Add a new movie to the catalog<\/p>\n\n GET<\/p>\n \/movies<\/p>\n Retrieve all movies, sorted by title<\/p>\n\n GET<\/p>\n \/movies\/search?q=\u2026<\/p>\n Search movies by title or description (fuzzy match)<\/p>\n\n<\/div>\n Before deploying this app to production, we want to make sure it functions correctly and is free from critical vulnerabilities.<\/p>\n We verify the application against a real PostgreSQL instance by using Testcontainers<\/a> to spin up containers for both the database and the application. A key advantage of Testcontainers is that it creates these containers dynamically during test execution. Another feature of the Testcontainers libraries is the ability to start containers directly from a Dockerfile. This allows us to run the containerized application along with any required services, such as databases, effectively reproducing the local environment needed to test the application at the API or end-to-end (E2E) level. This approach provides an additional layer of quality assurance and brings even more testing into the inner development loop.<\/p>\n For a more detailed explanation of how Testcontainers enables a shift-left testing approach into the developer inner loop, refer to the introductory blog post<\/a>.<\/p>\n Here\u2019s a beforeAll setup that prepares our test environment, including PostgreSQL and the application under development, started from the Dockerfile :<\/p>\n We can now test the movie catalog API:<\/p>\n const response = await axios.post(`${baseUrl}\/movies`, payload); This approach allows us to validate that:<\/p>\n The application is properly containerized and starts successfully.<\/p>\n The API behaves correctly in a containerized environment with a real database.<\/p>\n However, that\u2019s just one part of the quality story. Now, let\u2019s turn our attention to the security aspects of the application under development.<\/p>\n\n To follow modern best practices, we want to containerize the app<\/a> and eventually deploy it to production. Before doing so, we must ensure the image is secure by using Docker Scout<\/a>.<\/p>\n Our Dockerfile takes a multi-stage build approach and is based on the node:22-slim image.<\/p>\n ########################################################### ########################################################### Let\u2019s build our image with SBOM and provenance metadata. First, make sure that the containerd image store is enabled in Docker Desktop<\/a>. We\u2019ll also use the buildx command ( a Docker CLI plugin that extends the docker build) with the \u2013provenance=true \u00a0and \u2013sbom=true flags. These options attach build attestations<\/a> to the image, which Docker Scout uses to provide more detailed and accurate security analysis.<\/p>\n Then set up a Docker organization with security policies and scan the image with Docker Scout:\u00a0<\/p>\nA Shift-Left Approach: Testing a Movie Catalog API<\/h2>\n
Shift-Left Testing with Testcontainers: Recap<\/h2>\n
\n const network = await new Network().start();
\n \/\/ 1. Start Postgres
\n db = await new PostgreSqlContainer(“postgres:17.4”)
\n .withNetwork(network)
\n .withNetworkAliases(“postgres”)
\n .withDatabase(“catalog”)
\n .withUsername(“postgres”)
\n .withPassword(“postgres”)
\n .withCopyFilesToContainer([
\n {
\n source: path.join(__dirname, “..\/dev\/db\/1-create-schema.sql”),
\n target: “\/docker-entrypoint-initdb.d\/1-create-schema.sql”
\n },
\n ])
\n .start();
\n \/\/ 2. Build movie catalog API container from the Dockerfile
\n const container = await GenericContainer
\n .fromDockerfile(“..\/movie-catalog”)
\n .withTarget(“final”)
\n .withBuildkit()
\n .build();
\n \/\/ 3. Start movie catalog API container with environment variables for DB connection
\n app = await container
\n .withNetwork(network)
\n .withExposedPorts(3000)
\n .withEnvironment({
\n PGHOST: “postgres”,
\n PGPORT: “5432”,
\n PGDATABASE: “catalog”,
\n PGUSER: “postgres”,
\n PGPASSWORD: “postgres”,
\n })
\n .withWaitStrategy(Wait.forListeningPorts())
\n .start();
\n }, 120000);\n<\/div>\n
\n const baseUrl = `http:\/\/${app.getHost()}:${app.getMappedPort(3000)}`;
\n const payload = {
\n title: “Interstellar”,
\n director: “Christopher Nolan”,
\n genres: [“sci-fi”],
\n releaseYear: 2014,
\n description: “Space and time exploration”
\n };\n
\n expect(response.status).toBe(201);
\n expect(response.data.title).toBe(“Interstellar”);
\n }, 120000);\n<\/p><\/div>\nIntroducing Docker Scout and Docker Hardened Images\u00a0<\/h2>\n
\n# Stage: base
\n# This stage serves as the base for all of the other stages.
\n# By using this stage, it provides a consistent base for both
\n# the dev and prod versions of the image.
\n###########################################################
\nFROM node:22-slim AS base
\nWORKDIR \/usr\/local\/app
\nRUN useradd -m appuser && chown -R appuser \/usr\/local\/app
\nUSER appuser
\nCOPY –chown=appuser:appuser package.json package-lock.json .\/\n
\n# Stage: dev
\n# This stage is used to run the application in a development
\n# environment. It installs all app dependencies and will
\n# start the app in a dev mode that will watch for file changes
\n# and automatically restart the app.
\n###########################################################
\nFROM base AS dev
\nENV NODE_ENV=development
\nRUN npm ci –ignore-scripts
\nCOPY –chown=appuser:appuser .\/src .\/src
\nEXPOSE 3000
\nCMD [“npx”, “nodemon”, “src\/app.js”]<\/p>\n
\n# Stage: final
\n# This stage serves as the final image for production. It
\n# installs only the production dependencies.
\n###########################################################
\n# Deps: install only prod deps
\nFROM base AS prod-deps
\nENV NODE_ENV=production
\nRUN npm ci –production –ignore-scripts && npm cache clean –force
\n# Final: clean prod image
\nFROM base AS final
\nWORKDIR \/usr\/local\/app
\nCOPY –from=prod-deps \/usr\/local\/app\/node_modules .\/node_modules
\nCOPY .\/src .\/src
\nEXPOSE 3000
\nCMD [ “node”, “src\/app.js” ]\n<\/p><\/div>\n
\ndocker scout quickview movie-catalog-service:v1\n<\/div>\n