For security insights into the top docker images, click here to read more.
Let's talk Docker security by using a thought experiment.
Imagine you are going to build a stack of cards representing a Docker image. If a card has an X on it, that represents a security vulnerability. You start with an initial deck. You may not need all of the cards in the deck strictly speaking, but they came out of the box together so you keep them. You go around to your friends, colleagues, and internet strangers and accept cards from them to add to your deck to add functionality. You donβt scan the cards you receive from these people because you either trust them, or more likely you are focused on building your deck, not looking for Xs on cards. You also may not need all of those cards, but you have bigger fish to fry.
By the time you have finished, do you know how many Xs are present in your deck? Do you know whether they are part of your your original card deck or in the cards you added from your friends?
Do you know whether the Xs exist on cards that are really required or on cards that are just in the deck because you havenβt taken the time to sort them out?
If you wanted to minimize the number of Xs in your stack of cards, it would make sense to start with a smaller initial stack of cards, consisting of only the ones you need, and being more selective and careful about the other cards you add to your deck.
This thought experiment gives us a good idea of why minimal images in docker are a good idea from a security perspective. By preferring minimal images that bundle only the necessary system tools and libraries required to run your project, you are minimizing the attack surface for bad actors.
If you only need thirty cards, don't use a deck of 70.
For security insights into the top docker images, click here to read more.
Top comments (0)