Abdulmalik

You already secure a normal app end to end. Secrets scan. SAST. SCA. Build. Scan. Sign. Approve. Deploy. That is DevSecOps.

Same gates on train and model promote. New artifacts. Poisoned data or an unsigned checkpoint still lands without them. Extra gate software CI rarely names: pin the training dataset by digest.

Skill transfer: DevSecOps to AI security. No GPU needed. Act A is the app stack. Act B is gates on train → registry promote → API, CPU sklearn stand-in. Kubeflow, MLflow, SageMaker: same gates, different knobs. Signing and SBOM / ML-BOM / AIBOM are adjacent.

MLOps is the ML lifecycle. AIOps is AI for IT/ops. Not the same. This post is AI security on ML and LLM pipelines.

Related:

• From signing containers to signing models
• From software SBOM to ML-BOM and AIBOM
• Don't put the token in the agent

You already generate an SBOM for apps and container images. An AI system still leaves two blind spots. The weight pack on disk is not a PyPI graph. The model string your agent actually calls often never appears in pip freeze either.

I treat that as three inventories, not one mash-up JSON:

1. Software SBOM: train/serve packages (cyclonedx-py / Syft) → Grype
2. ML-BOM: CycloneDX machine-learning-model for the pack on disk (weights, hashes, pedigree) → hash-check
3. AIBOM: what the running system calls: local tags, Modelfiles, cloud model IDs in config

Signing the pack and attesting the train job are separate controls. Those live in From signing containers to signing models. Do not treat this as a second signing tutorial.

Related:

• From signing containers to signing models
• SBOM generation is not enough
• Container image SBOM blind spots

At work we kept finding the same miss. Product engineering wired Cursor to GitHub with a PAT in the laptop MCP config. CI ran Claude Code or an internal AppSec agent with GH_TOKEN or AWS keys in the job env. The agent could open a PR or touch S3. Sandbox looked fine. Then a tool dumped env, a log printed the secret, or a prompt-injected step ran printenv. The secret was already inside. The sandbox did not save us.

The fix is not "use OIDC in the deploy job." We already do that. The fix is a visible call path with three named pieces:

1. Agent. Cursor, Claude Code, Copilot Chat with MCP, or an internal AppSec agent in CI. Decides. Sends tools/call. No durable secret in its env.
2. Broker. Separate service. Company remote MCP on ECS / Cloud Run / Kubernetes, GitHub's remote MCP (https://api.githubcopilot.com/mcp/), or an egress / tool gateway such as agentgateway. Secrets live on the MCP task role, server env, or IRSA. Not on the laptop. Not in the agent job env.
3. Upstream. Real api.github.com or AWS API call leaves from the broker. Agent only ever sees tool args and tool results.

Related:

• Eradicate long-lived tokens
• MCP security gateways / cMCP
• You cannot deny every tool and still ship
• MicroVM runners vs supply chain

I already know how to sign containers. Key-based Cosign, keyless OIDC, AWS Signer + Notation without public Rekor. That still applies when the artifact is a model directory. What changed is the shape of the thing I hash.

Signing answers one question: are these the exact bytes a known identity published? That is integrity of the artifact. It does not answer how the model was built, which base it came from, or what packages sit next to it at serve time. Those are separate controls. You do not need an SBOM, ML-BOM, or AIBOM to sign. Inventory is optional and adjacent if you want a bill of materials later. This post owns signing end to end, then shows provenance in CI.

Related:

• Sign container images with Cosign (key-based)
• Cosign keyless signing with GitHub Actions OIDC
• AWS Signer + Notation (no public Rekor)

Product wants the patch before standup. Security wants a gateway that can say no. I have sat between them. Both are right until someone makes it one dial.

Deny every tool and the agent is a chatbot. I have watched engineers stop waiting. They open the IDE on the laptop, shell still on, kubeconfig still in the environment, and they ship from there. Your deny rate looks perfect. Nobody complains. That quiet is the part that gets me. The control did not win. The work left.

Same argument without the table. Let the everyday work through. Fail closed on the three that can ruin your week. Any override dies on a clock. And go find the agent that never hits the gate.

Allow the shell because the tests will not run, and you handed a confused deputy a production write. I already wrote that one up: when your bot becomes the payload. This is the deal I will defend when both sides are in the room.

