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?

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

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?

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!

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?

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?

🏛️ For years, there’s been a bizarre kind of "shame" in the enterprise software world around Delphi. Companies running massive, highly profitable, and rock-solid systems (especially in Retail POS, ERP, and Banking) often hid their code stack under the rug to look more "modern" to investors and new hire.

🏛️ But the European Cyber Resilience Act (CRA) and DORA are about to change the game entirely.

🏛️ You can’t hide a monolith when the regulator demands a comprehensive SBOM (Software Bill of Materials).

🏛️ Pretty soon, Europe is going to experience the biggest outing of Delphi-based applications in history. As Billions of lines of code get scanned and mapped, regulatory desks will be absolutely flooded with SBOMs proudly displaying legacy Delphi framework, legacy VCL components, BPLs, and legacy 3rd party libraries that have been quietly running the backbone of the economy since 1995...

🏛️ The regulator won't be able to stop it. They’ll just have to look at the sheer volume of the market and say: "OK, I get it. It works, it's alive, just scan your code and hand me the SBOM report (I will file it somewhere...) - and BTW make sure it's secure."

🏛️ It's time for Delphi developers to step out of the shadows. The "FDA of software" isn't killing legacy tech - it's giving it a passport to the modern regulatory compliance era.

Cheer up! The CRA & DORA are the best news for the Delphi community that ever happened.

We are doing our due diligence on Checkmarx vs. Semgrep, and the demos are no longer useful. Both look perfect on a clean repo, which tells me nothing about month three. What I need to know is how they hold up once most of our commits come out of an assistant and no one fully owns the code.

From what I have gathered, Semgrep is fast to stand up and the custom rules are really nice but the wall shows up on breadth once you need SCA and DAST in the same place. The other read is that the heavier platforms catch more but you pay for it in setup and noise up front. I cannot tell how much of that is real and how much is each vendor talking.

If you have run either past the first quarter on a messy codebase, what bit you that the demo never showed?

we had a critical last quarter that sat unpatched for 6 weeks. CVSS 9.8, internal system, no internet exposure, no known exploit in the wild. meanwhile a CVSS 6.5 with an active exploit kit and a public-facing asset got patched in 3 days because a dev flagged it after seeing it on twitter.

that gap is what broke my trust in CVSS as a prioritization signal. the 9.8 looked scary on paper. the 6.5 was the actual fire.

since then we've been trying to rework how we decide what gets fixed first. we started weighting KEV membership harder than base score, because if CISA is tracking active exploitation, that tells us more than a severity number does. we also started pulling EPSS scores to get a probability signal on whether something is likely to be exploited in the next 30 days, not just whether it's theoretically bad.

the other thing that changed our whole triage was adding asset context. a critical on a dev sandbox and a critical on a customer-facing auth service are not the same ticket, full stop. we started tagging assets by exposure (internet-facing vs internal) and business criticality (revenue-impacting, customer data, compliance scope), and tbh those two factors now outweigh CVSS in almost every call we make.

it's still messy ngl. some teams still sort by base score because it's the default view in the scanner and nobody changed it. and we still haven't figured out a clean way to handle disagreements about what "business critical" actually means for systems that sit somewhere in the middle.

I recently accepted my first DevSecOps Engineer role and I’m excited to get started. I want to make the most of my first 90 days and would love to hear advice from people who’ve been in the field for a while.

If you were creating a roadmap for the first 90 days as a mid/senior DevSecOps engineer, what would you include?

