Documentation

Overview

Last updated: May 2026

See also: Terms and Conditions · Privacy Policy

DockerSec helps identify security risks and insecure patterns in Dockerfiles. The service can be used interactively through the website, by signed-in users who want to track previous scans, and, in future, through automated CI integration for enterprise workflows.

Use the topics on the left to learn more about the main DockerSec features:

Interactive Analysis explains how to submit a Dockerfile through the website and review the findings produced by DockerSec.

Credential Sanitisation describes how DockerSec detects and redacts credential-like values before storing submitted Dockerfiles, including the limits of this protection.

Scan History explains how authenticated users can view previous scans, retest Dockerfiles, add notes, apply tags, and delete stored results.

CI Integration describes the planned enterprise API and how DockerSec is expected to integrate with platforms such as GitHub Actions and GitLab CI/CD.

DockerSec findings are intended to support security review and remediation. They should be considered alongside your own knowledge of the application, build process, deployment environment, and organisational risk appetite.

Interactive Analysis

DockerSec provides interactive Dockerfile security analysis directly from the home page.

Paste or upload a Dockerfile using the submission form and DockerSec will analyse it immediately. The results are presented as a set of security findings, grouped by severity, so that higher-risk issues can be reviewed first.

Each finding includes:

  • the affected Dockerfile instruction or behaviour;
  • a description of the issue;
  • the potential security impact;
  • practical remediation guidance;
  • where possible, a reference to the relevant line or Dockerfile construct.

The analysis is designed to help developers, DevOps engineers, platform teams, and security teams identify insecure Dockerfile patterns early. Examples of issues DockerSec may report include the use of overly privileged users, unsafe package installation patterns, unnecessary exposure of ports, insecure downloads, embedded credentials, weak image pinning, and configuration choices that increase container risk.

DockerSec results should be treated as security guidance rather than a guarantee. Some findings may not be exploitable in your specific environment, and some risks may depend on how the image is built, deployed, and run. You should review each finding in context and decide whether the recommendation applies to your use case.

Interactive analysis can be used anonymously. If you are signed in, your scans can also be stored in your account history, allowing you to revisit previous results, add notes, tag scans, delete records, and retest Dockerfiles after making changes.

Credential Sanitisation

DockerSec automatically detects and redacts credential-like values in ENV and ARG instructions before storing your Dockerfile. This helps protect you if your Dockerfile contains real passwords, tokens, API keys, or similar sensitive values.

For example:

ENV DB_PASSWORD=mysecret       →  ENV DB_PASSWORD=SANITISEDPASSWORD1
ARG API_TOKEN=abc123           →  ARG API_TOKEN=SANITISEDPASSWORD2
ENV DB_PASSWORD=mysecret       →  ENV DB_PASSWORD=SANITISEDPASSWORD1

How it works

Security analysis runs against the original Dockerfile content you submit. This means findings are based on the real Dockerfile, not the redacted stored copy.

Only the stored copy is sanitised. Credential-like values detected by DockerSec are replaced before the Dockerfile is written to the database.

Each unique credential value is assigned a numbered label, such as:

SANITISEDPASSWORD1
SANITISEDPASSWORD2
SANITISEDPASSWORD3

If the same value appears more than once, it receives the same replacement label each time. This preserves useful context without retaining the original secret.

For example:

ENV DB_PASSWORD=mysecret
ENV BACKUP_PASSWORD=mysecret

would be stored as:

ENV DB_PASSWORD=SANITISEDPASSWORD1
ENV BACKUP_PASSWORD=SANITISEDPASSWORD1

What is detected

Redaction applies to ENV and ARG instruction keys whose names suggest that the value may be sensitive. This includes names containing words such as:

Password
Secret
Token
Key
Auth
Credential
Access
Private
APIKey
SSHKey
Secure

Detection is case-insensitive.

Warning before submission

When DockerSec detects credential-like values in your Dockerfile, the home page displays a warning banner before submission. This gives you an opportunity to review the Dockerfile and decide whether to continue.

Important limitations

Credential sanitisation is a protective measure, not a guarantee.

DockerSec attempts to identify credential-like values in specific Dockerfile instructions, but it may not detect every secret or sensitive value. You should avoid submitting real credentials, production secrets, private keys, tokens, or commercially sensitive values unless this is necessary and appropriate.

Credential sanitisation currently applies to detected values in ENV and ARG instructions. Sensitive values placed elsewhere in a Dockerfile, such as in RUN commands, copied files, comments, URLs, labels, or build arguments embedded into shell commands, may not be redacted before storage.

For best results, remove secrets from Dockerfiles entirely and use your platform's secret-management mechanism instead.

Scan History

Authenticated users can access their previous DockerSec scans from the History section.

Scan History is intended to support ongoing review and remediation. It allows you to track Dockerfiles over time, revisit earlier findings, and compare the impact of changes after risks have been addressed.

From the History section, you can:

  • view previous Dockerfile submissions;
  • review the findings produced for each scan;
  • retest a Dockerfile after making changes;
  • add notes to a scan;
  • apply tags to help organise related scans;
  • delete scans that are no longer required.

Retesting previous scans

Retesting allows you to run the current DockerSec analysis engine against a previously submitted Dockerfile. This is useful when:

  • DockerSec has been updated with new checks;
  • you want to confirm whether earlier findings are still present;
  • you want to compare results before and after Dockerfile changes;
  • you are maintaining an audit trail for remediation work.

Retesting does not alter the original scan unless explicitly stated in the user interface. Where a new scan is created, it will be recorded as a separate result so that historic findings remain available.

Notes and tags

Notes can be used to record context that is specific to your environment, such as why a finding has been accepted, why a recommendation does not apply, or what remediation work is planned.