You cannot deny every tool and still ship. Sort them by what they can break. Shell, secrets, and prod write fail closed. Read stays. A write that can only touch the PR branch stays. Take those away and you do not have a PR agent. You have a linter with opinions.

You ship an outer agent that plans. It spawns a "helpful" inner agent to dig, summarize, or call tools. Product demo looks clean. Trust model does not: classic confused deputy, just with LLMs.

The inner agent is often the one with broader tools, longer memory, or the system prompt that names secrets and schemas. Untrusted content does not need to jailbreak the outer model. It only needs to steer the inner one into echoing what it already knows, or calling a tool the outer agent would never have been allowed to call.

Your nested helper can become the payload. Prompt leak. Tool/schema leak. Same family of failure as approving an MCP server once and hoping every later tools/call is fine (MCP gateways).

Most access request "systems" are a scavenger hunt. Ticket portal for some tools. Slack DM for others. A spreadsheet for the weird ones. Someone with admin rights eventually clicks Approve in a console you do not have. The requester waits. The approver forgets. Onboarding docs live somewhere else.

The worst option is the DM. Almost no trail of when it was asked, why it was needed, or who said yes. That is a time bomb for offboarding, incident response, compliance, and the 2am question: who has maintain on that repo?

The fix is not a prettier portal. Treat access request as a product lifecycle: catalog → route → grant → onboard. Put it where the team already works. Slack for SaaS catalogs. GitHub Issues for repo and org roles. Same product idea either way: who, what role, why, who approves, audit trail.

AWS shipped GuardDuty AI Protection as GA in mid-July 2026. If you already run Bedrock or SageMaker AI and GuardDuty, this is the protection plan that finally looks at model invocation data events instead of only management-plane noise.

It is not "AI security done." It is a specific data-source plan with three finding types. Know what it watches, how to turn it on, and what to do when Low severity findings show up. Then know what it will never see.

Teams buy Firecracker-/Kata-backed runners (or DIY) and talk like the CI supply chain problem is closed. Hardware isolation. Fresh VM per job. Tear it down. The vendor deck lands. The budget conversation moves on.

A microVM protects your host from the job. You still have to protect the job from the supply chain.

Your engineering, infra, or security team is wiring agents to tools inside real environments: GitHub, Stripe, Slack, cloud APIs, filesystem servers, whatever the agent needs to act. Same session. Fine.

The quieter question is MCP gateway security: once those tools are reachable, who is actually allowed to say no before the upstream runs?

An MCP security gateway sits between the agent client and upstream MCP servers. It evaluates each tools/call against policy (allow or deny), keeps an audit trail, and optionally attests that path in a TEE. Raw MCP is the protocol and the catalog. The gateway is the control plane that can refuse a specific call before credentials, files, or APIs get touched.

That is different from a dumb reverse proxy that only terminates TLS or multiplexes routes. Auth at the door is not authz on the tool. Approving an MCP server once is not the same as deciding whether read_file on .env should ever leave the client.

I used to treat Vault like a snowflake appliance: click init, paste root token, vault write policies by hand, openssl for TLS, Terraform manifests for backups. That series still lives on this blog. Production taught a sharper split.

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 locked Actions deps 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 locked every third-party action (or pinned full commit SHAs the old way). 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.

Part of the ArgoCD series: install with Terraform, multi-cluster, common issues.

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: From One Engineer to Enabling Every Product Team

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.

Problem: pods stuck Pending because the VPC CNI has no more IPs (not enough addresses, failed ENI/IP assignment). Fix in this post: secondary VPC CIDR + VPC CNI prefix delegation, without rebuilding the cluster for IPv6.

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.

This post is AWS Signer + Notation for private ECR signing. It is not Cosign, and it does not use Sigstore's public Rekor.

• Cosign with your own keys: Signing container images for trust assurance
• Cosign keyless via GitHub OIDC: Cosign keyless signing with GitHub Actions OIDC

(URL note: the live slug still has a historical typo, aws-signerion. The corrected path redirects here so old links and Search Console entries keep working.)

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.

Short answer: use Atlas / MongoDB IAM authentication (authMechanism=MONGODB-AWS) with an EKS IRSA role on your pod's service account. The driver picks up the web identity token. No static DB password in the env.

Azure twin (Workload Identity + MONGODB-OIDC): MongoDB passwordless on AKS.

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.

For the longer community story behind the engineering posts, see Leading Communities.

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.

