So Many Tools. Definitely an Unsafe Release.

In 2018, I started watching F1 — and for some reason, I gravitated toward Red Bull Racing. Maybe it was the branding, maybe the ski-adjacent energy. Either way, I stuck with them through the Verstappen years: aggressive starts, a few too many crashes, and eventually a long stretch of dominance built on control, consistency, and timing. I especially enjoyed seeing the Constructors’ Championship finally come together with the addition of the Mexican.

Red Bull Technology HQ — back then, I understood the branding a lot better than the build process. Same with AppSec.

That same year, I pivoted into sales engineering — specifically in application security — when I joined Veracode. I didn’t know what a CWE was or why it mattered, but I learned fast. By the time I left in 2021, I was running secure coding sessions with developers, training them on OWASP fundamentals and classic CWE issues like CWE-80, CWE-89, and CWE-117. I even flew to Malaysia to help dev teams figure out why their Jenkins pipelines kept breaking. Few things piss off a team more than a broken build they can’t explain.

I started exploring cloud security back in 2021 — not as a résumé move, but because I wanted to understand the systems all these tools were running on. I began with Docker and worked through the Linux Foundation Certified Sysadmin course — easily the hardest technical training I’d done at that point. KodeKloud and Mumshad Mannambeth kept me going, especially when I needed a break from dry docs and just wanted to try things. I got more comfortable in the terminal, learned just enough vi to survive, and leaned heavily on Google like everyone else. That foundation helped me pass both the CKAD and CKA — and somewhere along the way, I realized I’d finally found a part of tech I actually thought was cool.

If you’ve ever seen an unsafe release in F1, it’s obvious — fast, risky, and usually followed by a penalty. We’ve seen it at Red Bull a few times this season. The thing is, we’ve got all the tools to prevent it — in racing and in security. The harder part is knowing which ones exist, how they work, and where they actually help.

When I joined Sysdig in the fall of 2024, runtime security finally clicked. I’d seen scanners and SBOMs before, but Falco showed me what it meant to detect threats from inside a running container — and that detection could happen in real time, not just during the build or deploy phases. That also tied in with what I’d picked up from Offensive Security training, especially around container escapes and privilege abuse. The kind of behavior I’d assumed was hidden was suddenly visible in real time.

After that, I started exploring other CNCF and eBPF-based tools to see what else was out there. The project landscape looked like the logos on an F1 car — layered, fast-moving, and a bit chaotic. I focused on the runtime and Kubernetes side first, testing out Tetragon and Tracee to see how they compared with what I already knew from Falco. I wanted to understand how they actually behaved in my own K8s cluster. After a few months, that curiosity started shifting toward the lesser-known end of the CNCF spectrum. Some of that came from the CNCF booths and talks I saw around KubeCon London — where I first saw KubeArmor mentioned. That led me to check out a few more sandbox and incubating projects: KubeArmor, Kyverno, and Kubescape. At that point, I wasn’t looking to validate anything — I just wanted to see how these tools worked and where they might fit.

Just the security section of the CNCF landscape — and it already looks like an F1 car’s livery.
Image credit: CNCF Security Landscape

Over the last month or so, I’ve been digging deeper into these projects — some more than others — and started building out small test harnesses to try them in repeatable ways. That quickly turned into documenting what I was seeing: setup details, detection rules, enforcement behavior, and how they actually behave in the cluster. I began with a focused look at KubeArmor and Falco, which you can explore in this GitHub repo, and I’ll be continuing that effort with more tools over time.

🔐 KubeArmor: Blocking AWS Credential Access

A simple KubeArmor policy to block access to AWS credentials — and a quick script to simulate and validate the block in a test pod.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: aws-credential-access-block
  namespace: default
spec:
  severity: 5
  message: "Blocked access to AWS credentials"
  selector:
    matchLabels:
      app: demo-kubearmor
  file:
    matchDirectories:
      - dir: /root/.aws/
        recursive: true
  action: Block

#!/bin/bash

POD_NAME=aws-credential-access-block
POLICY=aws-credential-access-block

echo "[*] Cleaning up any existing pod and policy..."
kubectl delete pod $POD_NAME --ignore-not-found
kubectl delete ksp $POLICY -n default --ignore-not-found

echo "[*] Applying KubeArmor policy..."
kubectl apply -f rules/kubearmor/creds/aws-credential-access-block.yaml
sleep 3

echo "[*] Launching test pod with fake AWS credentials..."
kubectl run $POD_NAME \
  --image=busybox \
  --labels=app=demo-kubearmor \
  --restart=Never \
  --overrides='
  {
    "spec": {
      "containers": [
        {
          "name": "demo-container",
          "image": "busybox",
          "command": ["sleep", "60"],
          "volumeMounts": [
            {
              "mountPath": "/root/.aws",
              "name": "aws-creds"
            }
          ]
        }
      ],
      "volumes": [
        {
          "name": "aws-creds",
          "emptyDir": {}
        }
      ]
    }
  }'

echo "[*] Waiting for pod to be ready..."
kubectl wait --for=condition=Ready pod/$POD_NAME --timeout=20s

echo "[*] Attempting to access /root/.aws/credentials (should be blocked)..."
kubectl exec $POD_NAME -- sh -c 'touch /root/.aws/credentials' || echo "✅ Block confirmed."

echo "[*] Cleaning up..."
kubectl delete pod $POD_NAME --ignore-not-found
kubectl delete ksp $POLICY -n default --ignore-not-found

echo "[*] Done."

I’ll also be extending this into some of the security areas I already know well — like Static Application Security Testing with Semgrep and Dynamic Application Security Testing with Nuclei — especially since both are built around YAML and make experimentation easy. What started as curiosity during KubeCon London has turned into something closer to a working hobby.

I'm still figuring this stuff out — one tool at a time. Lately, I’ve been watching my kid obsessively take apart and rebuild Lego F1 cars — specifically the Williams and Haas set. And honestly? That’s what this feels like. Pulling apart all the pieces, trying to put them back together — without the instructions. Hopefully it's not a Haas result.