r/devsecops

SAST clean. DAST clean. SCA clean. Phishing simulation — 99% pass rate. Then the breach happened anyway. The problem isn't that tools fail. It's that each tool is accurate inside its own domain and blind the moment you step outside it. SAST doesn't see what SCA sees. Neither sees configuration drift. And none of them correlate findings across layers. Three separate findings — medium input validation issue, low outdated parsing library, low information leak in error responses — each accepted by a separate analyst. Individually: noise. Combined: a complete exploit chain. The Blue Shield of California breach in April 2025 is a clean example of the other blind spot: no vulnerability, no exploit. A single analytics configuration quietly sent protected health information for 4.7 million people to an ad platform for almost three years. None of the standard tools were positioned to catch it because none of them treat configuration as part of the attack surface. Made a short video breaking down both gaps — the human side (trust laundering via training) and the technical side (dead zones between tools). Curious whether others are seeing this inter-tool correlation problem in practice — and how teams are handling it.

I've been thinking a lot about how much quiet risk sits in the base images we treat as done." so the Most of the security and supply chain conversations I'm in focus on scanners, SBOMs, dependency policies, and CI gatekeeping, but underneath all that are long-lived container bases that only change when someone remembers to bump a tag. failure mode isn't just slow patching, but tht nobody really owns the rebuild loop as a first-class responsibility.

The common pattern looks something like: pick an official distro or runtime image (ubuntu:22.04, python:3.11, node:20), pin a tag, run scanners, and patch in bursts when a critical CVE shows up or a compliance audit forces the issue. That feels fine until you realize upstream has shipped multiple rounds of fixes, but your "stable" base hasn't been rebuilt in months. At that point you're depending on ad-hoc human attention rather than an actual process.

What I'm interested in is treating base images as something that should move when upstream moves. i know In practice, that would mean images built directly from upstream project sources, minimized so they only contain what the app truly needs, and automatically rebuilt when upstream releases land. Near-zero CVEs become a property of the system, so not an occasional hardening sprint, and provenance plus SBOMs are baked in instead of added later.

The part I haven't fully resolved yetis ; automatic rebuild isn't the same as automatically safe to ship. If the rebuild loop just pushes a new digest straight through without a validation gate, you've traded "stale image" risk for "unattended image landing in prod" risk. So whatever this looks like in practice, it has to come with actual promotion gates (tests, canary, something), not just a fresher tag showing up. And going minimal/distroless has its own cost that doesn't show up in a CVE count: no shell, no package manager, sometimes a different libc than what you're used to, which means your debugging workflow has to change too (ephemeral containers instead of exec-ing in, basically).

There's a small handful of hardened/minimal catalog providers doing this now. The pitch is:..instead of every team inventing its own "watch upstream and rebuild" pipeline, you standardize on a provider whose job is to keep those bases fresh, small, and well-instrumented. You can still mirror the images into an internal registry and layer your own policies on top, so it's not a full hand-off, but you're not reinventing the underlying maintenance lifecycle either.

For anyone who's actually moved to this model: how are you gating the rebuilds before they hit prod, or are you trusting the vendor's pipeline outright?

We have several repos, all Clojure. I need SAST coverage for secure code review, but nothing mainstream (Semgrep, CodeQL) supports Clojure properly. Even clj-holmes the one Clojure-specific tool isn’t a real solution; the maintainer told me himself it’s not in good shape.

I’m leaning toward an AI agent for code review, since LLMs are actually decent at reading Clojure. Has anyone gone the AI route for SAST on a niche language? How well did it hold up?

Been looking into how banks are securing their AI systems, especially with the EU AI Act closing in. The data security side of this feels undertalked.

Banks are feeding sensitive client data into AI systems constantly. The exposure surface is massive. Prompt injection, data leakage between sessions, unauthorized access to training data. Regulators now expect banks to log and explain AI-driven decisions, which means the data flowing through these systems has to be traceable and controlled end to end, not just secured.

Looking into AI data security platforms in banking, I came across three that seem relevant: Palo Alto, Cyera, and NeuralTrust. They each cover different ground. Palo Alto handles security across the agentic AI lifecycle, Cyera focuses on data classification and controlling where sensitive data actually travels, and NeuralTrust monitors runtime agent behavior to catch unexpected data exposure or policy violations.

Do banks realistically need all three, or is there meaningful overlap? Curious what stacks people are actually running in regulated environments.

I built a free public benchmark that tests whether AI can catch bugs in code. Some of the bugs are real security regressions that actually shipped in open-source projects (real CVEs, put back in with the upstream fix as the answer key), and others are bugs I inject into real repos myself. Then Claude, GPT, Gemini, and DeepSeek review the diff, and I score who catches the bug, who flags fake ones, and whether they give the same answer twice. The surprising part: on the hardest bugs, some models catch them every single run while others miss every single run, so which model you pick matters more than I expected. No signup to browse, and the CVE-based ones link back to the real fix so you can check them. If you ship code with AI, I'd love you to poke holes in the method. benchmodel.io/leaderboard

