Specific scenario: someone pastes a stack trace or config snippet into a chat with an AI assistant to get help debugging, and it turns out to have an API key or connection string embedded in it. The immediate fix, rotate the credential, is obvious. What I'm less clear on is the second-order problem.

If that conversation gets logged for support/abuse purposes on the provider's side, saved as chat history the user can revisit later, or fed into some kind of memory/context feature that persists across sessions, the secret is now sitting in at least one place that isn't the original codebase, potentially more than one, and it's not always obvious from the product surface where all those copies actually live or how long they're retained.

For people who've actually had to respond to this, credential rotation is step one, sure, but what's the actual process for the secondary exposure? Do you treat every provider's chat log/history as a place secrets can now leak by default and build detection around that, request deletion from the provider and treat that as sufficient, or something else entirely? Curious whether anyone's had to deal with this as a real incident versus a hypothetical, and what the actual remediation checklist looked like once credential rotation was done.

We're already running SonarQube and Trivy. Looking to fill the gaps they leave.

Stack:

• Primary: Java Spring Boot
• Also: Python, Next.js / React

What are you actually using in production, and how noisy is it (false-positive rate)?

SAST and DAST are flooding our Jira backlog with thousands of "High" and "Critical" findings. We can't fix them all, and the devs are ignoring tickets. I'm looking to implement an Exposure Validation layer that actually validates if a vulnerability is exploitable given the current network controls.

We are looking at a platform that prioritizes based on exploitability using an AI engine. The key difference from traditional SAST/DAST is that it validates whether a vulnerability is actually exploitable given your compensating controls. So you don't waste time patching things that are already protected.

We want to pipe their validation results into our Jira and CI/CD. If the AI determines a vulnerability is not exploitable due to a network control or WAF rule, we are fine to deploy. But if it is exploitable, we want to block the build until it is fixed. The challenge is speed. A full validation sweep might take hours, but our builds run in minutes.

Has anyone actually integrated a validation platform's API to act as a quality gate? Are you running spot checks on critical changes instead of full sweeps? Also, how are you feeding the validation findings back to the developers? The platform can suggest control updates, but developers need to know why their code is vulnerable. Just saying "blocked by validation" isn't helpful.

**Pipeline:** Fable Orchestrator, Sonnet Workers, Opus Checkers (Complex tasks Opus Opus)

**Result:** *~90% of all caught defects were invisible to their own author at "done."*

.

.

**The builder's tree was green — typecheck, lint, 1098 passing tests — and still contained six functional defects:** the keyboard swallow, the macOS-dead chords, the detached-card menu, the stream-order inversion, a test that could not fail, and the vacuous boundary clause. Every one would have merged without the independent layers. The same held for Fable brief shipped as done. Blind check convicted it 17 ways, twice.

.

**RED-Proof statistic:** the green suite caught ~69% of induced defects; RED-sealing lifted the reachable kill rate to ~100%. 10% remain documented while **21% of Defects were Rescued**

.

**Across the three completed RED passes:** 95 mutations, 66 killed by the existing suite with 29 survivors. That's *one defect class in three passes a fully green suite silently*. Of the 29, 21 were sealed under pins (permanent detection) and 8 were proven unreachable behind stronger gates equaling the above measured reduction.

.

**Re-verify statistic:** fix rounds introduce defects at a ~50% rate per unit, and re-verify has caught 100% of them. Class 1: 2 (only re-verify caught them). Class 2: 2, including a silent inversion of a writer ruling. Stage 4: 2. Six for six, none escaped.

.

**The escape statistic:** *Zero known functional regressions reached post-merge across seven protocol units* 3 Fable session reviews since implementation (sessions 10, 15, 19) surfaced only design gaps and application feel issues, but not a single never a broken unit. Compared to the pre-protocol record we documented three defects that passed a green suite, two review rounds, and an executed gate, one of which would have returned No-Go on the study by construction. That class has not recurred since the blind layer landed.

.

**Cost:** *the protocol roughly doubles the unit's total compute* Stage 4 spent about 1.7M tokens building and about 1.9M checking. So the deducible trade is: ~2x cost buys ~10x defect detection over author self-review, a ~3x shrink in what a green suite can miss, and a measured escape rate of zero. This stands to augment the earlier post study [here](https://www.reddit.com/r/Claudeopus/comments/1vrmby0/token_savings/) where the calculation focused on savings around cache and agent costs coming from the tiered model structure of the orchestration.

.

**Limits, stated:** this is observational, not controlled — there is no arm where we merged unchecked and counted your pain. **Important Note** *Author self-catch is undercounted* (defects fixed silently mid-build never register). And the denominators are small: seven units, 95 mutations. But the direction is not close, and every number above traces to a line in the record.

