diff --git a/content/posts/docker-hardening.md b/content/posts/docker-hardening.md
index 01fc0aa..4f992b8 100644
--- a/content/posts/docker-hardening.md
+++ b/content/posts/docker-hardening.md
@@ -44,7 +44,7 @@ For these reasons, good practices were established:
 - An image should be rebuilt when the images it's based on are updated.
 
 ### A minimal base system
-[Alpine Linux](https://alpinelinux.org/) is often the choice for official images for the first reason. This is not a typical Linux distribution as it uses musl as its C library, but it works quite well. Actually, I'm quite fond of Alpine Linux and `apk` (its package manager). If a supervision suite is needed, I'd look into `s6`. We can do even better than using Alpine by using **distroless images**.
+[Alpine Linux](https://alpinelinux.org/) is often the choice for official images for the first reason. This is not a typical Linux distribution as it uses musl as its C library, but it works quite well. Actually, I'm quite fond of Alpine Linux and `apk` (its package manager). If a supervision suite is needed, I'd look into `s6`. We can do even better than using Alpine by using **distroless images**, allowing us to have state-of-the-art application containers.
 
 "Distroless" is a fancy name referring to an image with a minimal set of dependencies, from none (for fully static binaries) to some common libraries (typically the C library). Google maintains [distroless images](https://github.com/GoogleContainerTools/distroless) you can use as a base for your own images. In my experience, distroless is an excellent option with pure Go binaries. Going with minimal images drastically reduces the available attack surface in the container.
 
@@ -62,7 +62,7 @@ USER nobody
 ENTRYPOINT ["/my_app"]
 ```
 
-The main drawback of using minimal images is the lack of tools that help with debugging, which also constitue the very attack surface we're trying to get rid of. The trade-off is probably not worth for development-focused containers, and if you're running such images in production, you have to be confident enough to operate with them. Note that the image `gcr.io/distroless` has a `:debug` tag to help in that regard.
+The main drawback of using minimal images is the lack of tools that help with debugging, which also constitute the very attack surface we're trying to get rid of. The trade-off is probably not worth the hassle for development-focused containers, and if you're running such images in production, you have to be confident enough to operate with them. Note that the image `gcr.io/distroless` has a `:debug` tag to help in that regard.
 
 ### Keeping images up-to-date
 The two other points are highly problematic, because most software vendors just publish an image on release, and forget about it. You should take it up to them if you're running images that are versioned but not regularly updated. I'd say running scheduled builds **once a week** is the bare minimum to make sure dependencies stay up-to-date. Alpine Linux is a better choice than most other "stable" distributions because it usually has more recent packages.