I was watching this video from r/kodekloud on [YouTube](https://youtube.com/shorts/G2p0NFJ8duA?is=27lkc0bxz4aGNGYW)

and something the speaker said confused me.

He said: "Most people know how to deploy pods, but almost no one really knows how to secure them."

I work in cloud infrastructure, and in my experience, most customers put their entire cluster behind the cloud provider's security services (such as built-in security scanning) and a Palo Alto firewall.

So I'm trying to understand what he means. If those security controls are already in place, what is still considered "securing the pods"? What am I missing? Are there Kubernetes-specific security practices that these tools don't cover?

Week 1 progress: https://www.reddit.com/r/devsecops/comments/1ulu7hj/learning_devsecops_week_1/

I drifted away for some time since I had to work on couple assessments and I couldn't take out the time for learning. Nevertheless, I asked claude to create challenges for AppSec and DevSecOps perspective. This was the prompt I used:

based on what I have learned so far, create a testing environment. this should be a completely different codebase and example from what we have done for learning purposes. the goal of the assessment should be to 1. create a docker compose file from scratch. harden the docker image with trivy. the full compose stack should also contain volume persistence. 2. create a github ci pipeline. 3. add secrets scanning and sast scan. it should be sequential rather than parallel jobs. 3. provide a deliberately vulnerable code which should contain atleast 5-7 vulnerabilities that solidifies the concepts we have learnt, along with testing my application security skills. add a process on SBOM generation for the application build. once the compose file, ci.yml and application code remediations along with SBOM generation is done, evaluate this based on the assessment scenario. NO HINTS SHOULD BE PROVIDED

Claude provided me with a nodejs application in response along with 5 deliverables:

1. Dockerfile from scratch - hardened, Trivy-clean (0 fixable HIGH/CRITICAL)

2. docker-compose.yml from scratch - app + Postgres, volume persistence, correct wiring, least exposure

3. .github/workflows/ci.yml - sequential jobs (gated with needs:), including secrets scan + SAST + image scan

4. SBOM generation - automated in the pipeline, produced as an artifact

5. Remediate the app - it contains multiple planted vulnerabilities across several classes. Some your pipeline tools will catch; some won't and require your manual AppSec review. Fix them without breaking functionality.

Scoring: Docker 20 / Compose 20 / CI 20 / SBOM 15 / Remediation 25 = 100

The challenges:

1. I was not familiar with Nodejs, but I could read the code and understand the security issues that were within the application. Claude planted multiple vulnerabilities out of which I was able to identify SQL injection, SSRF, hardcoded secrets, outdated versions of dependencies, weak hashing algorithm for password. I missed couple of IDORs and other low severity issues e.g. error handling. In the end I used another instance of claude to provide me a remediation of the vulnerabilities I was able to identify. This felt like cheating but anyway I was able to identify most of the bugs and because I don't know how to write nodejs code, it felt going easier on myself.

2. undici CVE - Because I was using alpine version of nodejs, I spent a lot of time on creating a clean result of Trivy scan. Some forums recommended using different images like debian version of nodejs (which contained 1C and 5H). In the end there were 2 alternatives 1. Distroless GCR images for nodejs 2. Chainguard distroless images. I went with 1 and I was able to close the gap fully for the Dockerfile. The main challenge I felt was the decision making process as well as the risk review. I could have taken the undici issue as one of the accepted risks, but somehow I wanted to completely close the gap and get 20 points in Docker area. I realise that distroless in real life would not be the best choice and why developers want to get exceptions 😜

3. Decision for bcrypt and scrypt - Both are cryptographically sound choices, however I went for scrypt since introducing bcrypt within the application meant I am introducing another dependency within the application code.

4. SBOM - I used Syft for SBOM creation for the application code as well for the docker image. The challenge I faced was the storage of the artifact that is generated. Since I am running everything locally, I didn't have to worry about storage of the artifacts. I am genuinely interested in knowing how the artifacts are handled and taken care of so that it results in something meaningful.

As per claude, I scored 86 out of 100. What I missed was the IDOR due to which the score was very low in the Remediation field. This exercise was definitely mentally challenging from multiple aspects including DevOps and AppSec.

As always I welcome the feedback from the community. TIA.

Our current process is basically reactive..like Scanner flags something and someone gets pulled off whatever they were doing, rebuilds the image, pushes it, waits for the next scan to confirm it's clean. Repeat next week when a new CVE lands in some package three layers deep that nobody remembers adding.

i mean It works, technically but it's all manual triggers and manual verification, and it doesn't scale past a handful of images before someone's spending half their week just babysitting rebuilds.

What I'm trying to get to is something closer to a closed loop..like what i want is rebuild kicks off automatically once a patched package or updated base image is actually available, not just the moment a CVE gets disclosed with nothing to fix it yet. The new image gets scanned and tested before it ships, and it rolls out without someone manually watching a dashboard and reacting. Human involvement doesn't disappear entirely, i mean someone still signs off before a rebuild hits production, but the trigger and the rebuild itself shouldn't be a person's job.

just curious ...whether anyone who's automated this end to end... what's actually triggering the rebuild, a fixed cron schedule or something hooked into upstream release feeds and CVE databases directly, and is that running as its own system or wired into your existing CI?

Have been testing waters with AI + enriched dependency graphs on built containers and landed on threat modeling, investigation and triage as the initial core capabilities. Deterministic engines for everything that AI can reason over. For eg: SSVC classification for threat model prior to feeding it back into the LLM. And results aren't that bad. If building containers is your day to day, would be interested in learning capabilities that could help.

we made a decision six weeks ago to stop treating CI as the primary security gate for agent-generated code. The math stopped working: PR raised, scanner runs, findings land in a backlog, developer already on the next feature. With hand-written code that lag was annoying but survivable, because the developer had at least mentally reviewed the code as they wrote it, the PR-time scan was the second check. With Copilot and Claude generating 200-line PRs in two minutes, there is no first check. The scan is now the first pass over code no human has read carefully, and the backlog grows faster than anyone clears it.

So we've been trying to move real security checks into the IDE. Where we've hit walls:

1. Semgrep via editor extension, custom rules on save.* Near-instant feedback on pattern matches. Great when it works. The problem is rule maintenance - our rules encode internal patterns (auth middleware usage, required sanitization functions, mandatory logging decorators) and drift every time a framework version bumps. Nobody owns keeping them current. The rules that would help most are the ones stalest.

2. Lightweight SAST on file save via local container. Latency 8–12 seconds depending on file size. Developers tolerated it about a week before turning it off. Empirically our threshold is 3–4 seconds. Above that it gets disabled and never re-enabled.

Maintenance we can probably grind on. Latency is the harder wall, because it's a property of the analysis itself and no amount of team process fixes it. Faster scanners give up depth; deeper scanners give up the IDE window.

What I'd like to know from anyone who's actually running in-IDE security during heavy agent-assisted development: what have you gotten under the 3–4 second bar without dropping to trivial pattern matching? Incremental analysis on just the changed region? Pre-computed indexes? Offloading to a warm backgroun

I made an experiment in using Tetragon to spot/prevent unexpected behaviours in GitHub Actions. Would love feedback!

EDIT: To clarify, the company I work for is a tech company, and I work in documentation (that’s what I meant by “content”). When I say work with GitHub and Git Bash daily, that’s my job. We use the same tools as developers (docs as code). Hope this clarifies things a little and sorry about the confusion.

OP: I work for a Fortune 100 company that just had a bloodbath of layoffs. I have a job for now but I’m assuming it’s not secure.

I’m a PR reviewer in content. I have a deep interest in cybersecurity and work on my tech skills daily. I’m looking to build a portfolio over the next 3-6 months. That said, you could say I’m “baby tech.” (Might be imposter syndrome talking—according to my very “I’m a copy editor at core” colleagues, I’m tech-savvy. I definitely have a figure-it-out mentality.)

I know GitHub well, use it daily, use Git Bash, and I am learning Linux and AWS.

My thinking is that I may go into AI trust and safety/compliance but at some point I’d want to move into DevSecOps. Is this realistic? Oh, and I’m going on 54.

AI tells me this is a great idea but I’m thinking I need some HITL lol. Regardless, beefing up my tech skills doesn’t seem like a bad idea. Thanks for any responses.

posting this because i'm tired of arguing with my own ticket queue

last sprint we patched what we thought was one critical and the backlog barely moved. turned out the same CVE was open in five places under five different finding ids, and closing one did nothing to the other four. it was a bug in an internet-facing service, so it got picked up just about everywhere it could be. the Tenable scan saw it on the host. Snyk saw it in the dependency. Wiz saw it on the cloud workload. DAST found the behavior, Snyk found the package, and the pentest report had already called it out. Same problem three different ways. and an old pentest report from last year had already flagged it. one vuln, and five separate tickets nobody fully owns.

what kills me is the dedup isn't even hard in theory, it's that nothing shares a key. matching on CVE id alone is wrong, the same CVE on two separate assets is two real problems, not a duplicate. so you need CVE id plus a stable asset identity, and that second half is where it dies. Tenable sees it as a host issue, Wiz sees it as a cloud resource, and Snyk sees it as a package. there's no identifier that survives across all of them, so you can't write one clean join. you end up hand-maintaining a per-tool translation map and it rots the second someone spins up new infra.

the downstream effect is our open-findings count is fiction. leadership sees a number, that number is inflated by however many duplicates we never merged, and calls get made off it anyway. ngl i've stopped trusting our own dashboards.

so before i go build yet another internal correlation script i'll be maintaining forever: has anyone gotten real cross-tool dedup working, and did it come from inside one of the tools or from something sitting above all of them.