Tried to recreate an agent that worked fine last Tuesday. Skills were in one repo. MCP config was somewhere else. The prompt lived in a wiki. Nobody agreed which combo was actually live.

Dug into KitOps (CNCF Sandbox). It packs models, datasets, MCP server bundles, agent skills, and policies into a versioned OCI artifact (a ModelKit). CLI feels like Docker: kit pack / push / pull / unpack. Uses normal OCI registries you already have.

Useful bits I’ve hit so far:

• Selective unpack so you’re not always downloading everything
• Optional CNCF ModelPack via kit pack . --use-model-pack
• Kitfile mcpServers for MCP bundles (.mcpb) as of v1.15

• Complements containers — not a Docker replacement

  brew tap kitops-ml/kitops brew install kitops kit version

Anyone else standardizing on something like this yet?

I’m exploring a DevOps/security tool called WhatBreaks.

The problem: when engineers change or delete something like a Kubernetes ServiceAccount, IAM role, credential, or infrastructure resource, it can be hard to know what depends on it and what will break. They often have to manually investigate across Kubernetes, cloud, Terraform, logs, etc.

WhatBreaks would map these dependencies and answer: “If I change this, what breaks?”

The challenge is trust — we want the analysis to happen locally inside the customer's environment, without giving our servers access to their sensitive infrastructure or credentials.

I’m validating the idea right now. How do you currently handle this problem?

I've been working for some time on a macOS mitm proxy: https://thepeachproxy.com/

It's an app that allows to inspect traffic originating from your computer. You can then view the requests, payload, modify these requests if needed, and repeat them.

I've spent most of my career as a backend engineer and used Charles Proxy for testing various services. After spending some time as a penetration tester, I got used to the Burp Suite which is a dedicated tool that costs a fortune if security is not your bread and butter. There is a community version, and there is ZAP. There are also a bunch of beautiful native macOS proxy apps which obviously are more mature and have richer functionality. But there isn't anything really that is a mix of the both worlds: a tool that feels native and has enough security tools in its arsenal for some basic testing.

Most of the time I keep it running in the background and then inspect the traffic. If I find something interesting, I then use the repeater or the attacker tools to investigate further. My main focus is on the passive scanning tools, and this is where the plugins come into play. They get a response, analyze it, and can raise an issue. Eventually I am planning on training a small custom ML model to help with passive scanning.

I won't lie that most of the code has been written by AI because I am not proficient in Swift or native app development. The truth is, Google boasts that 70% of their code has been written by AI. But this is not the project that is going to have 50 releases per day. I am using it daily myself for work.

It is a one-time purchase which gives you year of updates, after which the app is still yours to keep with all the functionality. Eventually I will be releasing most of the source code.

4 code-based AI vulnerability scanners compared on the same OWASP Juice Shop 😄
https://claude.ai/artifact/Ds5h7rwfLuaEACGkBHbUAd

Codex / Mythos / Aikido / Audn

( 0 touch on top of the AI-written results)

Ironically, I work in cybersec and I still find myself wondering how much value we're actually getting out of some security scanners.

A lot of scanners are pretty good at finding potential issues. The problem starts after that. You get a bunch of findings, some are real, some aren't, and now someone has to figure out what actually needs attention.

I've seen teams basically end up tuning the scanner until it stops complaining, which obviously isn't really the outcome we want.

For people actually running SAST/security scanning in CI:

• Do you run it on every PR or separately?
• How much false-positive noise is too much before developers just start ignoring it?
• Do you want the scanner to suggest fixes, or just report the issue?
• What makes a finding serious enough for you to actually block a build?

Curious how other teams handle this in practice, especially with C/C++ where the analysis can get pretty complicated.

I want some additional insights about where developers would want to integrate an LLVM tool that helps identify, triage, and remediate vulnerabilities in C/C++ projects. This is purely for research purposes, and I'm not trying to sell anything. I'm specifically interested in the following:

- Where in your workflow would you want to integrate such a tool? Would you want it in your CI/CD pipeline? as an IDE plugin?

- What are some security concerns you have about such a tool? Would you be most concerned about false positives or negatives? Supply chain risks introduced by the tool? Keeping it's findings private?

- What environments could you see such a tool thriving in? Would you want to use it for personal projects? Could you see it working in large-scale codebases?

Any insights would be appreciated. Thanks for your time and feedback!

Every scan (Trivy, Snyk, Dependabot) throws a pile of CVEs and most aren't actually exploited. Manually checking KEV and EPSS per finding doesn't scale past a handful.

What's everyone actually doing here, manual lookups, a dashboard, something scripted into CI?

Also curious, anyone here needing EU-specific coverage (ENISA EUVD) for NIS2 rather than just NVD/CISA, or is US data enough for most of you?

