Docker lets security bug sniffer dogs off the leash at container images Docker has hit upon an idea that perhaps other platforms could potentially incorporate: scanning software components for publicly known vulnerabilities prior to deployment. Today, the software container biz will announce Docker Security Scanning, which scours private repositories in the Docker Cloud for recognized security …
The developer gets an alert that there is a security flaw in the code that needs to be rectified. The developer then checks a few boxes and deploys as is, regardless of the warning. There will be scant uptake by devs as this will be perceived as an annoying additional step in the development process.
You know, it'd be nice if you didn't think all devs were idiots. I respect smart sysadmins and I find I learn a lot from them. And, though I have occasionaly seen incompetent ones, I would find it foolish to generalize against the profession.
We kinda depend on each other, so no need for the nastyness.
Me think there is a world of benefits from this type of idea. If you are gluing systems together, whether via Docker, VMs or package installers, that means you have atomic units of code that are versioned and IDed in repos. If versions subsequently are shown to have bugs, then, yes it'd be nice to use computer brainpower to flag it. And I don't think it's that big of a hassle to bump up versions for a good cause (rather than maniacally chasing latest across the board for no clear reason).
@AC how long do you expect a container to run for? Why would I periodically rescan something designed from the ground up to redeploy repeatedly. Scanning has a performance impact, deploying from fresh does not. This technology is akin to an Exchange server which handles one email but we start up 2000 of them. The intention isn't really to leave it running long enough to be problematic.
Why scan 2.000 times? If nothing has changed, just store the BOM in a database and inform me which containers are impacted when a new vulnerability is discovered, based on the information in the database.
> @AC how long do you expect a container to run for? Why would I periodically rescan something designed from the ground up to redeploy repeatedly.
Who knows - it could be running for months. Not everybody eats the agile/devops daily release mantra.
But the point is, it's not even necessary to scan every container! Rather, you scan the master image which it was spawned from.
Hence if you have 1000 containers running from the same image, you only need to scan one; and the scanning should take place on your repository, not the production servers, so has no service impact.
All you need to do is to track which containers were spawned from which images. If the master image is no longer being used by any running containers, then it can be garbage-collected anyway.
We do this now. But we deploy the known vulnerable containers anyway - it's just too hard to patch everything and retest.
We do try to patch important stuff. So, for example, a vulnerability in tiff parsing we'd let through because we never parse tiffs in production. There's risk here of course, but it's part of using Docker in a microservice environment.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