Hi everyone, I have about 8 years of experience in DevOps. I never tried freelance yet.

How do I start? Where do I find work? Any suggestions?

Visual E2E label encompasses tools which fail in a very different way. The question we need to ask here isn't what we call those tools, but why exactly do they fail.

Tools that fail when application structure is changed:

Firebase App Testing Agent: path explorer going through accessibility nodes, screenshot of crash on failure, obviously to what is actually presented to a user

Maestro AI: YAML language cleaner than Appium, yet still bound to the component tree below, UI changes will break the flow even if the code of tests is well written

Tools that fail only if the screen itself is changed:

There are no attempts at reading the component tree, there are no bindings to accessibility nodes the change in class name or component hierarchy does not influence the test unless something visible to user is changed autosana belong to the latter group, the tool runs flows directly against the screen layer

Hi everyone;

I've been looking around and haven't found a tool that lets you actually define and track your own KPIs. Not control compliance I mean real KPI tracking: define the metric, track it over time, report on it.

Everything I find is either a GRC tool (compliance-focused, not KPI-focused) or a BI tool you have to bend into shape yourself.

What's actually working for people here? Spreadsheets, Grafana, something built in-house, a GRC tool that secretly does this well?

Start with the smallest base that runs your workload  distroless or scratch for compiled binaries, minimal OS images for everything else. Multi-stage builds are non-negotiable: build dependencies should never appear in the final image. Every unnecessary layer is a future CVE to triage.

Beyond the build: automate rebuilds on base image updates, scan every image before it hits a registry, and enforce a maximum image age policy so stale images don't persist in production. Lean and secure aren't in tension, they reinforce each other. What's the one thing that's made the biggest difference for your team in keeping images clean?

Hey everyone,

I'm building a CI SCA pipeline for a Spring Boot application using Dependency-Check, Trivy, and OSV Scanner.

I've been going back and forth between two approaches:

1. Generate a CycloneDX SBOM from Maven and feed it into all the tools
2. Resolve dependencies into a local Maven cache and point the tools directly at the JARs or POM files

From my testing, scanning the Maven cache directly produces a huge amount of noise — false positives coming from other libraries' POM files declaring their own dependency versions, which Maven never actually uses at runtime.

The SBOM approach gives much cleaner results since it only contains the versions Maven actually resolved.

Is SBOM the industry standard for this kind of pipeline? Are there any downsides I'm missing?

which one do u think best:

Cybersecurity and Information Assurance – B.S.

VIEW DEGREE
Protect your career and earning potential with this degree.

MORE DETAILS
APPLY NOW
Time: 60% of graduates finish within 29 months.
Tuition: $4,410 per 6-month term.
Courses: 34 total courses in this program.
Certifications included in this program at no extra cost include:

Certified Cloud Security Professional (CCSP) - Associate of (ISC)2 designation
Systems Security Certified Practitioner (SSCP) - Associate of (ISC)2 designation
ITIL® Foundation Certification
CompTIA A+
CompTIA Cybersecurity Analyst Certification (CySA+)
CompTIA IT Operations Specialist
CompTIA Network+
CompTIA Network Vulnerability Assessment Professional
CompTIA Network Security Professional
CompTIA PenTest+
CompTIA Project+
CompTIA Secure Infrastructure Specialist
CompTIA Security+
CompTIA Security Analytics Professional
Skills for your résumé that you will learn in this program:

Secure Systems Analysis & Design
Data Management
Web and Cloud Security
Hacking Countermeasures and Techniques
Digital Forensics and Incident Response

****************

Cisco, Cloud and Network Engineering – B.S.

VIEW DEGREE
This specialization contains a unique focus on Cisco systems and processes

MORE DETAILS
APPLY NOW
In the Cisco specialization, you will learn specific Cisco operating systems and networks, giving you experience with Cisco architecture.

Time: 61% of graduates finish similar programs within 36 months.
Tuition: $3,915 per 6-month term.
Courses: 34 courses in this specialization
This program also includes third-party certifications that will help you boost your résumé and be prepared for career success. Certifications include:

CompTIA A+
Linux Essentials - LPI
ITIL (Information Technology Infrastructure Library)
CCNA (Cisco Certified Network Associate)
Cisco Certified Cybersecurity Associate (CyberOps)
Cisco DevNet (CCNA-Automation)
CompTIA Cloud+
WGU Certified Network Technician Badge

*****************

Azure, Cloud and Network Engineering – B.S.

VIEW DEGREE
In this specialization you will focus on Azure systems, processes, and tools

MORE DETAILS
APPLY NOW
With the Azure specialization you will gain knowledge and skills that will help you as you progress in your career.

