As a DevSecOps engineer, do you have security CVEs (Common Vulnerabilities and Exposures) slowing down or halting your development? Are you constantly seeking exceptions for your security findings? If you’re like me, you dread spending time constantly remediating CVEs just to find that they are part of your base image and not your codebase.

Feeling like the image above, “I ain’t got time for irrelevant CVEs”. I decided to take the plunge and make the move to Alpine after one of my most recent projects came back with the following CVEs.

That’s right, 1 Critical, 13 High, 34 Medium, 4 Low, and 173 Informational findings. Mind you, this was on the latest image from docker hub! I decided then, I’d try to make the switch to Alpine. I thought “It can’t hurt to give it a try at this point”.

For those unfamiliar with Alpine Linux, Alpine Linux was built as a security-oriented distribution (distro) of Linux. It’s small, lightweight, and doesn’t include all the extra bells and whistles included with many Linux distros, and that’s a good thing from a security perspective. That means less time remediating outdated libraries, binaries, etc in your base container images. More information about Alpine Linux can be found here Alpine Linux.

I updated my Dockerfile to the -alpine image and went through updating my packages. Luckily, Alpine has an easy way to search packages on Alpine Linux packages and for the most part I found my software dependencies pretty easily. I spent around 1.5 hours updating and testing everything and then ran it through my scanner. I got the following results:

That’s right, ZERO, nada, zilch CVE findings. I was floored! Is Alpine just that much better than other base images? I wasn’t sure before beginning this journey but seeing is believing.

So why is Alpine Linux so much more secure than traditional Linux distros? This is because Alpine Linux binaries are compiled using Position Independent Executables (PIE) also known as Position-independent code (PIC) with stack smashing protection to prevent zero-days and other exploits. This means that each binary is run in virtual memory by default, making stack overflow attacks based on memory much more difficult. This gives Alpine Linux an edge over other Linux distros due to this memory protection, especially when it comes to common CVEs. That also means that all Alpine binaries are hardened within Alpine Linux by default, pretty cool huh?

So what’s the process for building this yourself? I’ve outlined the process using the image above. If you want to convert your existing base Docker images to Alpine Linux it can usually be done fairly easily yourself. First off, most major development platform images usually support Alpine. For example with NodeJS you can search DockerHub for a “-alpine” image like the below https://hub.docker.com/_/node/tags?page=&page_size=&ordering=&name=-alpine/.

Once you find the image it’s only a matter of updating your Dockerfile to use the new image. Since this is a new base image, you will most likely need to update any packages you need installed. This is where alpine packages https://pkgs.alpinelinux.org/packages/ comes into play. You can search any existing packages you need and update your Dockerfile installation with the new apk packages. From there it’s a matter of building and testing your base image, note you may need to build and test until you feel your new image meets all your criteria. Then from there you can publish your new base container image to your container registry. Once you publish it you can also do a quick CVE scan to see what your results are.

In conclusion, for the amount of effort (1.5 hours) involved in refactoring to a new base container image, this was totally worth the effort. In return for this time investment, I’ve reduced 100% of my container CVEs which would fulfill any compliance or security requirements I may run into (especially in the public sector.) When compared to the alternative of justifying or finding remediation options for CVEs, this approach is a no brainer. I’m excited to try out other applications that are having similar base image issues and make the push to Alpine in the future to help secure my applications. If you’ve heard of Alpine Linux and haven’t given it a try, I hope this article pushes you to give it a try.

Additional Links

About Alpine Linux: https://alpinelinux.org/about/
Package Lookup for Alpine Linux: https://pkgs.alpinelinux.org/packages/
Support Alpine Linux on Github: https://github.com/alpinelinux

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.