[ system :: lens ]

Lens .

Vulnerability scanning that hands you the work that actually matters — and tells you why.

[ finding :: cve-2026-x ] priority · 02
Critical RCE on public-facing service
cvss 9.1
kev yes
public exploit weaponized
exposure external
controls none
asset REDACTED
action patch → fix-version 7.0.5

[ 00 / brief ]

Most vulnerability scanners produce a list. The list has a few thousand entries on it. Every entry has a severity score from a system that hasn’t met your environment. By the time your team is done sorting “really exploitable in our setup” from “noise from a default rule on a tool nobody owns,” the next scan has dropped a new list on top.

Lens does the scanning, and then it does the part that scanners usually leave to you. We correlate every finding against the rest of what we know about your environment, what’s actually being exploited in the wild, and how the affected component sits in your real exposure surface. The output isn’t the scan results. The output is the ordered list of work — with the reason it’s in that order — that closes risk fastest.

[ 01 / what’s covered ]

  1. The scan — Lens runs as a managed scanner against the infrastructure you tell it to look at. Deployable as a module on your existing Grid appliance if you’re already a Grid customer, or as a standalone for organizations that aren’t. Authenticated and unauthenticated modes both supported; cadence is yours to set.

  2. Exploitability, not just severity — Every finding gets cross-referenced against our own threat intelligence platform. CVSS score is the input, not the answer. The output tells you whether the CVE is on CISA KEV, whether there’s a public exploit, whether exploitation is actively being observed, whether a patch is out, whether a workaround exists.

  3. Context against your actual environment — A CVSS-9 in a service you don’t expose isn’t a CVSS-9 problem. A CVSS-6 in something on the perimeter, behind no mitigating controls, with a working exploit in the wild, very much is. Lens looks at how an affected component sits in your environment — exposure, asset criticality, the controls that are actually in front of it — before it tells you what to do first.

  4. Prioritized work, not raw output — Findings are ranked by exploitability, environment context, and the effort it takes to fix them. The top of the list is what closes the most risk for the least time; the bottom is everything else, ordered honestly. You can work down it without having to re-prioritize the queue yourself every Monday.

  5. Grid integration — Findings that cross an exploitability threshold can fire as Grid cases. The same on-call team handles them, the same alert lifecycle applies, and closure round-trips back to Lens when the next scan confirms the fix.

  6. Reporting your auditor will accept — Findings, dispositions, exceptions with documented justification, remediation timelines, scan history. Exportable. Auditor-readable. The evidence trail your compliance work needs.

  7. Read what you decided — Every accepted-risk, every deferred finding, every disposed entry keeps its history. When a deferred CVE moves from “no public exploit” to “active exploitation,” Lens surfaces it again automatically and flags that your prior disposition needs another look.

[ 02 / who this is for ]

  • Security and IT teams running their own vulnerability program who want correlation and prioritization, not another scanner-output dump.
  • Grid customers who’d rather not stand up a separate tool when the platform we already run for you can hold the scanner too.
  • Public sector, regulated industry, and mid-market organizations working toward an audit (SOC 2, CMMC, HIPAA, PCI) that requires a documented vulnerability management program.
  • MSPs and integrators managing vulnerability programs across a portfolio of customers, who want a single product handling the scan-to-disposition lifecycle for all of them.

[ 03 / how it fits ]

  • Lens runs on Intel. The “is this actually being exploited” question gets answered by the same threat-intel platform that powers Grid’s alert enrichment. Public exploit status, KEV listing, active exploitation, vendor advisory state — all live, all cited.
  • Lens hands findings to Grid. If you also run Grid, anything that crosses an exploitability threshold can become a case in the same workflow your SOC alerts already live in. One case queue, one set of dispositions, one trail.
  • Lens cross-references Pulse. When a finding maps to a CVE that’s currently in the news, the finding’s detail view links to the Pulse topic page so your team can see the broader coverage without leaving the workflow.
  • Identity is centralized. Lens uses the same identity plane as the rest of our products. Your team logs in once.

[ 04 / where we are ]

Lens is in build. Scanning, intel correlation, exposure-context ranking, and the Grid case handoff are wiring up against our own infrastructure first. General availability is targeted for Fall 2026, opening from there outward by platform coverage — cloud infrastructure, web-facing services, internal network surfaces, identity systems.

Early-cohort scoping is open. If you’re staring at a scanner output today and wishing it was a real work queue by Fall, get in touch.

[ ready :: contact ]

Talk to us.

Tell us what you're scanning today, what's in your environment, and what your current program looks like. We'll tell you honestly what Lens would change about your queue — and whether it's the right fit.