The alert backlog that never gets shorter.
Your team closed a few hundred findings last quarter, and the queue is longer than when they started. Most of it is not new work. It is the same handful of mistakes, arriving again from the same places.
You will recognise this if
- A finding your team closed in March is back on the list.
- Nobody can say who owns half the resources in the queue.
- Exceptions live in a spreadsheet, so the tool still counts them as open.
- Most weeks end with more findings than they started with.
Sort the backlog by why it is still open.
A count of open findings tells you how big the problem is. It does not tell anyone what to do on Monday. Sort the same queue by the reason each finding is still there, and it turns into a short list of jobs.
- Came back after a fix342
Closed once, then reopened by the next deployment or by a change made by hand in the console.
- New copies of an old mistake296
A template or pipeline is still creating resources with the same setting, so every release adds more.
- No owner on the resource214
No owner or team tag, so the finding waits for somebody to claim it.
- Accepted, but only on paper87
Agreed over email or in a spreadsheet. The queue does not know, so it keeps counting them.
- New, one-off problems257
Genuinely new. Each one needs somebody to look at it properly.
In this example, 257 findings are new problems. The other 939 come from a few causes, and each cause can be dealt with once.
First, count it once and sort it by cause.
This is the work an NxSCORE analyst does with your team in the first days, in this order. Nothing in your cloud changes while it happens.
- 01
Bring everything into one list.
NxSCORE brings in your CNAPP’s open findings and runs its own scan for what the CNAPP does not check. When both flag the same failing setting on the same resource, it counts once.
The first sync also reads the last 90 days of resolved alerts. That is how findings that came back after a fix show up on the first day, instead of three months from now.
An account NxSCORE cannot reach is listed by name as not scanned. It is never counted as clean.
First sync, prod-paymentsCompleteOpen findings from your CNAPP 842 Found by the NxSCORE scan, not raised by your CNAPP 354 Resolved alerts read from the last 90 days 2,310 Of those, came back after a fix 342 Accounts not scanned 1: dr-site, read-only role missing - 02
Group findings into issues.
An issue is one mistake, wherever it appears. Public access on buckets in forty accounts is one issue to solve, not 214 alerts to close.
Each issue shows how many findings are open now, how many came back after a fix and how many are new in the last 30 days. An issue that came back after a fix, or that turns up week after week, is marked recurring.
Recurring issuesExampleIssue Open now Came back New in 30 days Prevention S3 buckets that allow public access 214 61 38 Agreed EC2 instances that still allow IMDSv1 181 44 30 None yet Access keys not used for 90 days or more 133 0 22 None yet Security groups open to the internet on port 22 96 27 11 Applied Storage accounts without secure transfer 18 0 0 Verified - 03
Put the issues in order.
The Priorities page ranks issues by severity and by how many resources they touch. It lifts anything that came back after a fix, is past its fix-by date, or would clear a compliance requirement once fixed.
Each issue also says how much work it is: one setting, a fix kit, or a change window. The quick wins, high impact for the least work, are where most teams start: they shrink the list fastest, and they show your engineers how the kits behave before the harder changes.
PrioritiesExampleIssue Why it is high Effort S3 buckets that allow public access High, 214 resources, came back after a fix One setting EC2 instances that still allow IMDSv1 Past its fix-by date, clears 3 requirements Fix kit Security groups open on port 22 High, came back after a fix Change window
Then clear it, safely.
Fixing fast is easy to promise. Fixing without breaking production is the part that decides whether a team keeps going.
- 04
A verdict before anyone touches it.
Before a fix is suggested, NxSCORE reads the evidence in your account: whether a key has been used in the last 90 days, whether a security group is attached to anything, whether a bucket serves a website, and who created the resource.
Each finding gets a verdict with its reason written next to it. Your team spends its judgement on the findings that need it, and not on the ones the evidence already settles.
VerdictsWith the reason- Access key for svc-reporting, data-lakeSafe to fix
Last used 214 days ago. Removing it breaks nothing that ran this quarter.
- Security group sg-payments-edge, prod-paymentsCheck first
Attached to two network interfaces behind the customer load balancer. Your team decides the change.
- Bucket ap-south-1-exports, core-bankingIn use
It hosts a website. Blocking public access would take it offline, so it moves behind CloudFront first.
- 05
A name and a date on every finding.
The owner comes from the resource’s own tags, in the order your organisation uses them: owner, team, application, cost centre or project. Your security team assigns whatever the tags cannot place, and the person assigned gets the finding with its fix attached.
Every finding has a fix-by date from its severity: 30 days for high, 60 for medium and 90 for low, unless your policy says otherwise. The list shows what is overdue, what is due this week and what is on track.
Fix-by, this weekExample- Public access on 58 buckets, prod-paymentsDue this week
team: payments-platform
- IMDSv1 on 44 instances, data-lakeOverdue
owner: r.iyer
- Unused key, svc-reportingOn track
application: reporting
- Port 22 open on bastion-drRisk accepted
team: infra-dr
- 06
A fix kit your engineers run.
For a safe fix, NxSCORE writes the script. It runs in check mode first and changes nothing. Apply asks before it acts. Rollback is in the same file, in case a change needs undoing.
One kit can cover every resource in an issue, so 58 buckets are one change in one window, not 58 tickets.
A finding is closed only when the next assessment no longer sees it. Your engineers can ask for a rescan of that one control straight away, instead of waiting for tomorrow’s run.
nxscore-fix-s3-public-access.shExample fix kit, run in check mode, then applied$ ./nxscore-fix-s3-public-access.sh check Checking 61 buckets in prod-payments, ap-south-1 would block public access on 58 skipped 3: website hosting is on, in use No changes made. Run with "apply" to make them. $ ./nxscore-fix-s3-public-access.sh apply Block public access on 58 buckets? [y/N] y done: 58 of 58 To undo: ./nxscore-fix-s3-public-access.sh rollback Then press Verify in NxSCORE to rescan.
Then stop it refilling.
A backlog stays down when its sources are closed.
Clearing the queue is half the job. The other half is making sure the same findings do not arrive again next week.
- 07
A prevention plan for each recurring issue.
When an issue keeps coming back, fixing the same resources again is the expensive way to handle it. Your analyst writes a prevention plan aimed at where the findings come from.
That can be a guardrail for the whole organisation, a default for each account, a change to the template that keeps creating the resource, a check in your pipeline, or a detective rule where blocking would be too much.
Your team agrees the plan and makes the change. NxSCORE marks it verified only after 14 days with no new findings. If the issue starts again, the plan goes back to applied and your analyst looks at why.
Prevention plan: S3 buckets that allow public accessApplied- AgreedYour security team chose the organisation guardrail.
- AppliedYour engineers made the change. 9 of 14 quiet days so far.
- VerifiedSet by NxSCORE after 14 days with no new findings.
- 08
Exceptions written down where they count.
Some findings are right to leave open. Anyone can ask for an exception, but only your security team can approve one, with a written reason and an expiry no more than 12 months away.
The finding stays visible, marked as accepted, so the queue tells the truth. When the expiry passes, it goes back on the clock.
Exception requestApprovedFinding Port 22 open on bastion-dr Reason Disaster recovery access, limited to the DR team’s fixed addresses Asked by infra-dr Decided by Security team, a second person Expires 31 March 2027, then back on its fix-by date
Who does what.
The work is shared out so that nobody marks their own homework: one person prepares, another approves, and the people who own the systems make the changes.
Your NxSCORE analyst
- Sorts the backlog into issues, and keeps it sorted as new findings arrive
- Prepares each verdict from the evidence in your account
- Writes the fix kits and the prevention plans
- Asks owners the questions the evidence cannot answer
Your security team
- Approves any change to a verdict, as the checker
- Assigns the findings that tags cannot place
- Decides every exception, with a reason and an expiry
- Agrees each prevention plan before it is made
Your engineers
- Run the fix kits in their own change window
- Change the template or pipeline that keeps creating the problem
- Use the rollback in the same kit if a change needs undoing
NxSCORE’s access to your cloud is read-only. Every change on this page is made by your people, through your own change process. Read every permission.
Watch what arrives, not only what is closed.
A team can close two hundred findings a week and still fall behind. The Trends page puts what was found each week, new or back again, beside what was fixed, and shows what was still open when the week ended.
| Week | Found, new or back again | Fixed | Open at the end of the week |
|---|---|---|---|
| Week 1 | 140 | 96 | 1,240 |
| Week 2 | 128 | 152 | 1,216 |
| Week 3 | 96 | 188 | 1,124 |
| Week 4 | 74 | 210 | 988 |
| Week 5 | 52 | 176 | 864 |
| Week 6 | 41 | 158 | 747 |
| Week 7 | 30 | 133 | 644 |
| Week 8 | 26 | 120 | 550 |
The same page shows the median time to fix for each severity, and how many findings were fixed by their fix-by date. When a prevention plan holds, the found column is the one that falls.
Questions teams ask about this.
Will NxSCORE add even more findings to the queue?
At first, it may. NxSCORE scans for what your CNAPP does not check, and those findings are real. They go into the same issues as everything else, so the list your team works from gets shorter even while the raw count goes up.
Does NxSCORE close findings for us?
No. Your engineers make every change, and NxSCORE’s access to your cloud is read-only. A finding is closed only when a later assessment, or your CNAPP, no longer sees the problem. Whoever made the fix is never the one who confirms it.
Our CNAPP already groups alerts. What is different?
Your CNAPP groups what it raised. NxSCORE adds what it did not raise, reads 90 days of resolved alerts so repeat findings are visible from the start, and follows each issue past the fix: an owner, a fix-by date, a prevention plan, and a check that the plan held.
Do we have to fix everything in the backlog?
No. Some findings are right to leave open. The difference is that each exception is written down, approved by your security team, and expires within 12 months, instead of living in a spreadsheet the tool cannot see.
How long does it take for the backlog to come down?
That depends on how much of your backlog comes from a few causes, and how quickly your team can make the changes. The first assessment shows that split for your own accounts, so you can plan from your own numbers rather than an average.
Which clouds and CNAPPs does this work with?
AWS, Microsoft Azure, Google Cloud and Oracle Cloud, alongside Prisma Cloud, Cortex Cloud, Wiz, Orca or Tenable. If you have no CNAPP, the NxSCORE scanner does the finding on its own.
Start with one account.
Connect one account with the read-only role. After the first assessment, your analyst takes you through your own backlog: how it splits by cause, the few issues that make up most of it, fix kits for the quick wins, and a prevention plan for the issue that comes back most.