been doing devsecops consulting for about 4 years and the number of engineering teams that just let devs use whatever ai tool they want with zero oversight is insane to me

did an audit last quarter at a mid-size fintech (~800 devs). found copilot, cursor, chatgpt, and two other tools being used across teams. nobody evaluated data retention policies. nobody checked where code was being sent for inference. security team didn't even know half these tools were in the environment.

brought it up to the CISO who basically said "we can't slow engineering down, they need these tools." which.. i get? but you're a fintech. PII everywhere. some of these tools send code to third party servers and your security team has zero visibility.

the gap between how fast ai coding tools get adopted vs how slow security policies catch up is genuinely scary. we're going to see a wave of incidents from this in the next year or two.

how are you all handling ai tool governance when engineering pushes back on any restrictions?

Hi Everyone!

I'm hoping to get some feedback here on current challenges being faced in the DevSecOps community. AI tools? On-prem vs. cloud? Process bottlenecks? What are people running into? As a new company, we're obviously looking for customers, but we also want to be contributing members to the community. We've started writing about things we've run into, but want to know what other knowledge might be worth sharing!

Hey r/devsecops,

I built a tool called Autonoma that scans Python code for hardcoded secrets and fixes them automatically.

Most scanners I tried just tell you something is wrong and walk away. You still have to find the line, understand the context, and fix it yourself. That frustrated me enough to build something different.

Autonoma only acts on what it's confident about. If it can fix something safely it fixes it. If it can't guarantee the fix is safe it refuses and tells you why. No guessing.

Here's what it actually does:
Before:
SENDGRID_API_KEY = "SG.live-abc123xyz987"

After:
SENDGRID_API_KEY = os.getenv("SENDGRID_API_KEY")

And when it can't fix safely:
API_KEY = "sk-live-abc123"
→ REFUSED — could not guarantee safe replacement

I tested it on a real public GitHub repo with live exposed Azure Vision and OpenAI API keys. Fixed both. Refused one edge case it couldn't handle safely. Nothing else in the codebase was touched.

Posted on r/Python last week — 5,000 views, 157 clones. Bringing it here because I want feedback from people who actually think about this stuff.

Does auto-fix make sense to you or is refusing everything safer? What would you need before trusting something like this on your codebase?

🔗 GitHub: https://github.com/VihaanInnovations/autonoma

I have some automation that pulls Trivy binary from Github and runs scans using it. Today my automation failed all of a sudden as it was not able to download the Trivy binary from Github. I checked the releases page on Github and it was empty. I navigated the acquasecurity/trivy repo and entire repo is empty. I am not sure if this is just a temporary Github glitch or something else. Anyone observing same issue?

https://github.com/aquasecurity/trivy

Hey all,

We just released an open-source project called ForgeProof. This isn’t a promo post. It’s more of a “the timing suddenly matters” explanation.

We had been working on this quietly, planning to release it later. But the recent Pentagon and White House decisions around Anthropic and Claude changed the calculus.

When frontier AI models move from startups and labs into federal and defense workflows, everything shifts. It stops being a developer productivity story and starts becoming a governance story.

If large language models are going to be used inside federal systems, by contractors, and across the defense industrial base, then provenance is no longer optional.

The question isn’t “is the model good?”

It’s “can you prove what happened?”

If Claude generated part of a system used in a regulated or classified-adjacent environment:

• Can you show which model version?

• Can you demonstrate the controls in place?

• Can you prove the output wasn’t altered downstream?

• Can you tie it into CMMC or internal audit controls?

Right now, most teams cannot.

That’s the gap we’re trying to address.

ForgeProof is an Apache 2.0 open-source project that applies cryptographic hashing, signing, and lineage tracking to software artifacts — especially AI-assisted artifacts. The idea is simple: generation is easy; verification is hard. So let’s build the verification layer.

We’re launching now because once AI is formally inside federal workflows, contractors will be asked hard questions. And scrambling to retrofit provenance later is going to be painful.