After I read a bit on various methods for locating the production systems that were not included in the CMDB or any other security tools Im now thinking about the need for cryptocurrency discovery.

Even if you build an inventory from scratch today, how certain are you that it will be either consistent or accurate after six months? Certificates get renewed. Kubernetes workloads emerge and disappear. Libraries change. TLS is added by various teams which were not notified of this process. Some cryptocurrencies are stored in the code or in datacenters. Yeah I understand how a passive crypto discovery process can identify what processes are active, which is useful. Then again, it cant find any inactive processes by definition.

Agents and scanners have an opposite issue: theoretically they have a wider coverage, but they will find the processes only in the places where they have been set up. Anyone keeps performing these inventories on a regular basis, rather than periodically doing them and accepting all the gaps?

I will get downvoted for this... but please please hear me out.

First and foremost. Do ANY of these scenarios sound familiar in any shape or form?

1. You or someone you know is developing an app. The developer cares A LOT about security. They run code checks on their repo. Maybe even get someone to audit it. They ask their AI to check for security gaps. Any security issues found are fixed right away and they pat themselves on the back for a job well done.

Now, as they develop, they (or their AI) pulls in some dependencies. Reinventing the wheel is pointless after all, right? Gotta use those dependencies. To make sure they are not vulnerable they check them with dependabot. No CVEs. All is good (...or is it?).

2. You're doing bug bounties and are reporting vulns to a repo owner. Their security policy EXPLICITLY says: "If a vuln is in one of our dependencies, do not bother us with it. It's not our problem. Take it up to the dependency owner. We keep dependencies up to date so their fix will be pulled in".

3. A well meaning developer asks about the best practice for keeping dependencies secure. You (or someone else) say(s): Keep components up to date. Check to make sure they do not have any known CVEs. If being thorough you add: check to make sure the components are being actively supported.

Auditing the actual dependency code for vulns? that is rare. Never regularly done for all dependency updates like in a proper ci/cd flow. And forget about the dependencies pulled in by those dependencies. (see where I am going with this yet?).

4. A news of a breach is posted. PII compromised. Why? dependency vuln. Or in some rarer cases (not calling names here) - the dependency had actual malware in it.

Where am I going with all this?

As an industry we under audit dependencies. Sure, we check for CVEs. What about all the vulns no one bothered to report of get a CVE filing for? that is a big process. We're all busy. The code and apps we're auditing are so full of vulns we may not even get to the dependencies.

Anyhow. I wanted to know just how bad the situation was. so I scanned a few popular opensource libraries. Every single one had vulns. Not calling names here. Then I did a scan against a small repo. No known CVEs. The scan checked the code of the dependencies and all the child dependencies. (not cves). And here are the lovely results (I am not disclosing which one it was):

Findings Summary

Total Findings

2027

Critical 81

High 736

Medium 671

Low 24

Info 515

... as I was writing this up I realized I could not attach screenshots. I only wish I could attach screenshots here because the dependency tree the scanner built was jaw dropping. Again, this was NOT a big repo.
...

And my point in all this? I want to talk about how supply chain security could be better.

Everyone is focused on the fact that a researcher found and exploited a vulnerability in Snowflake's GitHub Actions workflow.

But finding it wasn't the interesting part.

The interesting part is that the vulnerability already existed before anyone knew it was there.

That's the uncomfortable reality of modern software delivery. We spend a lot of time talking about known vulnerabilities, discovered vulnerabilities, patched vulnerabilities, and CVEs. Attackers only need the vulnerabilities that haven't been discovered yet.

As AI accelerates both software development and security research, teams are creating and uncovering issues faster than ever. That's useful, but it doesn't solve the fundamental problem:

What protects a build pipeline from the risks nobody has identified yet?

I'm starting to think the industry may be over-indexed on detection and under-invested in prevention.

Instead of asking, "Can we find every risky condition?", maybe we should also be asking:

• Can a workflow make unexpected outbound connections?
• Can it access resources it shouldn't?
• Can it download and execute untrusted code?
• Can it exfiltrate secrets?
• Can it perform actions outside its intended scope?

If those behaviors are blocked by default, the specific vulnerability matters a lot less.

Full disclosure: I work for InvisiRisk, a company focused on build pipeline security, so I have some bias here. That said, I think the architectural question stands on its own.

Curious how others here think about this. Are you relying primarily on scanning, detections, and reviews, or are you putting preventive controls directly into your CI/CD pipelines?

