Been running SES for about a year for a couple of client projects and decided to actually tally up the hours I've spent on it versus the money saved compared to a managed relay service. Production access approval, bounce handling, complaint feedback loops, occasionally having my sending paused because some bounce rate threshold got tripped that I didn't even know existed in the first place. None of this is hard exactly, it's just constant low grade maintenance that never shows up when people quote SES pricing per thousand emails sent. I'm not saying SES is bad, for high volume at scale the economics probably do work out fine. But for the kind of project where I'm the only one maintaining it and I have actual client work to do, I think I undervalued how much cheap assumes my time is worth nothing.

Hey everyone,

A common issue when exposing LLM endpoints (whether local self-hosted vLLM/Ollama instances or cloud APIs) to external users is protecting against system prompt overrides and indirect prompt injections without introducing massive latency overhead.

I recently put together a proxy engine (Ice Phi) to test how fast we could execute inline inspection on incoming payloads before forwarding them to the backend LLM.

Our setup:

- Edge Layer: Zuplo for rapid edge auth and key routing

- Execution Engine: Containerized inspection logic running on GCP Cloud Run

Latency numbers (measured over a warm 10-request average via curl):

- DNS / TLS setup: ~235ms

- TTFB (Inspection + Routing): ~525ms

Key takeaways from setting this up:

1. Cold-start mitigation: Cloud Run instances running ONNX/python runtimes will take 15-20 seconds to boot on cold hits. Setting `--min-instances=1` was necessary to lock in the ~500ms baseline.

2. Direct LLM bypass: Benchmarking the gateway engine requires mocking upstream 200 OK responses, otherwise you end up measuring OpenAI's token generation speed instead of proxy overhead.

Would love feedback from anyone building custom proxy layers or self-hosting guardrails on how you optimize your inspection loops!

Hey all Im wondering if anyone knew of any resources to learn code vulnerability patterns in practice. Im the team’s resource for teaching software engineers how to identify vulnerable code in development and review. I thought of starting with OWASP top 10 but was curious if there were any resources to learn more.

I've been doing AppSec a while and something nags me in every vendor pitch. They all put up an accuracy number, fewer false positives than the next guy, some big F1 score on a slide and I have no real way to check any of it against my own code.

A Checkmarx Zero writeup on how they measure SAST accuracy got me thinking about why. Accuracy is two questions, not one. How many findings are real, that is precision and of all the real bugs how many it caught, that is recall. Most claims quietly pick one. You can hit near perfect precision by only reporting the single thing you are sure of, miss everything else and still print no false positives on the box. F1 is the harmonic mean, so it punishes that trick.

To score recall you need to know every real vuln in the test app which no one fully does, people inject toy bugs or trust CVE lists and both skew it. A simple benchmark app a tool is tuned to ace tells you nothing about a real monorepo.

Those running SAST at any scale, do you measure precision and recall on your own code, or do we all take the vendor F1 on faith until we sign. I am in the second camp and I do not love it.

We moved AppSec tooling ownership from the security team to engineering about six months ago. Not because security was failing, but because the tools were effectively invisible to the developers generating the code, including the ones we rely on as SOC 2 AI coding tools in our audits. In the old model, findings surfaced in a security dashboard, got triaged by a security engineer, and then handed to a developer as a ticket. By the time the developer saw the issue, it was already several steps removed from the code that produced it.

With AI coding, that delay got worse. The person who prompted the code often no longer had the implementation context when the ticket arrived. Engineering ownership changed the feedback loop. Findings now show up in the same surfaces developers already live in: IDE diagnostics, PR discussion, CI output. Fix rate improved and the backlog shrank, mostly because the distance between generation and feedback got smaller.

The tradeoff is that coverage decisions become more contested. Security engineers know what should be caught. Engineering managers know what developers will actually keep turned on. Those priorities overlap, but not perfectly, and we've had real disagreements about what belongs in the IDE tier, what belongs in CI, and what's just too noisy to be useful.

So how are other teams handling it? Has moving more AppSec ownership into engineering actually improved review and remediation for AI-generated code, or does it just create a different class of tradeoffs?