Been following the tech communities in Ekiti from 100 Level, passionate about every bit of it, the way I swiftly leave classes to the Tech Hub even made my colleagues nickname me "Techub".

But then there was no clear path, no focus, looking around there were no cyber security communities, so what was I doing? I joined the dev communities, going to every event just to take the swag and yes learning too.

This post is Cosign keyless via GitHub Actions OIDC (Sigstore Fulcio + Rekor). Not AWS Signer, and not the older key-based Cosign flow.

• Key-based Cosign walkthrough: Signing container images for trust assurance
• Private AWS path without public Rekor: AWS Signer + Notation

In my past article about signing container images, got some comments which led me to dig into the keyless signing of container images.

Okay, you've moved your infrastructure provisioning from visiting the console page and now adopted IaC ( Infrastructure as Code) for provisioning your infrastructure using Terraform.

So along the way, you discovered that you will need some sensitive credentials like GitHub token to use with aws amplify, datadog API and key deployments?

So you've moved your organization's secret management process to Hashicorp Vault on Kubernetes? everything is working well, but you are about to promote to production, this brings a lot of questions about stability, recovery and fully operational vault servicing your deployments.

What this is: Terraform to put Karpenter on an existing EKS cluster (policy, IRSA, instance profile, Helm), then provision nodes that match your workloads. If you want Cluster Autoscaler instead, this post is not that path.

Struggling to pick the right autoscaler for your Kubernetes cluster? Trust me, I get it. With all the options out there, choosing between Cluster Autoscaler, Karpenter, and others can be overwhelming.

Here's the deal - while both Cluster Autoscaler and Karpenter are backed by AWS, I've found Karpenter to be consistently faster at both scaling up and down. Let me show you how to set it up.

Install ArgoCD with Terraform: deploy the argo-cd Helm chart to an existing Kubernetes cluster, connect a private Git repo over SSH, create an Application, and optionally wire a GitHub webhook so sync is not stuck on the 3-minute poll.

This is the day-one install path. Already running ArgoCD? Jump to More ArgoCD on this blog for issues, multi-cluster, and Helm secrets.

When it comes to graceful shutdown, signal forwarding, and reducing attack surface in containerized environments, an init process belongs in the conversation. The two smallest options are dumb-init and tini.

When you are preparing your vault environment for production, you would want to implement the end-to-end tls setup as stated in the hashicorp vault production-ready documentation.

Setting resource quotas such as CPU and memory limits/requests is easier said than done.

But why do you need this in the first place?

hello everyone, okay, so I did something recently with GitHub action, re-wrote and optimized a workflow of 900+ lines back to 200+

This is the key-based Cosign post (you manage signing keys). Related:

• Cosign keyless + GitHub Actions OIDC
• AWS Signer + Notation (no public Rekor)

Hii 👋, I am sure you want peace of mind too, haha

Well, there is no way you would be discussing container supply chain security without talking about the signing of container images.

You are probably handling secrets in Kubernetes like this today:

Yeah, being doing the CI/CD implementations via github workflow lately and I am also trapped in the process of making commits to trigger the workflows or better still making empty commits, haha.

Almost everyone knows how to use .gitignore, the git file that helps in keeping sensitive files like .env out of the tracking, commit, and pushing process, and also unwanted folders like node_modules and all.

But do you know secrets, hardcoded credentials, and API aren't easy to deal with using a .gitignore file? you don't want to keep your config.js or config.go file out of the commit process, these are essential files to your project.

For someone who just started writing Go, I have no idea about //go:embed feature which came with the released version: 1.16.

A project I was working on recently led to discoveries.

Documentation is a vital part of any open source project or software.

It is the entry point or a fall back option for users of any open source project or software to read usage, installation instructions, to fix issues and learn more about the project.

Before we start, I will like to say, All these programs listed are not mandatory for you to contribute to open source.

But you can contribute to open source even if you don't get selected for these programs, you can always contribute to open source programs anytime you want.

I joined the OSCA Africa Open Source Challenge 2021 which Started on the 16th of August 2021.

Having your Linux environment set, is also one of the essentials to getting your assignments done in any pentesting, security class or day to day work.

So I started participating in bug bounty not so long and after a lot of read ups and web app practice, I found a stored XSS on quite a big education platform which i was using for learning web development last year.

Yeah, just wanna share to a little story about the bypass of an authentication through source code reading.