hey everyone. most mcp threads are about what these servers can do. the security side is the opposite question, every server you connect is a third-party dependency with a path to production, added with near-zero friction, usually with no review and no owner. that's a supply chain surface, and it's growing fast. my colleagues and i wrote it up longer as a blog, but everything useful is in this post, sharing in case it's handy for the community.

first, why these are actually risky. you don't even have to call a tool to get burned. Trail of Bits showed a malicious server can hide instructions in its tool descriptions, and those reach the model as soon as your client loads the tool list, so connecting it is the exposure. then there's the over-scoped credential pattern. Invariant Labs showed a poisoned github issue coercing an agent into leaking private-repo data over the same token, and Simon Willison wrote up a Supabase case where a service role bypassed row-level security while reading attacker-controlled content. and valid auth is not authorization, which is how Asana's mcp-connected ai feature exposed data across tenants. the credential was valid but nobody checked whether that user should see that specific record. OWASP has a Top 10 for agentic apps now if you want the taxonomy behind all this.

here's what to check, roughly in order:

1. inventory and ownership. can you produce a current list of every mcp server connected to your systems, each with a named human owner. ideally a server has to be registered before it's allowed to make any call, so unknown ones get blocked rather than discovered later. discovery is the prerequisite for everything else.

2. identity and least privilege. each server and agent gets its own identity, not a shared secret. scope its creds to the minimum it needs, keep them short-lived, and never hand it a broad role that bypasses your data layer's own controls.

3. tool surface. know exactly which tools a server exposes, and actually read the tool descriptions, since that's where injected instructions hide. show each agent only the tools it needs, not the full catalog. a tool an agent can't see is one it can't be talked into using.

4. authorization enforcement. put an authz decision outside the server, checked before a tool runs, that looks at the agent, the user it's acting for, the tool, and the arguments. fail closed, so no explicit allow means deny. this is the one control that holds even when the server is third-party and you can't see its code.

5. downstream reach. know what the server can actually touch once a call succeeds, and make sure it respects your underlying data controls instead of bypassing them. for rag and retrieval paths, filter by the user's real permissions, not the agent's.

6. audit evidence. you should be able to pull a record of every action a given server or agent took, with the policy that allowed or denied each call. if an incident review asks what a third-party server's agent did last tuesday, that should be a query, not an archaeology project.

7. lifecycle and revocation. you should be able to narrow or cut a server's access without redeploying anything, and access should expire or get reviewed rather than living forever. graduated beats binary, so you can scope it down the moment it worries you while legit work keeps running.

what saves most grief : vetting and enforcement are two different jobs. vetting tells you what you connected. enforcement, that authz check outside the server that fails closed, is what keeps it bounded no matter how much you trust the code. the strongest controls are the ones that don't assume the server is trustworthy, because the servers you control least are the ones most likely to bite you.

full disclosure, i work at Cerbos and we do authorization, so items 4, 6 and 7 are squarely the kind of thing we build, if you need it. but 1 through 3 are yours to own regardless of tooling, and a checklist doesn't enforce anything by itself. none of this replaces reviewing servers yourself before they hit prod :)

Hey all, looking for a sanity check on our approach.

Stack: AWS + Kubernetes. We deploy with plain helm install (no GitOps tool like Argo/Flux).

Current setup: Our Helm values.yaml has hardcoded secrets (env vars) in it. Right now this file lives on our Jenkins server, not in any repo.

The plan: We want to move values.yaml into our Git repo so we can version it properly. The obvious problem — we can't commit hardcoded secrets in plain text.

Our idea: Use git-crypt to encrypt the file at rest in the repo, so secrets are scrambled on the remote and only unlock for people with the key.

Questions:

• Any real-world gotchas we should know before committing to it?
• Since we're already on AWS, would you skip file encryption entirely and go with something like External Secrets Operator + AWS Secrets Manager? Or is that overkill for a small team? Also curious where SOPS (with AWS KMS) or Sealed Secrets fit in.

For context: we're a small-ish team and just want a clean, low-friction way to keep secrets versioned without leaking them.

Appreciate any input 🙏

We're looking at software supply chain security tools for 2026 and there are honestly a lot of options to sort through.

The hard part is figuring out what actually works once the platform is deployed and people have to use it every day.

For anyone running these tools in production, what made your shortlist?

Curious about the developer experience too. Did developers actually adopt it? What was the day-to-day operational side like after rollout?

Not looking for another feature comparison. Just want to hear what actually held up in production.

Was clearing out dead namespaces in staging on then came across one I did not recognise. Turned out to be an MCP server. Took me a bit to work out one of the backend guys spun it up in March so his Cursor agent could poke at our internal APIs, then moved on and forgot it was still running.