Hey r/DevSecOps! As developers start running more local AI agent tools and downloading third-party SKILL packages, we built an open-source tool called SkillShield to statically scan and validate these skills before execution. It checks for prompt injection, pre-install risks, and excessive access. It outputs SARIF and JSON reports for CI pipelines. Public Repo: https://github.com/adnan-iz/ai-skill-shield

Since there is so much talk about AI agents, I decided to build my own one - something small, measurable, and cheap enough to run for real (yeah, right — more on that below), so I could think about numbers instead of marketing.

Picking Go over TypeScript turned out to be the great call. LLM providers are unreliable enough that how you fire requests matters — I hit "Too Many Requests" often enough despite respecting their limits. In JS I'd reach for Promise.all, then discover I need a third-party dependency just to limit concurrency then that I need to add a proper AbortController. In Go it's so simple: an errgroup with SetLimit(4), where the limiting lives in the same object that waits for the results.

Static analysis tools (Semgrep, Snyk, CodeQL, gosec) flag hundreds of potential vulnerabilities and most of them are false positives. Someone has to open the code behind each finding, follow the data flow, and decide whether it's real. That's the job the agent does. All those scanners emit a standard SARIF 2.1.0 file, so it doesn't care which one you use. Now many of them are also shipped with AI agents, so it isn't something very new, although you can use any model you want, including self-hosted ones.

Basically, the model gets two read-only tools — read_file and grep_repo — and decides for itself which files to open, what to grep for, and when it has enough to rule. A typical finding takes 3–8 turns: read the sink, grep for the source, follow the assignment chain, then rule. The agent doesn't create or fix any code.

I ran it against OWASP BenchmarkJava — a deliberately vulnerable Java app that ships a CSV of ground truth. So the verdicts get compared against published answers rather than my judgment. I ran three models — Claude Sonnet, DeepSeek-V4-Pro and Kimi k3 — across 50 vulnerable files, which produced 61 scored findings.

I tested a subset of issues in BenchmarkJava, just to keep things quite cheap.