Tags can be used to group scans by project, repository, application, team, environment, or review status. For example:

production
backend-api
accepted-risk
needs-review
remediated

Deleting scans

You can delete scans that are no longer needed. Deleting a scan removes it from your account history.

Deletion may not immediately remove data from backups or operational logs, but those copies will be removed or overwritten through normal retention processes.

CI Integration

CI integration is currently in development.

The DockerSec API is being designed to allow enterprise users to submit Dockerfiles automatically as part of their development and deployment workflows. The goal is to provide fast feedback when Dockerfiles are added, changed, or refined, allowing teams to identify potential security risks before container images are built or deployed.

Intended use

The CI integration is intended to support automated checks in platforms such as:

GitHub Actions
GitLab CI/CD
Bitbucket Pipelines
Azure DevOps
Jenkins

When released, the API will allow committed Dockerfiles to be submitted programmatically. DockerSec will then return structured results that can be used to inform build decisions, security review, or developer feedback.

Authentication

CI integration will use API tokens.

To create an API token, you will need to:

  • have a DockerSec account;
  • be authenticated;
  • hold an active enterprise licence;
  • generate a token from the account or organisation settings area.

API tokens should be treated as sensitive credentials. They should be stored using your CI platform's secret-management feature and should not be committed to source control.

Thresholds and exceptions

The planned CI integration is intended to support configurable thresholds. This will allow organisations to define when a Dockerfile should pass or fail automated checks.

For example, a team may choose to fail a build when:

  • a critical finding is introduced;
  • a high-severity finding is introduced;
  • the number of findings exceeds an agreed threshold;
  • a finding appears that is not covered by an approved exception.

The intended model is to support a clear go/no-go decision while still allowing organisations to manage justified exceptions. This is important because some Dockerfile risks may be acceptable in a specific context, provided the decision is understood, documented, and reviewed.

Planned API workflow

A typical CI workflow is expected to look like this:

  1. A Dockerfile is added or changed in a repository.
  2. The CI pipeline submits the Dockerfile to the DockerSec API.
  3. DockerSec analyses the submitted content.
  4. The API returns structured findings.
  5. The CI job evaluates the result against the configured threshold.
  6. The pipeline either passes, fails, or reports findings for manual review.

Example use cases include:

  • blocking high-risk Dockerfile changes before merge;
  • commenting on pull requests with DockerSec findings;
  • generating build artefacts containing analysis results;
  • tracking Dockerfile security posture across multiple repositories;
  • enforcing organisation-wide container build policies.

Current status

CI integration is not yet generally available.

This section will be updated when the API, authentication model, example integrations, and enterprise configuration options are released. Future documentation will include examples for GitHub Actions and GitLab CI/CD, including how to submit Dockerfiles programmatically and how to interpret the returned results.

Contact us to register your interest or be notified when CI integration becomes available.

Limitations

DockerSec analyses the contents of the Dockerfile that you submit. The results are based only on that Dockerfile and the checks that DockerSec is able to perform against it.

DockerSec does not build the image, run the container, inspect the final filesystem, or test the deployment environment. This means the analysis cannot provide a complete view of the security posture of the resulting image or application.

DockerSec cannot assess:

  • how the image is built, published, deployed, or run;
  • the runtime configuration used by Docker, Kubernetes, or other container platforms;
  • Docker Compose, Helm, Terraform, Kubernetes, or other deployment configuration files;
  • environment variables, secrets, volumes, networks, capabilities, or security options applied at runtime;
  • the contents of files copied into the image using COPY or ADD;
  • application source code, package manifests, scripts, binaries, or configuration files included in the build context;
  • vulnerabilities in installed operating system packages or application dependencies, unless they are identifiable from the Dockerfile itself;
  • whether a referenced base image is currently vulnerable, compromised, outdated, or appropriate for your environment;
  • whether commands executed during the build behave safely in practice;
  • whether findings are exploitable in your specific infrastructure or threat model.

For example, DockerSec may identify that a Dockerfile copies files into an image, but it cannot inspect those files unless their contents are included in the submitted Dockerfile. Similarly, it may identify that an image runs as root, exposes a port, or installs packages, but it cannot determine how that image is ultimately started, isolated, networked, or restricted in production.

DockerSec findings should therefore be treated as Dockerfile-focused security guidance. They are useful for identifying insecure patterns early, but they should be reviewed alongside other evidence, including image scanning, dependency scanning, runtime configuration review, container hardening, CI/CD controls, and environment-specific threat modelling.

Licences and Usage

DockerSec uses a licence-based model to control scan usage and keep the service available to all users.

A licence is consumed when DockerSec performs a new analysis. The model supports anonymous use, provides additional benefits to registered users, and will accommodate paid tiers in future.

Anonymous Use

Anonymous users receive one licence per 24-hour period, applied per IP address.

Once used, no further chargeable scans from the same IP address are available until the 24-hour window resets. This limit prevents abuse and keeps the service available to other users.

Registered Users

Registered users receive one licence per 24-hour period.

Your daily allowance resets at the point of registration, so you receive a scan immediately on creating your account, regardless of any anonymous scans already used from your IP address that day.

Creating an account also unlocks Scan History, retesting previous scans, notes, and tags.

Retesting Previous Scans

Authenticated users can retest Dockerfiles from their Scan History.

A licence is not consumed when a previous scan is re-run and:

  • the analysis results have not changed; or
  • the scan produces no findings.

A licence may be consumed where a retest produces new or changed findings.

Pro, Enterprise, and Enterprise CI tiers are in development. These will offer higher daily limits, share links, API access, and CI/CD pipeline integration.

See the Pricing page for a full comparison of tiers and to register your interest.