Security of Docker Images
Last updated
Was this helpful?
Last updated
Was this helpful?
We use Docker in production and for our self-hosted package. We are implementing the following measures to make sure that our deployments are secure.
We use a single image repository . On this repository, we use for , and .
Docker, Inc. sponsors a dedicated team that is responsible for reviewing and publishing all content in the Official Images. This team works in collaboration with upstream software maintainers, security experts, and the broader Docker community. This team ensures security updates are applied in a timely manner.
We build our backend container image from a trusted, minimal : python:<version>-slim
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run python. We only pull the packages that we need. We install our connectors to external data systems sparingly and on demand in order to minimize attack surface.
We build our frontend container image from a trusted, minimal : nginx:<version>-alpine
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run nginx. We only copy Toucan's frontend files (cf CSS, JS, HTML).
Toucan has optional features allowing creation of PDFs or taking screenshots of elements of the Toucan UI. This is done in specific containers running for each customer instance with no exposed port.
This image is built on node:<version>-slim and uses Chrome.
At this time, we are not running scans on the node + Chrome image used in optional features depending on rendering parts of the app to PDF and images.
We maintain a physical separation between our build environnement and our production repository. Our images are built and scanned on our CI/CD infrastructure and are not pushed to our image repository if we find new vulnerabilities. As a result we cannot deploy images with new vulnerabilities in production.
We implement image scanning and analysis as part of our backend CI/CD pipeline. We use to do this. Our Clair instance CVE database is updated every five minutes.
Some of our self-hosted customers are using rather than Clair. We know the results of scans with different tools can be different. If your tooling is picking out vulnerabilities that we have not seen, please contact us with information on the layer and version of the problematic binary and we will help you to assess the severity of the situation and on how to potentially fix it.
If you run scans on our image you need to know that they will initially find some binaries marked as "vulnerable". CVEs are attached to libraries and programs but their impact is evaluated and mitigated differently by different distributions and maintainers. In some cases a high severity vulnerability can be marked as a minor issue in a given distribution because it can only be exploited on other distributions and images (for further details about this you should refer to this ).
For this reason, we maintain a and whitelist of the CVEs that we know are not relevant in our context (Debian userland) and should not be taken into account in security assessments. The veracity of the information in this list can always be double checked using the information, and we encourage your team to do so.