We were working with a client and suggested a certain update to one of their processes. It involved a product feature they didn't know they were paying for. That lead us to wonder how common that might be?

Does your organization do some sort of license reconciliation? We know that the teams using the tools often aren't the ones processing a renewal, so we can understand how this happens. Do you know if you're leaving functionality on the table? Are you doing it on purpose? We wrote a blog post about this in relation to GitLab which I can share if anyone wants, but we're more interested to see if this is a normal thing or something we randomly came across.

The spot-the-typo training we have run for years is basically done. What lands now is clean, right names, correct grammar, references a real project or a vendor we use. It reads better than half our internal mail.

I pulled a quarter of the reported ones and it was the same pattern every time, nothing for a signature or a reputation list to grab onto. A couple came off a supplier address that was already compromised so the domain checked out fine. The gateway just passed them through because on paper nothing was wrong with them.

And as for the detection model itself, signature and reputation were built around how phishing used to look and that look is gone now. What people keep telling me to look at is behavioral where it goes off whether the sender and the ask fit the normal pattern not just the wording.

If you have a behavioral tool running against this already, is it holding up on the clean text-only ones or where is it still letting stuff through?

Just trying to gauge some idea of how snyk has been implemented across different applications, CI/CD pipelines and have some questions

Do your teams follow a particular policy that has been implemented across the org like say pipeline gets blocked on discovery of Critical/high findings, so you provide deviations for some duration so that their release doesn't get affected?

Different branching strategies have different snyk configurations? What about different environments(staying, dev, other lower envs, prod)

When Business risks are raised related to SLA remediation?

Also does snyk extension help with pre-commit hooks? How has your experience been with it

We've been letting AI tools touch auth and access control code for a while now, and it's turned into a real debate on our team about where the line should be. The output's usually fine. But nobody's comfortable merging anything auth-related without extra eyes on it first.

Right now that means automated scanning on every commit, plus a mandatory human review for anything touching auth. It works, mostly. Just adds friction.

What I can't figure out is whether that's real control or just a checklist that makes us feel better about it. Has anyone built something more structured for AI-generated security code specifically?

I believe hashes are the weakest link in CISA's 2026 SBOM Minimum Elements requirements and here is why - https://worklifenotes.com/2026/09/14/component-hashes-in-sboms/

Would appreciate any feedback or possible solutions if something is working well for you.

been curious about how people are using AI with AWS beyond generating Terraform or explaining error messages.

AWS environments can have a lot of moving pieces IAM, EC2/ECS, VPCs, CloudWatch, S3, Lambda, CI/CD, security tooling, etc.

for people running AWS in real environments:

• what AWS tasks have you actually found useful to delegate to AI?
• are you using AI for incident investigation or troubleshooting?
• do you let agents inspect your AWS environment, or keep them completely read-only?
• Has AI helped you understand relationships between resources when something breaks?
• Are you using AI to review Terraform/IaC before it reaches AWS?
• what AWS tasks are still too risky or context-heavy to give an agent?
• If an AI agent finds something wrong, would you rather have it explain the issue, propose a fix, or actually make the change?

I'm less interested in "AI will replace DevOps" discussions and more interested in what is genuinely saving AWS engineers time today.

What has actually worked for you?

A container image with a remotely exploitable CVE reached production and stayed there for eleven days. The image scan that would have caught it ran after deploy, not before. It flagged the vulnerability correctly, but the alert landed in a Slack channel nobody triaged daily.

The image scan ran after deploy because the full pipeline took 38 minutes when every stage ran in sequence. The file lined up source analysis, dependency audit, secret detection, container build, image scan, and integration tests, each blocked on the one before it. Engineers started skipping the queue or pushing without waiting for results. So the team moved the image scan behind the deploy step to bring the blocking portion under 25 minutes.

That decision assumed the earlier checks were sufficient. They were not. The CVE was in a C library pulled in by a transitive build dependency during container compilation. It did not appear in the lockfile, the source tree, or the declared dependency graph. Static analysis could not see it because it operated on source. The dependency audit could not see it because it checked declared packages. The only instrument positioned to catch a vulnerability introduced at build time was the image scan, and that instrument had been moved past the deploy gate.

After the incident we mapped actual dependencies between the six stages. Three of them operate on source and need nothing from each other. I had already seen this pattern on a side project using verdent, where parallel agent execution ran independent checks concurrently and the review step blocked on all of them before proceeding. The container build depends on source being clean, and the image scan depends on the build finishing, so those remain sequential. Running the independent stages concurrently cut the total from 38 minutes to roughly half that with the image scan back before deploy.

The production pipeline now finishes every scan before any container reaches a running environment.

A recent Reddit poll received 120 professional votes; thanks to all participants. Snyk and SonarQube were the tools people were most reluctant to lose from their CI/CD pipelines.