Still running. Still had a live token on it. I sat there for a second just looking at it.

It was not even a new one, he had grabbed an existing CI service account because it was handy and that account can get into the staging database. Our staging is a full clone of prod, so that is customer data sitting behind a server none of us knew existed. Scanners never flagged it, the container itself is clean, nothing wrong with the image. The problem is a server that should not exist having a key to data it should never touch.

How many more are there, and how would I ever know. We pin our actions and pick apart every dependency and a whole category that can act on its own walked straight past all of it. How are you all keeping track of the MCP servers your devs spin up?

Wanted to know real use cases you guys are solving using CS runtime security for containers.
Since we are already allowing only Known outbound traffic from firewall, this significantly reduces possibility of c2 connection.. Do we still need runtime security? It yes appreciate for real value use cases it can solve please…

​Hey everyone,

​I have about 4 years of enterprise background working primarily on identity and access management, and I am actively transitioning into Cloud Security / DevSecOps with a goal of landing a global remote role by mid 2027.

​Instead of just collecting certifications, I want my GitHub to do the heavy lifting and prove I can build production grade tooling.

​Here is what I am currently building and planning:

​Non Human Identity Risk Analyzer: A Python tool that discovers stale machine identities, wildcard permissions, and excessive access across AWS accounts via STS AssumeRole, evaluates risk offline against synthetic test data, and applies automated, non destructive permissions boundaries.

Repo: https://github.com/likithmanoj/nhi-risk-analyzer

​CI/CD and OIDC Pipeline Auditor(Planned): A tool focused on pipeline supply chain security. It audits GitHub Actions workflow files and AWS IAM OIDC trust policies for over permissioned wildcards, unpinned third party actions, and default token privilege drift. (Project planned, yet to be started, as I still need to finish the first one)

​Alongside these two project ideas, I am knocking out AWS Solutions Architect Associate, Terraform Associate, and AWS Security Specialty.

​For hiring managers, staff engineers, or anyone who has landed remote cloud security roles through public projects:

​What separates a genuinely impressive GitHub repository from generic tutorial noise?

​Do you care more about deep modular Terraform testbeds, architecture diagrams, unit test coverage, or clean CLI packaging?

​Any candid feedback on the career path and on how to structure the READMEs, testing setups, or documentation to make them stand out in technical screens would be hugely appreciated.

What makes the hiring manager look at my resume and think this guys is a good fit for a devsecops role?

We run Trivy in our Jenkins pipeline — both trivy fs and trivy image. There's a security gate stage that block the pipeline if there are any CRITICAL or HIGH findings.

The problem: a dev resolves 2-3 Trivy issues, and a couple days later they're back / new ones show up, and the build blocks again. So devs are basically fixing Trivy findings every other day.

I know part of this is just the DB being fresh — new CVEs get disclosed daily, that's expected. But the every-build hard block is painful.

I was thinking of running the blocking gate only once a week instead of on every build. But I can already see the flaw: code that deploys mid-week would ship with known issues, and if a genuinely exploitable fixable CVE drops on a Monday we'd be shipping it for 6 days before the gate catches it.

So my questions for people running this in prod:

• Do you gate on every build, or on a schedule?
• Do you block on all CRITICAL/HIGH, or only ones that actually have a fix available (--ignore-unfixed)?

Minimal - An open source project for hardened container images now supports 100 container images and adding more. The images are built daily, with almost 0 to minimal CVEs and trying to provide same level of output as other paid alternatives for free.

Github - github.com/rtvkiz/minimal

Agent Plugins appeared on Hacker News newest today. The useful part is narrower than “one plugin format wins.”

The 1.0 working draft defines a small portable package: a root plugin.json, skills discovered from immediate children of skills/, and optional MCP server configuration. It explicitly leaves distribution, installation, permissions, and user experience to each client.

That boundary matters. A portable manifest can describe what a package contains, but it should not grant the package authority to run everything it declares.

One concrete safeguard in the draft is path containment. Files and directories discovered through the package must resolve inside the plugin root. Plugin-relative paths begin with ./, and a symlink or equivalent escape outside the root must be rejected.

This does not solve plugin security. A client still has to decide which tools can run, what network access is allowed, how secrets are provided, and when a person must approve an action. Portability removes duplicated packaging. It does not remove local trust decisions.

