r/devsecops

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?

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.

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.

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 🙏

Violin is now at v3.0.1 on master.

It is a Hermes-native profile for supervised, authorised penetration testing, with:

• 31 methodology and vulnerability playbooks

• An execution guard at the target boundary

• Evidence-backed findings and reporting

• Structured scoping and approval gates

• No additional credential broker or provider lock-in

Install:

"hermes profile install https://github.com/Strategic-Automation/violin"

I’m looking for Hermes users and penetration testers to test the installation and engagement workflow and report where the guard, evidence capture, or reporting process creates friction.

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?

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)?

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…

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.

Finally making bonsai-ninja public.
It’s a local code intelligence and static analysis engine built around compiler-backed facts instead of giant file dumps.

Use it for code intelligence, security taint analysis across 20 languages, or export call graphs, control flow, dataflow, IDG facts, and other structured compiler data for AI training, code-reasoning research, and agents.

It’s also built with local-first AI in mind. Pair it with your local LLMs to give them focused, compiler-backed context about a codebase instead of burning context windows repeatedly reading files. Models like Qwen and Nemotron are a great place to start, and experimenting with different local models is encouraged.

It’s free, MIT licensed, and runs locally. No subscription required, no hosted service required, and no analysis features held back behind a paid tier. Your source code stays on your machine.

Even if the engine isn’t your thing, the security-patterns alone are worth checking out. There’s an extensive YAML rulepack for modeling sources, sinks, sanitizers, frameworks, and security behavior across the supported languages.

This is just getting started. Contributions, testing, sharing, criticism, forks, whatever. Hell, steal it, improve it, build something better with it. Doesn’t matter. The goal is to put it out there and see what people do with it.

github.com/gromhacks/bonsai-ninja

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

I've just released Violin v3.1.0 🎻

This release is mostly benchmark and guard work, not another pile of prompts.

The benchmark now runs Hermes end-to-end and scores what it actually proved, not what sounds convincing in "report.md".

- Executed request/response evidence is checked against the endpoint, method and decisive proof.

- Proof must link back to a validated hypothesis and canonical "FIND" file.

- Execution receipts are HMAC-signed and bind evidence files by SHA-256, so edited artifacts fail verification.

- The guard now stops target work when evidence is not being recorded as you go, and checks excluded URLs and paths inside command payloads.

- Docker, CI and known-good/known-bad scorer calibration are included.

Release:

https://github.com/Strategic-Automation/violin/releases/tag/v3.1.0

I'd appreciate people trying to break the scorer and guard. Can you make weak proof pass, good proof fail or get the workflow stuck?

I'm not looking for “nice update” comments. If it is overbuilt, unsafe or wrong, tell me.

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.

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.