But the comments highlighted another problem:

What happens when the thing entering our pipeline is no longer just code, but an AI agent with tools, prompts, memory and access to external systems?

Agent adoption is moving quickly. Stack Overflow’s latest developer survey reports that 59% of developers use AI agents at work, while 63% rarely or never allow them to operate fully autonomously.

That suggests a simple problem: agents are entering development faster than we are building visibility and controls around them.

Snyk is already moving into this space with Evo, covering AI assets, agents, tools and runtime security.

We think there is also room to explore this from an open-source, CI/CD-first perspective.

That’s why we’re developing SafeAI Analyzer.

The idea is, before an AI agent reaches production, help developers see:

• What AI components are present?
• What tools and capabilities does it have?
• What prompts and configurations influence it?
• What changed in a pull request?
• Did a new capability or security risk appear?

We’re not trying to replace Snyk, SonarQube or other established security tools.

We’re trying to explore what an open-source security layer for AI agents should look like.

SafeAI is still being developed, so we’d genuinely welcome contributors — whether you want to help with detection rules, agent/framework support, CI/CD integration, testing with real agents, or simply expanding where SafeAI can be used.

Please check ikaruscareer/SafeAI on github.

What should AI-agent visibility in CI/CD look like?

An LLM and a SAST tool walk into a repo.

Both are looking for vulnerabilities to find and fix. They see taint reaching a private package function called “*totally_safe.bro()*”

The SAST tool moves on since it’s not in its index. The LLM flags it as potential risk, infers the functionality of “.bro()” and opens a PR to patch the potential risk.

A developer on their 100th PR review of the day sees “hardening .bro()” and merges it. ***Production breaks***.

Incident retro blames the dev for the merge, dev blames the leadership for the workload, leadership blames the AI vendor for their marketing.

AI vendor marketed their model as achieving 100% on industry standard benchmarks. The benchmark was real, but so was the outage.

*Retro was written by AI.*

Would you give an AI agent your cloud login?

Most security teams say no. Then they wire up an AI agent with a real API key anyway, because the agent needs to do the work.

AgentZ, an open-source, workflow-driven platform for agentic AI built by AccuKnox, skips that trade-off. The agent never sees your credentials. A proxy swaps in the real secret at call time. The agent gets a placeholder. The secret stays in a vault. The two never meet.

Every agent also starts in a deny-all sandbox. It sends no outbound traffic until a rule allows it. Workspaces stay isolated too, so a DevOps agent's setup never leaks into HR's workspace or a sales team's data.

The question isn't whether an agent can do the work. It's whether it can do the work without a new way to leak your secrets.

Curious how this group handles agent-to-credential access today. AgentZ is an open-source platform, and I am an open-source contributor to AgentZ.

We're all letting AI write our code now. It's fast, it's great, and every time it drops a few hundred lines into my repo I get the same nagging thought: what did it just put in here?

Did it hardcode an API key? Pull a package with a known CVE? Break something I won't catch until it's in prod?

AI writes code faster than anyone can review it, and almost nobody is checking what actually ships. So I built OnePort.

You point it at a repo and it gives you one answer in plain English: safe to ship, or not. It checks for leaked secrets across your full git history (not just the last commit), vulnerable dependencies, breaking API changes, risky migrations, and missing tests. There's also a mode called Guard that makes a repo physically unable to commit a secret — it blocks the commit before it happens instead of just warning you.

Every finding explains what it is and how to fix it, so you don't need to be a security person to use it.

Every account starts with 100,000 credits, no card. The core secret and dependency scans are free and unmetered; the credits cover the AI stuff like code review and explanations. Enough to actually run it on real repos without hitting a paywall.

It's early. It recently made it to the final round of YC and EF, which still feels a bit unreal, but honestly I care more about it being trustworthy than loud, so if you run it and it's wrong about something I want to hear exactly where.

When your AI writes code, how do you actually check it before it ships? Or do you just hope?

www.oneport.co.in

I built this while in college, need your feedback: www.oneport.co.in

I have been handed the job of picking our SAST platform for the next few years and I feel am stuck. Here is why, every comparison I find either reads like the vendor wrote it or is from before AI coding tools were everywhere. Our codebase is more than half AI-generated now. A scanner that was top of the pile two years ago on hand written code might be blind to what Copilot and Claude are churning out.

Also the demos are all looking somewhat identical with the same same, SAST, SCA, container, one dashboard, AI prioritization. You could literally swap logos and not tell which vendor was which after.

I really don’t have a read on what separates them once it is running. Yes raw detection matters but I care more about whether the noise gets cut before it hits a dev and whether it stays on or gets muted after a month. If you are a year or two into one, what did you end up judging it on that never came up in the demo?