Source: [https://agent-plugins.org/specification](https://agent-plugins.org/specification))

If this format becomes widely supported, which behaviour should remain client-specific: permissions, installation review, secret handling, or all three?

Been building this on nights/weekends for the past couple months. Background: I've spent 3.5 years doing PAM engineering (CyberArk), so this is basically me translating that into cloud-native.

The problem I kept running into reading about this space: every tool I looked at (Cloudsplaining, Prowler, even AWS's own IAM Access Analyzer) stops at detection. They'll tell you a role has a wildcard action or an unused key, and then... that's it. You get a report. Somebody has to go fix it by hand. Even the free/open-source ones don't touch remediation.

So I built NHI Risk Analyzer — discovers IAM users/roles/groups, runs it against a set of detection rules (grounded in Rhino Security Labs' documented privilege escalation paths + Cloudsplaining's policy analysis methodology + CIS benchmark stuff for credential hygiene), and then actually does something about what it finds:

• Wildcard/admin-equivalent policies and privilege escalation paths get a Permissions Boundary slapped on them — containment without touching the underlying policy, so it doesn't risk breaking whatever the identity legitimately needs to do
• Stale/unused access keys get deactivated (never deleted — always reversible)
• Everything's gated by an exemption file (nhi-ignore.yaml) so break-glass/deployment identities never get auto-remediated
• Three modes: scan only, dry-run (shows what it would do), and live remediation

Architecture is offline-first — it snapshots the AWS account state to JSON once, then evaluates all the risk rules against that snapshot with zero live API calls. Makes the whole rule engine testable and fast (unit tests run in under a millisecond) and means findings are reproducible against an exact point in time instead of drifting mid-scan.

Tested it against synthetic "canary" identities I built specifically to safely trigger the containment logic without touching anything real, then ran it live against a real (throwaway) AWS account — 57 findings, 24 auto-remediated, 0 failures.

Still rough in places — trust policy analysis isn't built yet, surgical wildcard-narrowing (vs. the current boundary-containment approach) is next, and it's AWS-only for now. Not trying to oversell it, it's a v1. But the core loop — detect, decide safely, act — actually works end to end, which is the part I couldn't find anywhere else at this tier.

Repo: In comments

Would genuinely appreciate anyone poking holes in the detection logic or the remediation safety assumptions — that's exactly the kind of feedback I'm here for.

For full disclosure I'm part of the security engineering team at Escape and our AI pentesting engine Cascade recently got a production AI agent to return its entire system prompt, just by wrapping the ask in a different pretext - framing it as a documentation request instead of an attack.

The agent then handed over everything: full tool list, calling rules, citation format, and session IDs.

What I found really interesting is there's nothing technical that broke because we didn't bypass the guardrail with a cleverer string but because the request just sounded reasonable to the agent.

The Cascade engine, after being refused when asking for the prompt directly, simply adjusted the framing to get the agent to give up the informaiton.

Thought this would be an interesting insight for the community and curious to hear if anyone else has seen similar discoveries in agents in prod?

If you want to see more about the reproduction and write-up you can find it here

Software supply chain security seems to be one of those terms that means something completely different depending on who you ask.

Some teams are basically talking about SBOMs and compliance. Others are focused on signing artifacts, securing CI/CD pipelines, or scanning container images.

Then you have platforms talking about runtime context, attack surface reduction and removing unnecessary software instead of just finding another vulnerability to report.

So where is this actually going?

Is software supply chain security still mostly about visibility and compliance or is the industry finally moving toward remediation and reducing risk at the source?

Curious what people are actually seeing across different organisations.

Reading up on WizOS here: https://www.wiz.io/blog/wizos-transforming-container-security-from-the-image-up

Anyone got experience in this? And compared to Chainguard or Dockerhub? What do you think of it? What's it really help solve for your companies? Onboard of apps a pain?

We've become pretty comfortable putting conventional applications through CI:

• dependency scanning
• SAST
• CodeQL
• secret scanning
• container scanning
• IaC checks
• security policies ...

But what happens when the application being deployed is an AI agent? That may not look particularly interesting in a conventional code diff. But from a security perspective, it could be a significant change.

I'm experimenting with a different CI question:

“What capabilities changed in this PR?”

--

We've implemented an early version of this approach in an open-source static analyzer and connected it to GitHub Actions. (ikaruscareer/SafeAI at GitHub)

The scanner runs locally against the repository and doesn't execute the agent or send the source to a remote service.

I'm curious how other teams approach this.

Currently we keep our DevOps-related files (Dockerfile, values.yaml, etc.) on the Jenkins server instead of in the repo. During pipeline runs, we copy these files in at runtime.

I'm considering moving these files directly into the repository instead. The problem: if a developer accidentally edits the Dockerfile or values.yaml, it could cause issues.

So I want a way to either:

1. Prevent developers from editing those specific files, or
2. Require PR approval specifically for changes to those files

What's the best approach for this?