Skip to content

CI/CD

  • in CI/CD
  • 7 min read

Harden your GitHub Actions Workflows with zizmor, dependency pinning, and dependency cooldowns

It's been a crazy week (or weeks?) for a lot of people with several supply chain attacks. They all seem to have originated from the compromise of trivy (ironically, trivy is a security scanner). I wanted to understand how they initially gained access to the secrets used in their GitHub organization and found that there was an earlier attack that targeted GitHub Actions workflows of open source projects.

Looking at the details of how the secrets were extracted I noticed that they all used similar techniques. And, unless I missed something, it is through template injection and unsafe pull_request_target triggers. This could be avoided because all of those vulnerabilities (and more) can be found by zizmor, a static analysis tool for GitHub Actions!

The problem is that, unfortunately, GitHub Actions is NOT secure by default1. One would think that when following the official documentation you end up with workflows that are secure and can not be exploited. Last year, I came across zizmor and upon checking my workflows it pointed out several problems that I was quite surprised to find out about.

Of course, GitHub should make Actions more secure by default2. And it seems that the latest attacks have finally helped to make some progress in that direction. GitHub have published a security roadmap for GitHub Actions and are looking for feedback from the community.

Until that happens, what can you do right now to harden your GitHub Actions workflows?

  • in CI/CD
  • 4 min read

Linting Markdown files in GitLab CI

A while ago I was looking for a way to lint Markdown files and came across markdownlint in my search. There are two CLI tools for it, markdownlint-cli and markdownlint-cli2. Based on the comparison and rationale by one of the authors I gave markdownlint-cli2 a try first.

It is node-based and has lots of supported ways of invocation, such as a pre-commit hook, works well with the markdownlint vscode extension, and can be run as a container (including an image containing custom rules).

We are using GitLab which has code quality scanning support. You can import code quality results from a CI/CD job. Depending on the tier you have, you can see code quality findings in various places in the merge request UI helping the merge request author and reviewer(s). The code quality findings are provided as a JSON file during a CI/CD job. The report format is based on the CodeClimate report specification.

There was unfortunately no support for this yet. At first, I wrote a custom formatter that lived in our private repo. But instead of leaving it buried in a private repo, I wanted to make it available to all our own repositories and the markdownlint-cli2 community. I checked if there was appetite for integrating this into markdownlint-cli2 and ended up contributing a code quality formatter. It is published as an npm package: https://www.npmjs.com/package/markdownlint-cli2-formatter-codequality.