Close nothing you can’t prove.

One view over every vulnerability scanner you already run.

Every finding in one list, ranked by real risk, each with a deadline.

Works with Tenable.sc · Tenable.io WAS · CIS benchmarks · Prisma Cloud CSPM · Prisma Cloud CWPP

What is Aegis?

Aegis is your business’s shield: one umbrella over every scanner you already run.

It gathers what they find into one picture of your estate, ranks each problem by the risk it really poses, gives it a date, and keeps it open until a scan proves it fixed. It doesn’t replace your scanners, and it doesn’t take anyone’s word for it: the number on the board only goes down when your machines are actually safer.

Walk through.

Follow a month of findings, from the scanners that report them to the scan that proves each fix.

The blind spot

A month of scans from five scanners: hundreds of findings, many of them the same problem on the same machine, reported again and again.

540findings, from five scanners

The hand-off

Aegis merges the repeats into exposures, one problem on one machine, and lays them out by where they live.

60exposures, once the duplicates are merged

The fix

An engineer patches and marks it fixed. That is a claim: it stays open and counted.

60still open: 34 marked fixed, none closed

An exposure, open
Marked fixed: a claim, still open and counted

The proof

The next scan checks. Proved fixes close; the rest stay open, and say why.

31still open. 29 closed, each proved by the scan

29 closed: the scan proved the fix
5 marked fixed, but the scan found them again
26 not fixed yet

Close nothing you can’t prove.

An exposure closes only when a scan proves the fix.

See the whole loop on a demo estate

Chaos to order

One scanner, scan after scan. One ordered list out.

Every report

from one scanner, scan after scan: repeats, reopenings, noise

One list

each problem once, ranked by real risk, with a date and the machines named

The same findings, in Aegis · example rows

Fix this weekKnown to be exploited, on machines that matter

Then the rest, in order, each with a date. Closed only when a scan proves it.Point at a row, or tap it, to see the raw reports it was merged from.

tenable.sc220 reports this month200 repeats49 reopened

Open one row: Log4Shell, on one of its seven machines.

One exposure

Three scanners, three names for it. One exposure.

Log4Shell on host-14one exposureclock from 2 Sept

Tenable.scApache Log4j < 2.15.0 remote code executionhost-14 · CVE-2021-44228 · first seen 2 Sept

Prisma Cloud CWPPCVE-2021-44228 in log4j-core 2.14.1host-14 · CVE-2021-44228 · first seen 4 Sept

Tenable.io WASJNDI injection on /loginhost-14 · CVE-2021-44228 · first seen 5 Sept

Tenable.scApache Log4j < 2.15.0 remote code execution10.20.4.17 · CVE-2021-44228 · first seen 3 Sept

Is 10.20.4.17 host-14? The rule can’t tell, so it waits for a person: merge, or keep apart.

Each scanner names the same problem its own way. Aegis matches them by rule (the same machine, the same weakness), never by a similarity guess, and keeps every original report word for word.

When the rule can’t tell whether two records are one machine, it doesn’t guess. The pair goes to the reconcile queue, and a person merges them or keeps them apart.

Now rank it: what does Log4Shell on host-14 score?

Why this score

Severity is not priority. Every score shows its working.

What it draws on: four public standards

CVSSCommon Vulnerability Scoring System · FIRST35%
How bad it would be if someone used it.
Log4Shell: 10.0 of 10
KEVKnown Exploited Vulnerabilities catalogue · CISA30%
Whether it is already being used against real systems. An observation, so it counts for more than a prediction.
Log4Shell: listed
EPSSExploit Prediction Scoring System · FIRST25%
How likely it is to be exploited in the next 30 days.
Log4Shell: 0.97, top 1%
ACSCAustralian Cyber Security Centre advisories · ASD10%
Whether Australia’s national cyber authority has warned about it.
Log4Shell: flagged

Example · Log4Shell on host-14

example estate

–.––Criticalfix by 9 Sept, 7 days from first seen

How Aegis puts them together

01BlendThe four signals are weighted and added into one score out of 10.
02FloorsRules the average can’t overrule: CVSS 9 or more is never below High; known to be exploited is never below High; CVSS 9 or more and in the top 10% for exploitation is Critical.
03The machineControls take some risk off: virtual patching 15%, EDR 10%, SIEM, antimalware and privileged access 5% each. Never more than 40% in all, and running as root cancels 10 points of it. Never below a floor.
04Band and dateThe result sets the band (Critical from 7, High from 5, Medium from 2.5) and, with how critical the machine is, the date it must be fixed by.