Time: 61% of graduates finish similar programs within 36 months.
Tuition: $3,915 per 6-month term.
Courses: 34 courses in this specialization
This program also includes third-party certifications that will help you boost your résumé and be prepared for career success. Certifications include:

CompTIA A+
Linux Essentials - LPI
ITIL (Information Technology Infrastructure Library)
Network+
Security+
Azure Fundamentals
Azure Cloud Platform Solutions
Azure Solutions Architecture
CIOS - IT Operations Specialist (A+ and Net+)
CSIS - Secure Infrastructure Specialist (A+, Net+, and Sec+)

is sourcecode review also a necessary skill in web security just like appsec or not?

Our own app images are the easy bit because we rebuild them every release and the base fixes just ride along. It's the off the shelf services that nag me, things like postgres, redis and nginx where theres no build step on our side at all. When trivy lights up the official postgres image over some debian CVE theres really nothing for me to fix so im just sat there waiting on the maintainer to push a new one.

None of the options feel good either. I could pin it and eat the lag, but building my own from source means babysitting it forever, and going off to find a faster-patched variant turns into its own rabbit hole.

How are you keeping the service images you dont build yourself patched

After our last access review, we started trying to tighten up identity across the whole application estate, not just the modern SaaS that already speaks SAML/OIDC, but the older stuff too. And the pricing model is actively working against us. "Enterprise SSO" has started to feel like a tax bracket. For modern SaaS, you pay extra just to flip SAML on. For legacy apps, you pay again, in engineering time or extra tooling, just to make them visible to the IdP at all.

The genuinely painful part is the long tail. Custom, legacy, and internal apps that don't talk SAML/OIDC, don't have a decent connector, and definitely don't show up in your IGA the way the slideware promised. You can wrap some of them in identity-aware proxies or ZTNA-style access, but that still doesn't fix provisioning, deprovisioning, or access reviews. They stay partially managed at best, which is precisely where the risk hides.

Right now we're juggling three worlds at once: IdP-native SSO for the well-behaved apps, reverse proxies or ZTNA for some legacy web apps, and a pile of disconnected desktop and thick clients where auth is still local or bolted onto ancient LDAP. For a subset of those, the only "governance" we have is manual access tracking in spreadsheets, because there's no realistic path to refactor them this year.

So here's my real question for anyone who's pushed past the low-hanging SaaS. Where did you draw the line between "we invest the time to fully onboard this legacy app into the IAM stack" and "we accept it as an exception with documented manual controls"? What actually made an app worth the full onboarding cost versus signing off on the risk?

Sales engineer at a devops platform company. We sell to platform eng leaders and devops directors mostly mid market. our outbound has basically stopped working in the past year. response rates are in the toilet and the AEs are losing morale. 

Marketing inbound has volume but the lead quality is terrible, half are students or people studying for a cert. The issue as far as i can tell is that our buyers are not on linkedin all day. They dont open emails from sales tools, they live in slack communities, github, kubernetes adjacent discords, and sometimes hacker news. our outbound stack (zoominfo nd outreach) is built for marketing buyers, not these people.

Ive been pushing internally for us to invest in something that actually meets the buyer where they are. ai prospecting that looks at where engineers actually live, not just where they list themselves on linkedin.

Ive seen demandbase and 6sense in the past and they dont really solve this, they tell you the company is researching, not who in the company. 

had one of those incidents recently where afterwards everybody technically followed process and we still ended up in a bad place.

few months back one of our external-facing middleware apps got flagged for a vulnerable third-party java library. not a name-brand CVE, no KEV listing yet, EPSS was low-ish. scanner marked it high but not critical. went into backlog with the rest of the noise because we were already burning patch windows on stuff with confirmed in-the-wild activity. nobody at that point would have called it an emergency and honestly i still dont think we wouldve 

security wanted it patched earlier. ops pushed back because the fix would've required downtime during quarter close and CAB wasnt going to approve an emergency change off “possible exploitation” alone. vendor also hadnt fully certified the patched version yet against the older JVM stack this app still depends on.

so the finding sat.

we added temporary WAF coverage, documented compensating controls, CAB signed off on the deferral and everybody kind of moved on to the next fire.

then about six weeks later SOC escalated outbound traffic patterns from the same server talking to infrastructure tied to a known campaign.

turned out the vulnerable component was getting actively exploited and the entry point was the exact service we'd kept deferring because there were other “higher priority” findings ahead of it.

thats the part thats been bothering me honestly. nobody ignored the issue. ticket existed. CAB reviewed it. controls were documented. ops had legitimate concerns about downtime risk and vendor supportability. if you looked at the decision in isolation it all sounded reasonable.

the problem was exploitability changed while the finding was sitting in backlog waiting for organizational process to catch up.

and we didnt really see that shift until SOC was already involved.

how others are pulling active exploitation context into prioritization workflows without creating another separate feed analysts have to manually cross-reference all day. especially in environments where remediation depends on CAB approvals, vendor coordination and maintenance windows instead of just patching immediately.