is there such a thing as a linter for Dockerfiles? i went on a hunt for one and found this docker-compose-linter, which was unexpected and absolutely welcome. the linter, however, is a topic for another day. i bring this up only because it was in the developer’s write-up of this linter that i discovered KICS, a security testing service for infrastructure-as-code.

why KICS?

up until now, i have only vaguely considered how to tighten up security in containerization. i routinely set up rootless mode for Docker when i spin up a virtual machine (VM) where i will not run containers requiring root privileges. i try to minimize attack surfaces across the tooling i use, but i have yet to take a deep dive into how best to lock everything down.

security matters, and i want to be no slouch about it.

KICS, or Keeping Infrastructure-as-Code Secure seeks to do exactly this. it supports a number of platforms serving as infrastructure deployment—i.e. Docker, Kubernetes, Terraform, etc—as well as support platforms for deployment provisioning, i.e. Ansible. as i’ve been working more and more with Docker and Ansible, this caught my attention.

the general idea is to set up the service as early as possible in development and test your deployment files. KICS runs queries against a number of known vulnerabilities specifically targeting containerized applications and returns a set of warnings where potential vulnerabilities may exist in your code. this provides you with the opportunity to rewrite, refactor, or replace it with code written to incorporate better security practices.

how am i using KICS?

for example, to test it out, i pulled the KICS Docker container and mounted my Ansible collection into it for testing:

docker pull checkmarx/kics:latest
docker run -t -v "/full/path/to/ansible_collections/ephemeralrogue/bookworm":/path checkmarx/kics scan -p /path -o "/path/"

i just loaded the whole damn project. KICS ran queries against all of my files and this is what it spit out:

Unpinned Actions Full Length Commit SHA, Severity: LOW, Results: 1
Description: Pinning an action to a full length commit SHA is currently the only way 
to use an action as an immutable release. Pinning to a particular SHA helps mitigate 
the risk of a bad actor adding a backdoor to the action's repository, as they would 
need to generate a SHA-1 collision for a valid Git object payload. When selecting a 
SHA, you should verify it is from the action's repository and not a repository fork.
Platform: CICD
CWE: 829
Learn more about this vulnerability:
https://docs.kics.io/latest/queries/cicd-queries/555ab8f9-2001-455e-a077-f2d0f41e2fb9

and this is how i learned you should use the full length commit hash for actions in your automated workflows. the solution to this particular vulnerability comes straight from GitHub’s docs.

once i figured out how to grab the full length commit hash for the version of the ansible-lint action i was running, it was a simple matter of updating the workflow yaml and running it through KICS again. these were the results:

Results Summary:
CRITICAL: 0
HIGH: 0
MEDIUM: 0
LOW: 0
INFO: 0
TOTAL: 0

sweet! this, of course, is not the end-all to addressing security concerns, as there are best practices to incorporate in other ways, but KICS at least provides me with a way to tighten up my code without having to deep dive into CVEs.

automating KICS

running this locally and addressing these issues as i’m writing is fantastic. i’ve already loaded the scripts into my Warp Drive for easy access to run the container against directories and single files. but what about implementing KICS in CI/CD? in every single project i boot up, i set main as a protected branch and require PRs to update it, even for myself. i generally have a linter run as a check, and now that i know about KICS, i want to set this up as a status check before a PR can be merged. conveniently, there’s a GitHub Action for that.

creating the workflow was fairly straightforward:

name: KICS Security Scan
on:
  pull_request:
    branches:
      - main

jobs:
  security-scan:
    name: KICS Scan
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout repo
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
        # notice the use of full length commit hashes? i learned my lesson.
      - name: Make results directory
        run: mkdir -p results
      - name: Run KICS Scan
        uses: checkmarx/kics-github-action@94469746ec2c43de89a42fb9d2a80070f5d25b16
        with:
          path: .
          platform_type: ansible
          token: ${{ secrets.GITHUB_TOKEN }}
          output_path: results/
          enable_comments: true
          enable_annotations: true
          # with the GITHUB_TOKEN and setting comments and annotations to true,
          # KICS will provide comments in the PR discussion and make notes alongside the code,
          # a la code review.
      - name: Display KICS Results
        run: |
          cat results/results.json

i also learned how to make use of the GITHUB_TOKEN option. never having used this before, this was a point of fumbling for me, until i figured out i didn’t actually have to save the token as a repository secret, that the action would pick up on it automatically.

so now, when i submit a PR in ephemeralrogue.bookworm, two status checks will run: ansible-lint, and KICS. i also add KICS to the list of required status checks.

what’s next?

with regard to this particular service, guess what my ass is putting on the TODO list? that’s right: time to update the workflows for every project.

i should, perhaps, make a note that i’m writing this post out sheer excitement for this service. i’m not getting paid, no one’s twisting my arm, hell, no one even asked me to do this. i just think this thing is so fucking cool, it wasn’t enough for me to just use the damn thing. i wanna tell everyone about it now.

anyway, that being said, my spare time in evenings and over the weekend will be spent doing two things:

1. replace versioning with full length commit hashes in existing workflows, and

2. add a KICS workflow where containerizing files—Dockerfiles and Compose files—appear.

should be fun. wish me luck.