Ask an engineering or infrastructure team what is happening inside their CI/CD pipeline at runtime. The answer is usually a blank stare. Artifact signing, SBOMs, and pinned Actions SHAs matured. Runtime insight into the job itself lagged behind.
The image signature said yes. Provenance said GitHub Actions on main. The image still shipped with a build that opened the wrong sockets and ran a binary nobody named in the workflow. That is not a signing-tool bug. That is a missing link in the chain of trust.
If you are still using classic GitHub PATs in your environments "just for pulling, read or packaging," you are not being pragmatic. You are accepting forever access as normal. That is a culture problem. Tooling only follows.
Publish returns ack. Consumer never sees the message. Restart a pod and a stuck queue suddenly drains. Realtime join works on one pod; another user never sees it. Websocket adapter events vanish depending on which replica you hit. Same cluster. Same Service DNS. Different JetStream stores. That is the smell.
Do you even know the supply chain risk your Helm charts carry? I bet you don't.
best bet, you are still not rotating your DB passwords and tokens across your infra, but if the software integrations you use, has a stable passwordless option, i think you shouldnt keep a static credentials option then?
kubectl get pods is fine. kubectl describe is fine. Then you hit kubectl logs on a pod that just landed on a Karpenter node and get 401 Unauthorized. Same cluster. Same context. Pods on the system pool still give you logs. That split is the smell.
On EKS, "run Karpenter" is mostly: chart, IRSA, NodePool, EC2NodeClass. On AKS the same sentence hits a wall of prerequisites Microsoft already documented. Then a quieter wall nobody puts in the getting-started: regional vCPU quota.
Your audit logs are quiet. Falco did not fire. The pod filesystem looks clean. And the threat actor is still in the cluster.
Every container security program ends up doing the same three things: scan the image with Trivy in CI, sign it with cosign, put up a dashboard that counts CVEs. Then they call the problem "in progress."
That checklist is the easy 20% of the work. It makes a lot of noise but cuts very little risk.
Your team has pinned every third-party action to an immutable SHA. Runners are GitHub-hosted, ephemeral, isolated. Someone ran zizmor once and filed a ticket. The posture feels done.
On an engagement I worked alongside Olakojo testing a product. Between Ola is one of the best offensive security engineers in this space, and watching him work is a lesson in patience: he does not spray exploits and hope. He reads the app, finds the innocent looking path, and walks in through the front door everyone believed was secure.
A Reddit thread on r/devops stuck with me: someone at a 600-developer org with 2,000 repositories, Okta pushing users via SCIM, was redesigning RBAC and asking whether GitHub teams could realistically be managed with IaC. The replies split fast: Entra groups, access-request tickets, safe-settings, Terraform, and one blunt take: "Don't. Unless you have a full team of Terraform experts."
If you stay in this space long enough, you'll one day face real incident before you retire, pivot, or quietly stop answering pages. Dont let it catch you off guard, compose and face it, haha, its your turn.
Every team generating an SBOM and calling it done is doing the security equivalent of buying a fire extinguisher, putting it in the closet, and never reading the label.
A rabona is not the obvious pass. You wrap your leg behind the standing one, hit the ball at an awkward angle, and somehow the play opens up anyway. VPN vs Zero Trust feels like that at first, same pitch, different move entirely.
Cloud costs at early stage startups rarely spiral because of recklessness.
They spiral because the team was moving fast, the architecture made sense at the time, and nobody had the bandwidth to revisit it.
By the time the bill becomes a problem, the decisions are already baked in.
I have been on both sides of this, burning through it personally, and leading teams trying to unwind it before the runway ran out. Here is what has actually worked.
Cloudflare Workers has become the go-to platform for deploying edge applications. It's easy to deploy, wrangler deploy and you are up.
If you've been following my journey with HashiCorp Vault on EKS, you've seen me talk about automating backups and setting up TLS. But as things scaled, I realized that detached manual processes and terraform/tofu-managed manifests were becoming a major friction point.
If you've been following my content, you know I'm big on IaC security. I've written about encrypting your OpenTofu state files before - because let's be honest, downloading unencrypted terraform state files dangling around has been a goldmine for attackers.
Yeah, the thought process must have crossed your mind too, deploying Helm charts via ArgoCD apps. That feeling when you can finally breathe without another long hour of tofu apply or terraform apply for a minimal change to your Helm chart values.
Scaling DevSecOps without burnout: how I moved from manual security reviews to AI-assisted recommendations that empower product teams.
In 2025, are you still embedding RDS database passwords in your app? If your software supports stable passwordless authentication, switch to it. It’s more secure and simplifies credential management.
Sooner or later, your Elastic Kubernetes Service (EKS) Cluster will run out of IP allocation for your workloads, pods and all.
A lot of uncertainty this year fr fr. Like, A LOT lot. But we move.
Tried many things i feared trying in the last two years
Most internal web apps I have seen are deployed to the public internet. The assumption is usually that the app is secure enough, but the network layer is still exposed.
Have you ever faced that dreaded moment when your EKS nodes suddenly go into a NotReady state? If you're managing an Amazon Elastic Kubernetes Service (EKS) cluster, this scenario might be all too familiar. While checking cluster logs gives you some insight, sometimes you need direct access to the nodes themselves.
Look, I get it. Everyone is using Cosign and Rekor for container signing these days. I've used it myself (check out my previous post if you're curious). But when you're working on private projects, using Sigstore's public Rekor instance isn't really an option.
I must say you shouldn't bet against open-source software, even when Terraform was still open-source, the ability to have state encryption was not available but was available on their Terraform cloud.
best bet, you are not rotating your password and tokens across your infrastructure and deployment but if the software you use has the passwordless authentication option and it's stable why not go for it?
We try, next year we go again. ✌🏽✌🏽 E go be.
You have your app deployed on an EC2 instance via nodes on EKS and this app needs to access/interact with files stored in an Amazon S3 bucket.
You've probably gotten to a point where you need to manage multiple clusters using GitOps, knowing that managing the argocd instance itself can be considered tedious or painful, haha, meaning you sure do not want to install new argocd instances on other new Kubernetes clusters.
You have deployed resources on AWS and hardened the application layer, but the network layer is often overlooked. If an EC2 instance or Redis node ends up in a public subnet by mistake, VPC Flow Logs are the fastest way to detect unexpected traffic.
In my past article about signing container images, got some comments which led me to dig into the keyless signing of container images.
