Real-World Validating the Integrity of a Docker Container
2017 expectations

Docker is about getting some freedom from host management at the expense of reinventing all the things package management does. Docker images are just another package format. This is all very new, so I think this question is part of the growing pains of the Docker ecosystem.

basic requirements/criteria

For secure trusted containers, only use them if they have been 
 1. tested by current standards 
 2. cryptographically signed 
 3. checked against a vulnerability database for insecure dependencies

Maybe there is a way, but I don't see a way to un-trust a signed, trusted Docker image after a researcher finds a new vulnerability. This is just one gap in the toolset cited in the question.

Are you planning to use a cloud Docker service? Are the containers' memory encrypted or at least obfuscated at the kernel (containers are just processes)?

Are your Docker hosts secure?

http://ieeexplore.ieee.org/document/7562068/
http://ieeexplore.ieee.org/document/7397244/

economy of security

In the end, you can never escape the economics of checking everything, so there needs to be some respect paid to the speed Docker provides by not worrying about all of this stuff. When you know you are handling sensitive information and you know you need to lock down the execution, it will require measures that are not available yet as commodity solutions (2017). Anything is better than nothing, so get some tools deployed and get your foot in the door.

Hubblestack?

Keep your eye on HubbleStack. It provides a Docker image which can be dropped in to run audits (and remediations) against a live database of vulnerabilities. I'd be surprised if they left Docker trust out of scope forever. Also, if you own the Docker hosts, you can use root to scan all the containers. This kind of thing belongs in the DevOps automated test and validation cycle.


get some kind of checkpoint in place to get security in the pipeline
keep a backlog of unmanaged security concerns (gaps in the tools? CVEs?)
keep the backlog prioritized by what you can get done now, at current funding
get involved in devops development and release planning
deliver software confident that you did the best with the resources you had