API’s from Dev to Production — Part 4
Welcome to Part 4 of this blog series that will go from the most basic example of a .net 5 webapi in C#, and the journey from development to production with a shift-left mindset. We will use Azure, Docker, GitHub, GitHub Actions for CI/C-Deployment and Infrastructure as Code using Pulumi.
In this post we will be looking at:
- Add container scanning to our GitHub Action workflow
- Resolve security vulnerabilities
TL;DR
We add the Azure Container Scan GitHub Action to our actions’ workflow file, before pushing the container image to our registry. Add a group and user to our Dockerfile and use the USER command to specify the user for the process to run; ensuring our copied files can be accessed by this user. The security attack surface is reduced by running as non-root, and this is raised in CIS; the linting provided by Dockle. We resolved some slightly older CVE’s as examples; these can be raised by Trivy and can be allowed through or not based on configuration. Both Trivy and Dockle are wrapped by the Azure Container Scan GitHub Action.
Introduction
In Part 3 we were able to get into GitHub Actions and build and push our Docker image to the GitHub Container registry. This is a great start, we are producing a Docker image in CI and it’s a consistent image, however, what about vulnerabilities?
Requirements
We will be picking-up where we left off in Part 3, which means you’ll need the end-result from GitHub Repo — Part 3 to start with.
If you have followed this series all the way through, and I would encourage you to do so, but it isn’t necessary if previous posts are knowledge to you already.
Vulnerabilities
A software vulnerability is a glitch, flaw, or weakness that is present in software or in an Operating System. CVE (Common Vulnerabilities and Exposures), contains a list of records each containing an identification number, a description, and at least one public reference — for publicly known cybersecurity vulnerabilities.
CVE Records are used in numerous cybersecurity products and services from around the world, including the U.S. National Vulnerability Database (NVD).
There are many open source and commercial tools specifically designed for CI purposes; to be used before pushing a Docker image to a container registry. This can ensure any CVE’s of certain thresholds can be caught a build time.
Commercial tools can also scan containers at runtime and apply custom mediating actions.
CIS (Center for Internet Security)
CIS is a community of cybersecurity experts, who have developed CIS Benchmarks: more than 100 configuration guidelines across 25+ vendor product families to safeguard systems against today’s evolving cyber threats.
CIS also produced a list of hardened images — https://www.cisecurity.org/cis-hardened-image-list/
Why is this important?
It’s important because the software we design, build, and ship needs to be secure, we want to ensure safety of our end users’ data and be responsible. We must take security seriously and both CVE and CIS provide a trusted source of information.
The open source community has done an amazing job of utilising the information and provided fantastic tooling we can all take advantage of.
To continue reading this post, please visit our blog here