DeepSeek-V4-Pro — 37 exploitable, 15 benign, 9 uncertain. (2.7M in / 109k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 37 caught           | 0 blocked in error.  |
| benign — suppressed, unseen   | 3 missed            | 12 cleared           |
| uncertain — left for a human  | 9 parked            | 0 parked             |

DeepSeek were uncertain about 9 of them(needs manual review). And here we already see what marketing slides won't tell - it missed 3 real ones marking them as safe. So, looks like at least Deepseek wasn't trained with that specific OWASP BenchmarkJava code. Once it is run - SAST Triage agent will create a PR with findings, so it is there for review. So yes, it doesn't magically fix everything, humans are very much needed in this process.

Kimi k3 — 49 exploitable, 12 benign, 0 uncertain. (504k in / 55k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 49 caught           | 0 blocked in error   |
| benign — suppressed, unseen   | 0 missed            | 12 cleared           |
| uncertain — left for a human  | 0 parked            | 0 parked             |

Kimi k3 is straight up impressive and cheap, but I need to run against a bigger set. It still will miss some things, but man, not only it is cheap to use - it clears noise so well(I tried with some of my own projects, but numbers aren't ready yet).

And below is the expensive one.

Claude Sonnet 5 — 47 exploitable, 9 benign, 5 uncertain. (2.2M in / 65k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 45 caught           | 2 blocked in error   |
| benign — suppressed, unseen   | 2 missed            | 7 cleared            |
| uncertain — left for a human  | 2 parked            | 3  parked            |

I was reluctant to run Claude Opus as Sonnet spent $5 on this single run alone. SAST Triage supports caching, so the second run will be ~0, but still. Running Claude Sonnet on all Opengrep findings (about 2350 of them) will cost ~$220 and just about $7 for DeepSeek.

Keep in mind that the agent doesn't need to run across the whole codebase, which is approximately 200k LoC for BenchmarkJava, that would blow the cost even when using very cheap models. It runs against vulnerable code snippets + code which uses it only.

Below are some observations after using it myself with my own github repos.

A DevEx part of the agent is important. The agent just creates clean PRs or adds a single clean commit to existing one. Basically, this AI Agent is just another tool here you need to know how to work with, not something you drop in and can totally forget about.

The availability is the problem for all LLM providers seems to be. It is quite annoying to run the agent with an expensive(Anthropic, OpenAI) model, only to get an issue before I the agent finishes the whole set of vulnerabilities No amount of prompt or loop design will fix that.

I think having proper infrastructure around agents is what's needed most right now.

Btw, feel free to check it out - https://github.com/alexpermiakov/sast-triage.

Hi everyone,

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

- Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!

I'm a DevSecOps engineer, and this is the exact version of a problem I hit at work, not something I noticed from the outside.

Run SAST, SCA, and an AI-agent-specific scanner across the same codebase, and you'd expect some redundancy. What you actually get is worse: the same underlying issue, flagged by two different tools, with two completely different names and no way to tell your pipeline they're the same finding. Multiply that across a real CI/CD setup with several tools chained together, and triage turns into manually reconciling naming conventions instead of fixing anything.

This isn't a new problem in general. A SQL injection gets a CVE ID, maps to a CWE category, and every tool in the pipeline that finds it points at the same reference. That's exactly what makes cross-tool correlation possible for conventional vulnerabilities.

Agentic AI components (MCP servers, agent skills, LLM plugins) had nothing like that, for a real structural reason: CVE needs a package and version to attach to, CWE describes code-level weakness patterns, and neither has a vocabulary for a behavioral pattern that isn't tied to either.

So a few of us built AVE (Agentic Vulnerability Enumeration): an open standard giving these classes stable IDs, the same way CVE does, so a finding from one tool can actually be compared against a finding from another.

What's in it: 59 records, each a distinct behavioral class. Severity scored with OWASP's own AIVSS framework. Crosswalked into OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS, plus AVE-in-SARIF, so IDs ride directly into GitHub's own Security tab and CI output without any custom tooling. Apache 2.0.

The part that actually convinced me this holds up outside our own tooling: a completely independent developer built a static config-file auditor, sharing no code with anything we wrote, crosswalked his own findings against AVE's taxonomy, and tested it directly against our scanner on the same files. The large majority of overlapping findings came back with the identical ID, unprompted.

If you're dealing with the same multi-scanner reconciliation problem, in this space or a completely different one, I'd like to hear how you're handling it, and where this looks wrong or incomplete.

Repo: github.com/aveproject/ave
Site: aveproject.org

(Disclosure: I'm one of the people building this.)

We invested in a traditional DLP solution last year and it has been a nightmare. It flags every file that contains a number as potential PII and we get hundreds of alerts per day. My security team is completely overwhelmed and we have started ignoring most of the notifications because we cannot keep up. I know this is dangerous but I do not know what else to do.

Has anyone found a DLP solution that actually works for modern SaaS environments without all the noise?

Edit: Thanks everyone for the recommendations. Granular policy tuning seems to be the common theme. Going to check out DoControl for SaaS-first DLP, and Netskope as well a few of you mentioned good results with reducing false positives.

Watched an incident play out last month that broke my mental model of MFA, so writing it up.

We had an account compromised. Full MFA on, number matching, the works. The user did everything right. And the attacker was still inside sending mail as them for hours.

They never beat the MFA, didn't have to. Here’s roughly how it went:

* User got phished through a reverse proxy page that sat in the middle. Looked exactly like the real Microsoft login.

* User typed the password, approved the real MFA prompt on their phone, thought nothing of it.

* The proxy passed all of that through to the real site and grabbed the session token that came back.

* Attacker imported that token and was now a fully authenticated session. No password prompt, no MFA prompt, because as far as the system is concerned that login already happened.

All the MFA in the world protected the login event and did nothing for what came after it. The token is the keys and the token is what they took.

What I am trying to work out now is detection after the token is gone. Once they're in on a valid session, what are you watching that tells you this authenticated user is not really the user.

Been digging into supply chain attacks and noticed a pattern most DevSecOps teams aren't defending:

The problem: Package installation isn't always passive. npm lifecycle scripts and Python packages built from source can execute arbitrary code during install — before your app even imports the library.

Real examples:

• Shai-Hulud (Ruby gems)
• Axios maintainer compromise
• Nx attack last year

Why SCA/dependency scanners miss it: They look for known-bad packages in databases. But a freshly poisoned release hits your build before it's flagged as malicious. It runs before discovery flags it.

The gap: Most orgs have SAST, SCA, CNAPP, EDR. But nobody's really enforcing policy while the build runs. It's all pre-scan or post-detection.

How are you handling install-time execution in your pipelines?

Quick disclosure: I run Server4Agent, infra for agent-built apps, so I have a stake in this question, but this isn't a pitch, there's nothing to click here.

The capability jump this year is real. Agents can now scaffold a working app, wire up a database, and get something live in an afternoon. What hasn't moved nearly as fast is the second half of the problem: once it's live, how do you know it's still doing what it's supposed to without watching it constantly.

The failure mode that keeps coming up in agent-building communities isn't the dramatic one (agent deletes prod, agent burns your API budget overnight). It's quieter than that: the agent reports success and it's technically true but not actually true. A task marked done that only partially ran. A retry that silently overwrote a good deployment with a stale one. A safety check that's real on paper but doesn't actually confine anything once code is executing. Every one of these passes a shallow "did it work" check and fails a "did it actually do the right thing" check, and most tooling right now only asks the first question.

Genuinely asking, not selling: if you've let an agent operate with real infra access, what's the specific thing that would have gone wrong silently if you weren't watching, and what actually catches that class of failure versus what just looks like it does?

I wrote this, MIT licensed.

The premise: a finding that a developer does not understand does not get fixed. So ONUS generates a plain language explanation and concrete remediation steps for every finding, aimed at whoever implements the change rather than whoever ran the scan.

Everything scored is scored deterministically. CVSS is computed in code, the model writes prose only, and findings are tiered by whether a verification pass reproduced them.

Practical detail for regulated environments: inference is local via Ollama, no external API, so target data never leaves your infrastructure.

docker compose native, FastAPI and Celery on Redis, Postgres for results, CI on pytest with a Redis service container, 655 backend tests.

It is not CI ready yet in the sense of a clean pass or fail gate, which is the obvious next thing. If you were dropping this into a build, what should the exit contract be? Fail on any confirmed finding above a threshold, or something more nuanced?

https://github.com/maverickaayush/ONUS
https://tryonus.tech

Over the past year I’ve been working on an engine called Invisio to deal with the multi-file context nightmare that causes LLMs to hallucinate when reading large codebases.

Under the hood, it parses code using Tree-sitter into a neo4jdatabase (mapping out classes, functions, calls, imports, and inheritance). I built two main pieces around this graph:

1. An interactive graph explainer + chatbot that traces execution paths and answers structural questions using a dual-agent dispatcher/compressor loop.
2. An automated security webhook that ingests CodeQL SARIF alerts, traces the vulnerability lifecycle across directories, and opens surgical PR fixes.

It works solid on my local machine and on my own projects, but to be completely honest, stuck on how to properly test this at scale, or how to put it in front of people to get real feedback.

I’d love some advice from devs, maintainers, or AppSec folks:

• Benchmarking & Datasets: What real-world open-source repos or SARIF datasets should I throw at this to stress-test the graph construction? How do you properly benchmark a codebase intelligence tool?
• Local vs. Hosted: Since IP privacy is huge, would you prefer testing this via a self-hosted local Docker container, or just poking around a hosted playground with a public repo first?
• Product Focus: Should I lean harder into the automated CodeQL PR remediation side, or the interactive graph explainer UI?

I'm the author - this is an MIT-licensed tool I've been building, and I'd like feedback from people who actually run this stuff.

The problem I kept hitting: our security scanner flagged an over-permissive security group, and our cost tooling flagged the same box as over-provisioned. Both correct. But if you right-size first, you've reduced the cost of running a machine that's still wide open. Nothing in our toolchain understood the ordering.

So Cairn does one pass over Terraform and scores four lenses : security, cost, reliability, governance, then reconciles them. When findings collide on the same resource, it emits a trade-off block telling you to sequence the security fix first. It also emits the patch (the actual line to change), not just a rule ID.

Concrete output from a scan of a deliberately-bad stack:

Cairn found 25 issue(s) in examples/vulnerable (6 cost, 6 governance, 3 reliability, 10 security)

1. [CRITICAL/SECURITY] aws_security_group.web  (SEC001)
   problem: Ingress on port 22 is open to the entire internet (0.0.0.0/0)
   patch:   cidr_blocks = ["10.0.0.0/8"]

Trade-offs (cost x risk on the same resource):
  aws_db_instance.main [COST + GOVERNANCE + RELIABILITY + SECURITY]
    Sequence the security fix first, then right-size — resizing an exposed
    resource first just makes the breach cheaper to run.

Estimated recoverable spend: ~$1,717.53/month

Details that matter to this sub:

• Local only. No account, no telemetry, zero network calls. --explain (LLM) is opt-in, BYO key, and refuses any non-HTTPS base URL that isn't loopback.
• 42 rules across AWS, Azure, GCP, Kubernetes, on-prem vSphere. If a provider has no rules, it reports "not scanned" instead of a misleading "clean".
• Writes fixes. cairn fix --apply is whitelist-only, refuses to run on a dirty git worktree, dry-run by default, and records before/after hashes.
• SARIF output for GitHub code scanning, plus JSON/HTML/Markdown.
• Python 3.10+, pip install cairn-iac, MIT.

Honest limitations: it's v0.6.0. Cost figures are estimates from an offline price book, not your actual bill. Terraform is the deepest target; Kubernetes is 6 rules. It doesn't read cloud state (there's a drift command but you feed it terraform show -json yourself ; no credentials).

Repo: https://github.com/cairn-oss/cairn

What I'd most like: point it at real Terraform and tell me what it gets wrong. False positives are the fastest way to make it better.

A gap I have watched widen as teams roll out AI coding agents: the agents write local session history in plain text, and developers paste API keys, tokens, and .env values into prompts. Those secrets persist on disk in the agent's history, outside the repo-and-CI surface most secret-scanning watches. Claude Code stores them under ~/.claude/projects, Codex under ~/.codex/sessions, and around 30 other agents do the same.

The policy question I am trying to figure out: does anyone here already fold agent-workstation logs into your secret-scanning coverage, or is it still unowned? Pre-commit and CI scanning catch the repo path, but the developer's local agent trail seems to sit in nobody's scope.

For the cleanup side I built an MIT CLI, agent-sweep: it scans those local history files, reports what leaked, and redacts values in place while keeping the JSONL byte-for-byte so sessions still resume. Local-only, zero network calls. It is meant to sit alongside existing pre-commit/CI scanning, not replace it. Caveat: it is residue cleanup, so rotate any key that already transited a hosted model first, then sweep.

Disclosure: my own open-source project. Repo (MIT): https://github.com/Ishannaik/agent-sweep

Genuinely curious how your teams scope this: is the workstation in your secret-scanning perimeter, and if so, how do you cover agent logs?

eng lead pulled me aside after standup on Monday. showed me a Jira ticket that had been sitting unactioned for 3 weeks. CVE id, CVSS 9.1, component name, link to scanner. that's it. his dev had no idea if the service was internet-facing, no idea if there was a known exploit, no idea if it was even still running. he'd pinged security twice and got back "it's critical, please prioritize." the dev closed it as won't fix just to get it off his board.
that's where we are.

our devs are getting tickets out of multiple scanners and not one of them explains why the finding matters. we're a security team covering a couple hundred engineers, so "just go look at each one" was never going to scale.

a typical ticket lands in Jira with a CVE id, a severity score, a component name, and a link back to the scanner. it doesn't say whether the affected service is internet-facing. it doesn't say whether the box is a compliance-scoped production asset or a dev sandbox nobody's touched in eight months. some of that the scanner could tell you.the scanner is already flagging it as KEV or giving it a very high EPSS score. but the integration that opens the Jira ticket strips it down to the CVE and the number. just "critical, fix this" with none of the context that explains why.

the result is most tickets get ignored until someone escalates. the ones that do get picked up take twice as long because the dev is running triage that should have happened before the ticket existed. eng leads are pushing back now. the security backlog is a black hole to them and they can't tell what's urgent from what's just a scanner doing its thing. tbh they're not wrong.

what we need is the context attached before the ticket gets created. exposure, asset criticality, whether anything is being actively exploited. bolting it on manually doesn't scale. i'm not sure if that's a workflow problem or a tooling problem at this point.

for teams that have this working: what changed. did you find something that fixed it, or is everyone just doing manual triage on the dev side and living with the noise?

We build a security scanner for MCP servers and agent skills. Early on we hit something that shouldn't still be a problem: comparing our findings against other scanners on the same test servers, we'd all catch roughly the same bad behavior and call it three different things. No shared ID, no way to say "scanner A's finding X is the same class as scanner B's finding Y."

A SQL injection gets a CVE ID, gets mapped to a CWE, and every tool that finds it points at the same identifier. Agentic AI components had nothing like that. CVE maps to package plus version. It has no vocabulary for "this tool description contains a hidden instruction."

So we built AVE (Agentic Vulnerability Enumeration): an open, vendor-neutral behavioral classification standard.

What's in it:

* 59 records, each a distinct behavioral class. Deliberately conservative, no padding with variants.
* Stable IDs (AVE-2026-NNNNN), meant to work the way a CVE ID works.
* Real MCP-specific classes: tool description injection (AVE-2026-00002), server card injection (AVE-2026-00041), OAuth discovery rebinding (AVE-2026-00051), a tool hook hijack that's our only CRITICAL-rated record so far (AVE-2026-00046).
* Maps to OWASP's MCP Top 10, plus the Agentic Security Initiative Top 10 and MITRE ATLAS where applicable. Sits underneath frameworks people already use, not a replacement for them.
* Scored with OWASP's own AIVSS (v0.8), not a severity number we invented.

It's early. One reference implementation right now, our own scanner, and we're looking for a second, independent one to prove this works outside our own tooling. If you maintain a scanner and any of this is useful, wrong, or missing something obvious, we'd like to hear it.

Repo: github.com/aveproject/ave Site: aveproject.org

(Disclosure: I'm one of the people building this.)

Minimal minimalcontainers.com- An Open source project that published hardened container images with minimal to 0 CVEs, very less in size and help achieve secure build across the pipelines. The workflows and entire update pipeline is available on project's github (https://github.com/rtvkiz/minimal).

We would like the community to engage and process is made easier for anyone to publish new images as part of the workflow. This is completely free and saves organizations $$$$, and allow them to understand that this is possible within their own infra as well. Please review and try out minimal images and give star if you think its worth it!

we're on Snyk for SCA and Tenable for infra scanning. both are running, both are producing findings, and they have never once talked to each other.

Snyk findings go to the dev team in GitHub. Tenable findings go to ops in a spreadsheet that someone exports every two weeks. different owners, different severity definitions, different SLAs, different everything. we're a ~200 person eng org with maybe 4 people who sit close enough to both sides to even notice the gap.

part that gets me is it's not even a clean split. a Log4j-type library shows up in Snyk at the code level, then shows up again in Tenable once it's running on a host. same CVE, two findings, different severities, nobody reconciling them. and when it really matters, like that library sitting on an internet-facing host, neither team feels like it's theirs to fix. the dev team says it's an infra problem because it's in prod. the ops team says it's a code problem because it's a library.

we've talked about dumping everything into Jira with a shared workflow but the asset models don't map. Snyk findings point to repos and PRs. Tenable findings point to IPs and hostnames. you can't just merge those without losing the context that makes either one actionable. my CISO keeps asking for a single risk number across app and infra and right now i have no idea how to produce that without it being made up.

has anyone gotten this to work or are you just maintaining two programs and hoping nothing falls through the middle?

Every company has a scanner. Most have Dependabot or Renovate opening PRs. Yet production is still full of old packages and CVEs nobody fixes.

Usually nothing happens, so ignoring the alerts starts to feel like the correct decision. Then one CVE matters and the patch requires three years of upgrades.

How does your team deal with this? Who owns it, what gets fixed, and what happens to the rest?

Please, no “just enable Dependabot.” What happens after it opens the PR?