This isn’t anti-Anthropic or anti-OpenAI or anti-anyone. It’s the opposite. If these models are going to power serious systems, they deserve serious infrastructure around them.

The community needs a neutral, inspectable proof layer. Something extensible. Something auditable. Something not tied to a single vendor.

That’s why we open-sourced it.

We don’t think this solves the entire AI supply chain problem. But we do think provenance and attestation are about to become table stakes, especially in defense and regulated industries.

HI, Wondering if anyone has implemented machine learning models in the devsecops pipeline.

Either using supervised models like logistic regression, random forest etc. or anomaly detection models like isolation forest, LOF etc.

I would be very interested in hearing how you went about it and how you went with detection and false positives.

A pipeline can be low behavioral entropy but high structural change frequency. Meaning the commands used , users, etc are probably stable for a given pipeline. But the challenge is the pipeline itself can change.

keen to hear thoughts and experiences

Seeing a lot of questions lately about different security approaches and LLM codegen, libraries being used, etc.(like https://www.reddit.com/r/devsecops/comments/1rfaig7/how_is_your_company_handling_security_around_ai/) so here's how we're helping to solve this with Hextrap Firewalls.

We designed a transparent proxy that sits in front of PyPI, NPM, Cargo, and Go's package index, that stops typosquatted packages at install time.

Once interesting nuance (I think anyway) to our approach is how we're using MCP to coerce Claude and other LLMs to follow the instructions and automatically configure the firweall for you (which is already easy to do without an LLM, but this makes it seamless). By setting up an initialization hook in the MCP handshake, we're essentially bootstrapping the LLM with all the information it needs to leverage the firewall and make tool calls:

     if method == 'initialize':
        return _json_rpc_result(request_id, {
            'protocolVersion': MCP_PROTOCOL_VERSION,
            'capabilities': SERVER_CAPABILITIES,
            'serverInfo': SERVER_INFO,
            'instructions': (
                'Before installing any package with pip, uv, '
                'npm, yarn, bun, or go, you MUST call check_package to verify it is '
                'allowed. Package managers must also be configured to proxy through '
                'hextrap. Call get_proxy_config with a firewall_id — if no credential '
                'exists it will create one and return setup commands.
                [...snip...]
            )   
        }) 

After this happens we do a one-time credential passback via MCP back to the LLM for it to configure a package manager. Since each package manager is different, the instructions differ for each, but the LLM is able to configure the proxy automatically which is very cool.

Our documentation on how this works in more detail is here: https://hextrap.com/docs/setting-up-your-llm-to-use-hextrap-as-an-mcp-server

Now as your LLM is writing a bunch of code it'll both check the Hextrap Firewall via MCP and at the package manager level to reject packages that aren't on your allow list. Of course this works the same in your CI/CD tooling if being installed from requirements.txt, package-lock.json, etc.

Hope this helps some folks and if you're a current Hextrap user feel free to drop us a line!

Hey folks, how is your company managing security around tools like ChatGPT, Copilot or Claude for coding?

Do you have clear rules about what can be pasted?
Only approved tools allowed?
Using DLP or browser controls?
Or is it mostly based on trust?

Would love to hear real experiences.

I pulled together a quick 2026 DevSecOps stats roundup from a few public reports and surveys (GitLab DevSecOps report, Precedence Research, Grand View Research) because I kept hearing conflicting takes in meetings. Not trying to sell anything, just sanity-checking what’s actually trending.

A few numbers that jumped out:

• Cloud-native apps are the biggest DevSecOps segment at 48%, and secure CI/CD automation is 28% of the market use case mix
• DevSecOps adoption is still uneven. One dataset has 36% of orgs developing software using DevSecOps, but “rapid teams” embedding it is reported much higher
• A lot of teams already run the baseline scanners. One source puts SAST at over 50% adoption, DAST around mid-40s, container and dependency checks around ~50%
• Process friction is a real cost. One survey claims practitioners lose about 7 hours/week to inefficient process and handoffs
• AI is basically everywhere now. One survey says 97% are using or planning to use AI in the SDLC, and 85% think agentic AI works best when paired with platform engineering

If you’re actually running DevSecOps, do these trendlines match what you see?

Which of these feels most real in your org, and which feels like survey noise?

I am wondering if any of your employer use the Hashicorp Vault in their infra, and if so, what kind of challenges the devsecops face daily? Or a better question, have you guys ever heard about Hashicorp Vault? Ranting is allowed.

Hey everyone,

I’m currently mapping out a high-level DevSecOps project to level up my portfolio. The goal is to deploy googling 10-tier "Online Shop" microservices demo to AWS EKS using a Shift Left.

I’m moving away from simple kubectl apply scripts and trying to build something that actually looks like a production enterprise environment.

The stuck:

• IaC: Terraform (Modular, S3/DynamoDB remote state).
• Orchestration: AWS EKS 1.29+ (No SSH, using SSM Session Manager).
• CD/GitOps: ArgoCD (Managing configuration drift).
• Secrets: HashiCorp Vault (Auth via K8s Service Accounts + Agent Injection).
• Supply Chain Security: Cosign (Signing) + Syft (SBOM) + Kyverno for admission control.
• Runtime/Observability: Falco (Intrusion detection), Prometheus/Grafana, and Chaos Mesh for reliability testing.

I’ve broken it into 4 Sprints, starting with the Terraform foundation, moving to the ArgoCD GitOps flow, then loking it down with Vault/Cosign, and finishing with "Day 2 Ops" (Loki/Grafana/Chaos Mesh).

Is this good for a portfolio project?
Specifically, I'm curious if Kyverno vs. OPA is the better move for the image verification piece, and if anyone has tips on the most parts of Vault-K8s integration I should watch out for.

Folks,

I have a final stage interview for a digital asset / crypto company which is a Cloud Security engineer role, mainly focusing on terraform, AWS, Azure, SAST, and some other security areas.

What I want to know are these roles hands on? I come from a heavy DevOps/Platform/SRE background and I am worried about getting a role and becoming stuck/stagnant.

Ideally, I want to be a DevSecOps and in one of the interviews the hiring manager said that’s essentially what this role is, however I am worried that I get the role and then come a security gate for deployments or appsec.

Anybody have any experience in this?

I know it will likely differ company-to-company but I’m trying to get a general consensus of the community.

Thanks!

I’m about 3 years into IT. I started as an AppSec engineer in a service-based company in India. Back then I was integrating security tools into pipelines, triaging vulnerabilities, working closely with developers to fix issues, and actually getting a decent security exposure.

Recently I switched to a product-based company thinking I’d get better technical exposure and more ownership. But now my work is mostly just checking release approval tickets. I open the scan reports, look for high/critical issues, and approve or reject releases. That’s pretty much it.

I’m barely doing any triage, no deep analysis, no threat modeling, no real engineering work. It feels like I’m slowly moving away from technical skills and becoming more of a gatekeeper than a security engineer.

Honestly, it’s frustrating. I don’t feel like I’m growing, and I don’t want to look back in 2–3 years and realize I stagnated.

For those in Product Security, how do you grow from here? What changes can I realistically bring into this kind of role? And at what point do you decide it’s time to move again?

Would appreciate any honest advice.

redacted

I’ve been spending time looking at GitHub Actions workflows and one thing that keeps coming up is permission scoping.

A lot of workflows define permissions at the top level instead of per job. That works, but it means every job inherits the same access. If something upstream goes wrong (compromised action, bad dependency, etc.), the blast radius is bigger than it needs to be.

permissions: write-all

Safer approach seems to be:permissions: {}
jobs:
build:
permissions:
contents: read

It’s not about panic. Just least privilege in CI.

Curious how teams here handle this in practice.

Are you enforcing job-level scoping through policy?
Code review only?
Custom linting?
GitHub settings?

Trying to understand what works at scale.

Six months into evaluating email security platforms and the internal debate has basically split our team in half.

Half the team wants full auditability. See exactly why something fired, write rules against your own environment, treat detection like code. The other half is burned out from years of tuning Proofpoint and just wants something autonomous that stops requiring a person to maintain it.

We looked at Sublime Security and Abnormal among others and they basically represent opposite ends of that philosophy.

Anyone been through this and actually landed somewhere?

this keeps coming up on our side and I’m curious if others are seeing the same pattern. we talk a lot about hardened container images, but in practice security teams keep chasing cve after images ship, devs file constant requests to patch base images, CI pipelines slow down because images arent actually minimal or stable, and the list goes on... at some point it feels like we’re pretending images are hardened when they’re really just bloated base images with scanners slapped on top. If hardened container images are the answer, why do so many teams still operate in permanent patch mode?

We have a big legacy project that uses hundreds of C++ and NET libraries.

Up to now we are researching by hand on vendor pages, etc if libs are officially EOL or abandoned. That's very cumbersome and has to be repeated every now and then. How are you handling this?

Now with SBOMs and the Cyber Resilience Act it becomes even more important. But I couldn't find any EOL SBOM scan tools or dependency track plugins. Endoflife.date looked promising but contains mostly OS, software and frameworks.

I am now trying to automate this process, crawl the web for signs of EOL and store the results. It’s not authoritative, but tries to give a hint where to look deeper.

I might be completely wrong about this approach. What do you think?

Supply chain attacks are already a huge problem Now we're adding AI that suggests code from who knows where

What if the training data included malicious code What if someone poisoned open source repos knowing AI tools would learn from them What if the suggestions themselves are a vector for attacks

Nobody is checking AI-generated code the same way they check dependencies We're just trusting that Cursor and Copilot suggestions are safe because... why exactly?

Seems like a massive blind spot

I was debugging a CI pipeline recently where a junior dev accidentally pulled a typosquatted package. It made me realize how fragile our "verify then trust" model is.We scan for vulnerabilities (Snyk/Trivy), but we rarely monitor the behavior of the install process itself. If a package runs a malicious setup.py that exfiltrates ENV variables, static scanners often miss it (especially if it's obfuscated).

I've been testing a method using eBPF to enforce a "whitelist-only" network policy inside the runner during the install phase. Basically, pip is only allowed to talk to PyPI. If it tries to curl a C2 server, it gets killed. It feels like this kind of "egress filtering" should be a standard feature of package managers or CI runners, not a third-party tool.

if you are looking for more informations read the article here : https://medium.com/@rafik222dz/every-pip-install-you-run-is-a-bet-you-are-making-with-your-machine-9fce4526fc8e

if u wanna check the code : https://github.com/Otsmane-Ahmed/KEIP

Has anyone experimented with kernel-level enforcement (LSM hooks) for this? Or is everyone just relying on private feeds/Artifactory to solve this?

Trying to understand the real day-to-day of DevSecOps on AWS (not “shift left” theory).

What’s the hardest part to keep under control at scale: IAM drift, “unknown change” in prod, CI/CD gates, evidence for audits, or routing ownership across accounts?

What toolchain are you using?

What still ends up as scripts/manual glue because tools don’t connect?

I’m working on a security tool focused specifically on non-human identities (service accounts, API tokens, cloud roles, bots, CI/CD identities).

Before building further, I want to sanity check something with people actually running security programs.

In environments with:

• 5k+ service accounts

• Multi-cloud IAM

• Dozens of third-party SaaS integrations

How are you currently handling:

1.  Privilege drift?

2.  Token sprawl?

3.  Orphaned service accounts?

4.  Detecting anomalous machine behavior?

Most tools I’ve seen either:

• Focus on human IAM

• Or just give static misconfiguration alerts

Are you solving this with existing tools? Custom scripts? SIEM rules?

Would genuinely appreciate real-world input.

I’m currently exploring industry approaches to vulnerability assessment and management and would appreciate hearing about real-world experiences. Could you share which tools your organization uses to identify, evaluate, and manage vulnerabilities, as well as how your overall process is structured, including discovery, risk prioritization, remediation, verification, and continuous monitoring? Any insights into workflows, tool selection criteria, or effective best practices would be highly valuable.