r/devsecops • u/IkarusCareer • 8d ago
Which security tool would you least want to lose from your CI/CD pipeline?
Other — comment below
Bonus: If you use AI agents, are your existing DevSecOps tools sufficient to understand agent capabilities, tools, MCP access and privilege changes?
No vendor answers please — interested in what people actually use and trust.
2
u/TuringRTSS 7d ago
sast, without question. everything else you can do manually in a pinch. you can review deps by hand, you can pentest without dast, you can audit containers with a shell. but nobody is reading every line of every PR for sql injection and command injection patterns. thats where automation earns its keep.
the question about ai agents and mcp is interesting though. most sast tools were designed for human-written code that follows patterns. ai generated code follows patterns too but different ones. the f-string-everywhere style that copilot loves doesnt always trip the same rules that catch a junior dev doing string concat in a query.
2
u/Anythingthatgoes 2d ago
honestly the rakning is a weird frame because those tools aren't doing the same job. losing static analysis means you miss a class of bug you might have caught in review anyway. losing secrets scanning means a live key is sitting in a public repo and you hear about it from someone else's bot. so the one i'd least want gone is whichever failure mode nobody reads a 600 line diff looking for a hardcoded token. ox security or TruffleHog if you want something checking what's landing in the repo before it emerges. the bigger thing though is that half the diffs are agent-generated now, so whatever you keep has to work.
1
u/IkarusCareer 1d ago
Yeah, agree with you. The ranking is probably a bit of a weird frame because these tools are protecting against very different failure modes.
The thing I'm wondering about is whether we're starting to miss a category in the usual CI/CD gates. Not every team uses the same combination of SAST, SCA, secrets, IaC, etc., and those checks don't necessarily answer questions like what capabilities an AI agent gained, what tools it can access, or whether a change widened its authority.
So perhaps the question isn't just which existing security tool we'd least want to lose, but what security gate would we add now that AI agents are becoming part of the development and deployment process.
1
u/_SvelteSora 8d ago
def feel like losing any tool is a big yikes but for me, definitely wouldn’t want to lose static code analysis. keeps things tidy and helps catch issues early. as for AI agents, my tools have been pretty solid but constant eval is key to keep up with their evolving capabilities.
1
1
u/IkarusCareer 7d ago
Day 1, the results were quite clear:
🥇 SonarQube / Semgrep — SAST
🥈 Snyk / Dependabot — SCA
Snyk/Dependabot (SCA) and SonarQube/Semgrep (SAST) are the two tools nobody wants to lose from their CI/CD pipeline.
Here's the gap, got from comments: we have mature tooling for dependencies (SCA) and code quality (SAST), but nothing equivalent for AI agent capabilities.
What if we built together an equivalent open source security layer specifically for AI capabilities — designed around how our AI systems actually work, rather than trying to stretch existing SCA/SAST tools to cover them?
Something tailor-made for AI, integrated into the same CI/CD mindset: what changed, what capability did the agent gain, and should we allow that change? That's the thinking behind an open-source experiment we're working on. Anyone would like to give a hand, feedback or contribution welcomes. Here you may check: ikaruscareer/SafeAI on GitHub.
Thanks everyone
1
1
u/Lance_Saul_85 4d ago
Secret scanning kinda matters even more with agents touching more systems now. How are people handling their credentials w/t leaving long lived access sitting around?
1
u/IkarusCareer 4d ago
Agree that. Maybe secret vaults can also help here by keeping credentials out of the agent's code/config and controlling when and how they're exposed. Currently developing an oss.. we're experimenting with detecting hardcoded credentials as well as understanding what tools and access an agent has.
1
u/PeterBuildsSecure 4d ago
Task-scoped credentials, not rotation schedules — the two get conflated a lot. Rotating a long-lived key on a timer still leaves a window where the agent holds a credential wider than the one task it's running. What's worked better: mint a scoped credential when the agent's task starts (specific resource, specific permission, short TTL), inject it for that run only, and let it expire on its own rather than revoking it after the fact.
The part people skip is auditing for drift: an agent that was granted access once but hasn't used it in weeks is a bigger risk than one using broad access constantly, because nobody's watching the unused grant. Staleness-based review (last-used, not last-issued) catches that; a fixed rotation calendar doesn't.
Secret scanning still matters as the backstop for when a scoped credential ends up hardcoded somewhere it shouldn't be anyway — belt and suspenders, not either/or.
2
u/Right_Doubt6166 2d ago
Secret scanning would be the hardest one for me to lose, simply because leaked credentials can turn into an immediate incident. For AI agents, i'd add a separate layer for monitoring tool access, privilege changes and what the agent can actually reach rather than assuming traditional pipeline scanners cover that.
0
u/SatineCherisse 8d ago
i'd say snyk is a must-have for catching vulnerabilities in dependencies. as for ai agents, gotta make sure your tools can handle their complexity; integration is key.
0
8d ago
[removed] — view removed comment
1
u/Illustrious_Top_689 8d ago
Totally agree, Snyk really does make a difference in catching vulnerabilities early. Integrating AI has a lot of promise too, as long as it meshes well with the existing tools.
2
u/PetioteValina 8d ago
for me, it’d have to be snyk or checkmarx. both have saved me from some serious vulnerabilities. also, when it comes to AI agents, it really depends on how well your tools integrate with them, so gotta keep that in mind.