« Previous 1 2 3
Security issues when dealing with Docker images
The Crux with Leaks
Good Sources, Quick Scans
Many system administrators retrieve software from a variety of sources. It is always advisable to carefully consider the providers of these sources – this also applies to classic software without containers. In this regard, Docker and others are no less or more secure than traditional installations.
If you provide images for Docker, but also offer rkt or Project Atomic, you should disclose how you handle updates and known vulnerabilities. This is the only way to ensure permanently secure operation of such software. Whether a commercial product can be linked with higher quality has been the subject of much discussion since the early days of open source, because some promises relating to security quality can genuinely be purchased with commercial applications.
The different static security scanning offerings usually test signatures. The results of the current implementations are mediocre and contain many false positives. The question arises as to whether the additional overhead of reworking actually justifies the amount of money you pay.
Info
- Docker: https://www.docker.com
- Best practices for official images: https://github.com/docker-library/official-images#security
- Docker Notary: https://docs.docker.com/notary/getting_started/
- The Update Framework: https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt
- Docker Hub: https://hub.docker.com
- CoreOS Clair: https://github.com/coreos/clair
- Project Atomic Scan: https://developers.redhat.com/blog/2016/05/02/introducing-atomic-scan-container-vulnerability-detection/
- OpenSCAP: https://www.open-scap.org
- Nmap Scripting Engine: https://nmap.org/man/de/man-nse.html
- Nessus: http://de.tenable.com
- OpenVAS: http://www.openvas.org/index.de.html
- Lynis: https://cisofy.com/lynis/
« Previous 1 2 3
Buy this article as PDF
(incl. VAT)