Traditional exposure management stops at CVEs. Your risk doesn't.

A vulnerability gets a CVE ID, a score, and a path to a fix. Every team works from the same catalog. But CVEs are only one type of security finding, and most exposure management programs stop there, even though your team is on the hook to address many security findings outside CVEs:

• Security Findings on assets not CVE-related: identities, certificates, SaaS apps, OT, and AI agents.

• Security Findings that didn't get a CVE (yet).

• Security Findings tied to security posture (misconfigurations, excessive privileges, security control gaps, etc.).

None of these come with a CVE ID, a shared catalog, or a shared workflow. And with vulnerabilities spiking faster than the NVD can catalog alongside mean time to exploit dropping toward zero or even negative days, the non-CVE surface is only growing.

Teams end up covering the gap with spreadsheets, siloed solutions, and per-asset prioritization, and that breaks twice. The security team becomes the integration layer, burning hours on manual correlation that technology should handle.

And prioritization happens in pockets: whichever asset type is hardest to catalog risk gets deprioritized for no reason but plumbing. A leader asking "where is the major risk?" gets no clean answer, because findings live scattered across devices, identities, code, cloud, SaaS, and OT.

What’s missing is a way to declare a finding everywhere a CVE/scanner does not reach.

How to turn any risk into a tracked finding

To solve that, we built Security Finding Rules.

A rule combines asset, security, and business signals from Axonius to declare what counts as a security finding for prioritization, ownership, and fix. You can build rules around your organization's specific context, or start from the catalog our cyber research team maintains.

A security finding rule has two parts:

1. A category. Organizing the issues you care about.

2. A scope. What constitutes a finding under this category, in declarative/query format. Example: Accounts with "executive" role in Workday, MFA not enrolled, and with recently breached data in Have I Been Pwned.

When the next discovery cycle runs, every match becomes a security finding, receiving the same treatment as a CVE would: an ID, a risk prioritization, an owner, a remediation, and an SLA. This ensures that any security findings are equally discovered, prioritized, and treated.

Rules come in two flavors:

1. Built-in rules ship from Axonius to catch common findings, and you can opt in based on your preferences.

2. Custom rules are yours to define. Open Security Finding Rules, click Create, pick a category, and scope what a finding is to be solved. Here's an example: unencrypted disk volumes in your PCI DSS network.

The rule turns that into a tracked, owned, scored finding alongside every CVE. When that works, the impact is immediate:

“Axonius exposes misconfigurations and unpatched software instantly. Instead of waiting for the next audit cycle, we can remediate vulnerabilities as soon as they surface.” – Matt Durant, CISO, BlueLinx

Why we built Security Finding Rules

Security Finding Rules exist to reveal the non-CVE attack surface, while taking the silo work off your plate (manual correlation, per-asset prioritization, and workflows every time a non-CVE issue appears). You shouldn't be doing any of that. Your technology should. 

Three principles shape how we built it:

Every asset type can present security findings

Security teams shouldn't have to track only the CVE-bearing slice of their attack surface. The CVE catalog covers vulnerabilities on devices and software. It does not cover an identity missing MFA, a certificate about to expire, a SaaS app misconfigured, or an AI agent with too-broad a scope. Those are all security findings, and they deserve the full lifecycle: surfaced, prioritized, owned, scored, and remediated.

Findings are yours to define

A vendor default shouldn't decide what counts as a finding in your environment. What counts depends on the asset's attack profile and your risk tolerance. MFA missing on a retail cashier may not be table stakes. MFA missing on the C-suite is urgent. The rule encodes your judgment.

Every finding lives in one normalized queue

Prioritization shouldn't depend on which asset type was easier to catalog. Every finding carries the same attributes (identifier, owner, risk score), so "work the certificate issue or the server vulnerability?" gets answered from your priorities, not from plumbing. The cost of asking stays flat as you add asset types, instead of growing with every new silo.

How Security Finding Rules fit your existing exposure management program

Security Finding Rules follow the same design principles as the rest of Axonius Exposures: ergonomic for security teams, ready to fit into your existing exposure management program.

• Integrates with what you have. Security Finding Rules work out of the box with the 1,400+ adapters and 150+ security tools Axonius integrates with, across any environment. No new agents, no network tap, no new scanners.

• Works with Axonius Cyber Assets. If you're already an Axonius Cyber Assets customer, Axonius Exposures and Security Finding Rules work without re-integrating anything.

• Batteries included. Findings inherit the full Axonius platform: query language, dashboards, workflows, actions, and the rest.

• Ships with rules, built to be remixed. Built-in rules cover common findings on day one. Custom rules encode your judgment when a vendor default won't do.

Get started with Security Finding Rules

To get started with Security Finding Rules, access your Axonius Dashboard, go to Exposures > Security Finding Rules, click Create, and follow our instructions to define your first rule. It's that simple.

If you're not an Axonius Exposures customer yet, have specific questions, or want to explore Axonius Exposures in depth, book a personalized demo with us.