Every score keeps this working, so a priority can be argued with. These are Aegis’s defaults: each client can tune the weights, preview the effect and see the history of every change.

See a score worked out on a demo estate

Then date it. Why 7 days to fix Log4Shell on host-14?

Deadlines

Every exposure has a date, and the clock started before you called us.

Days to fix, by band and how much the machine matters
	Most critical	2	3	Least
Critical	7	7	14	30
High	30	30	30	60
Medium	60	60	60	90
Low	90	90	90	180

A machine nobody has rated counts as 3, and the exposure says so.

Example · Log4Shell on host-14

example estate

Critical, on a machine rated 2: 7 days from first seen

Working it out

Overdue since 9 Sept: 11 days 00:00, and counting.

See your deadlines on a demo estate

The fix · remediation

Fixed in Jira, proved by a scan.

11 days 00:00 overdue

01 · 20 SeptOpenedAegis opens SEC-412 in Jira, with the machine and how to fix it.
02 · 20 SeptDraftedThe model drafts the steps from the advisory; an admin approves them before anyone else sees them. It never touches a score, a match or a closure.
03 · 22 SeptDone in JiraThe engineer marks it Done. In Aegis that is a claim: still open, still counted.
04 · 23 Sept, 2:15 amProvedThe scan logged in to host-14, ran the Log4Shell check and found nothing. Closed. Had it not looked (no credentials, the check not run, the scan unfinished), it would stay open, and say why.

Jira · SEC-412

example estate

Upgrade log4j-core on host-14

Status To Do

How to fix it

1. Upgrade log4j-core to 2.17.1 or later.
2. Restart the service that uses it.
3. Until then, remove the JndiLookup class from the classpath.

Drafted by the model from the advisory · approved by an admin

Sent to the model: the machine’s class, operating system and version. Never its hostname, address, owner or cloud account.

Aegis · EXP-1042

linked to SEC-412

Log4Shell on host-14

StateOpen · 11 days 00:00 overdue

The proof

Scanned with credentials
Log4Shell check ran
Not found

23 Sept, 2:15 am · the scan that closes it is the one that looked

Reports

Reports an auditor can check, line by line.

Report · example estate

as of 21 Sept

Essential Eight, Maturity Level One

Patch applications: internet-facing, within two weeksEvidenced
Measured from each finding’s own first-seen date and deadline.
10exposures past their deadline
Patch operating systems: within one monthPartly evidenced
Aegis measures the clock, but can’t tell which machines face the internet.
Multi-factor authentication on internet-facing servicesNot evidenced
Aegis can’t see this, and the report says so rather than guess.

21 Sept. Log4Shell on host-14 is one of them, 12 days past its deadline.

No compliance percentage. A percentage hides which control failed; Aegis shows each one, with its evidence.

Mapped for the Essential Eight (ML1), CIS Controls v8 and NIST CSF 1.1, and each obligation says how well Aegis can evidence it, including when it can’t.

See the Essential Eight report on a demo estate

One or many

For one organisation, or a hundred clients.

I look after

Run Aegis for one organisation. The same product a provider uses for many clients, set to one.

One setting decides which. Nothing else changes.

One organisation: the estate you followed, Log4Shell and all.

Roles: Owner, admin, member. Kept short on purpose.
People: Invitations, seats, and handing over ownership.
Sign-in: Two-factor with an authenticator app; Google or GitHub.
Secrets: Scanner credentials kept in a vault, with an audit trail.

What Aegis will not do, however convenient it would be.

The fine print

1.Close a finding because a scanner stopped mentioning it.
2.Call a claim “verified”, or let a ticket marked Done close anything.
3.Count a collection that failed as a clean estate.
4.Let a model touch a score, a match or a closure, or show guidance an admin has not approved.
5.Show a number it cannot stand behind. It says “at least”, or nothing.

Where your data lives

Kept apart: Each organisation’s data is separated by the database itself, not only by application code.
Where it runs: As a service we operate. Running it inside your own environment is planned; ask us about it.
What AI sees: Three fields about a machine: its class, operating system and version. Never a hostname, an address or an owner.
What is kept: Every claim, check and closure, attributed to a person or a scan, with its evidence.

Built for security teams in larger organisations: one honest view across every scanner you run, owners who work in Jira, and numbers you can take to the board.

Aegis collects findings from the scanners you already run, turns them into one list of problems per machine, and closes a problem only when a scan has checked the machine again and found it fixed.

Visit

See it on a demo estate.

We'll walk you through a claim, a verification and a closure, with the evidence behind each.

Request a demo