Mea culpa: Docker’s security tool and Black Duck’s Security Checker are NOT the same

container security chains

It pays to look deeply, and I didn’t. I apologize. Some days, I make mistakes. Further education says Black Duck Software’s Security Checker and the Docker Cloud Security Scanning tool aren’t the same thing. Both check vulnerabilities with the CVE database—in a quest to match inflated Docker container problems—and rate containers based on the severity of vulnerabilities and the number found.

These two tools (and there are others) are designed to load and parse Docker images and run a manifest against CVEs. Here’s where things largely diverge. Note also that there are other container security tools available, and I’ll get to them in a subsequent blog post.

These are both still teaseware. You’re doing a trial.

Black Duck Software Security Checker Process

  1. Sign up.
  2. Submit your Docker container under 100MB (deflated), or pull one from the Docker repository or Red Hat’s repository directly. Other sources must be downloaded by you first, then submitted.
  3. Go for coffee or a short walk.
  4. Receive an email that the scan is finished, then look at the report linked in the email.
  5. Deep dive into the report. (You may download one of the reports I ran to see what their reports look like.)
  6. Scratch off the dozens of links in the report that have nothing (zero, nada, SFA, zippo) to do with your rational deployment of the container into your selected environment.
  7. Do this three times for free, then decide whether or not to subscribe.

Docker Security Process

  1. Sign up for Docker Cloud.
  2. Initiate your first repository. Although it will be free, you will need to subscribe.
  3. Choose and subscribe above the free tier for security checking. Make sure to tick the box for security checking.
  4. Put desired containers in your repository. Size apparently doesn’t matter.
  5. Wait 24-48 hours for an email for the report, or find it as you’re monitoring the repository as the report comes available.
  6. You have until Aug. 1, 2016, to ruse the service for free.

Black Duck Software Security-Checker Upsides/Downsides


  1. Use any related container source that Security Checker supports (when you eventually subscribe to Black Duck Security Hub, which is what Security Checker is based on) including Red Hat Atomic/OpenShift, IBM AppScan, Jenkins, TeamCity and other build/CI solutions.
  2. You get results in a couple of hours or less.
  3. You can use it with Hub, tar, zip, rar, rpm, npm, zip or other file storage methods. Interestingly missing: .iso, .cdr and other CD/DVD formats. You can convert them, I suppose.
  4. It uses VulnDB, a service that tracks vulnerabilities far faster than their appearance in the CVEs. I have not researched VulnDB to know its worth.
  5. It parses against other Black Duck Knowledge Base projects. It’s said to be over 1.5 million of them. I imagine some of those projects are asleep or worse. Black Duck has been doing parsing of such things for a very long time.


  1. Non-contextual parsing of the CVEs renders stuff that may have NOTHING TO DO with your container. This renders a wicked amount of false positives unless your organization’s policy reads something like: NEVER CROSSES OUR TRANSOM PERIOD OR YOU DIE INSTANTLY. 
  2. The above non-contextual parsing additionally renders a “cry wolf” problem where a huge ugly score may not be so ugly after all. It’s nice, in a way, in that it makes you look through all of the ugliness found so you know all of the potential problems in the code you submitted. The signal-to-noise ratio still favors signal, but it could be better.

Docker Cloud Security Tool Upsides/Downsides


  1. It examines your repository while you sleep.
  2. Every time an image is pushed, it’s scanned if you’ve opted in. This means that on the way to use, it’s “linted.”
  3. The SHA of every component is checked except at the application layer. Then it’s compared to the CVE. I’ve yet to check whether a code injection could make it stumble the SHA and make it blow up.
  4. You can opt to have only one repository checked, presumably to save eventual costs.
  5. In some cases, it’s pretty easy to swap updated/changed versions for those deemed vulnerable. The dependencies, config files, symlinks, systemd nightmares and other devils of the details are up to you.


  1. I cannot determine at this time whether the same contextual errors that Security Checker has are present in the Docker Security parser.
  2. One cannot currently examine containers from other repositories.
  3. It doesn’t do other “close-cousin” container formats.
  4. You’re limited by the file format constraints of the repository until others can be added/linked.
  5. No other vulnerability sources are used in checking container payloads.

DockerCon is coming next week, and I wish I could be there, as more details will be forthcoming.

For now, suffice to say I’m both thrilled that there are multiple ways to check container payloads, and I’m eagerly awaiting news and even better/improved methods of vetting containers. I consider provenance perhaps the biggest security issue facing container users and their consumers of workloads.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10