Closing what is open to the internet.
A bucket anyone can read. A database with a public address. SSH open to the world on a server nobody remembers building. Everyone agrees these matter. They keep coming back because the next deployment opens them again.
You will recognise this if
- Public access findings come back after every release.
- You know which buckets are public, but not which are meant to be.
- Snapshots and images were shared publicly years ago, and nobody has looked since.
- Old keys and service accounts still work, long after anyone last used them.
Exposure has more ways in than the public bucket.
Public buckets get the headlines. Shared snapshots, open queues, unused keys and databases in public subnets get less attention, and are often how a small mistake becomes a large one. These are what the NxSCORE scan checks for.
| Kind | AWS | Azure | Google Cloud |
|---|---|---|---|
| Storage | S3 buckets public, or writable by anyone; EFS and Glacier open to all | Blob containers with public access; storage accounts open to public networks | Cloud Storage buckets and BigQuery datasets open to all users |
| Network | Security groups and network ACLs open to the internet on SSH, RDP, CIFS or every port | SSH, RDP, HTTP and UDP open to the internet | Firewall rules allowing SSH or RDP from anywhere |
| Databases | RDS instances with public access; ElastiCache and Neptune in public subnets | SQL servers with public network access | Cloud SQL with a public address, or open to all |
| Snapshots and images | Public EBS snapshots and AMIs; snapshots shared outside your own accounts | Recovery Services vaults open to public networks | Machine images shared publicly |
| Services with their own policies | Lambda, ECR, KMS keys, Secrets Manager, SNS, SQS and OpenSearch open to anyone | App Service and Batch open to public networks | Cloud Functions, KMS keys and secrets open to all users |
| Credentials and other ways in | Access keys and roles unused for 90 days or more; public EKS endpoints | Databricks workspaces with public addresses; public addresses already listed by internet scanners | Unused service accounts and keys; public addresses already listed by internet scanners |
Your CNAPP checks many of these already. NxSCORE reads what it checks, and scans only what nothing else covers.
First, find every way in, and which ones are real.
A long list of public resources is not a plan. The first job is telling apart what is reachable, what is intended and what is only old.
- 01
Your CNAPP’s exposure findings, plus the ones it misses.
NxSCORE brings in your CNAPP’s open findings and checks the exposure controls the CNAPP does not cover, or has switched off. A public bucket raised by both is one finding.
The first sync also reads 90 days of resolved alerts, so the exposures that came back after a fix are clear from the start. Those are where a guardrail pays for itself.
Exposure, first assessmentExampleRaised by your CNAPP 286 Found by the NxSCORE scan only 97 Found by both, counted once 141 Came back after a fix, last 90 days 64 - 02
Reachable, not only marked public.
A public address on its own does not make a server reachable. NxSCORE’s own checks look at the whole way in for instances, databases and functions: the address, the route to the internet, and the rule that lets traffic through.
It also checks that snapshots are shared only with your own accounts, which a check for “public” alone would miss.
Can it be reached from the internet?Example- pay-batch-3, prod-paymentsReachable
Public address, a route to the internet, and port 22 open to anyone. All three at once.
- reporting-db, data-lakeNot reachable
Marked public, but in a subnet with no route out. Still a finding, ranked lower.
- snap-0f2e77, core-bankingShared outside
Shared with an account that is not one of yours.
- 03
Meant to be public, or not.
Some resources are public on purpose: a status page, a public download, a website served from a bucket. Before suggesting a fix, NxSCORE checks for that, and your analyst asks the owner when the evidence cannot decide.
The ones that should stay public get an exception, approved by your security team with a reason and an expiry. They stay on the list, marked as accepted.
Bucket ap-south-1-exports, core-bankingIn useWebsite hosting On Created by j.thomas, 11 August 2026 Question to the owner Is this site still used? If so, move it behind CloudFront first
Then close it, in order.
Exposure findings have the shortest fix-by dates. The order matters as much as the speed.
- 04
Ranked by what it reaches and how often it returns.
Priorities weighs each issue by its severity and the number of resources it touches, and lifts anything that came back after a fix, is past its fix-by date, or would clear a compliance requirement.
High-severity exposure gets 30 days by default. Your team can set a shorter date, and each finding shows whether it is overdue, due this week or on track.
PrioritiesExampleIssue Why it is high Fix-by S3 buckets that allow public access High, 58 buckets, came back after a fix Overdue SSH open to the internet High, 11 groups, 3 came back after a fix Due this week Public EBS snapshots High, clears 2 requirements On track - 05
A fix kit, with the usage check built in.
For a safe fix, NxSCORE writes the script your engineers run. It checks first and changes nothing, asks before it applies, and carries its own rollback.
Anything the usage check marked for review, such as a bucket that serves a website, is left out of the kit and listed, so it is decided by a person and not by a script.
nxscore-fix-public-snapshots.shExample fix kit in check mode$ bash nxscore-fix-public-snapshots.sh Check mode. Nothing will be changed. Account 6610-2284-0147, ap-south-1 would make private: 6 EBS snapshots would make private: 2 AMIs skipped snap-0f2e77: shared with 3381-xxxx, not public; check first Run with "apply" to make these changes. To undo later: bash nxscore-fix-public-snapshots.sh rollback - 06
Closed when the rescan agrees.
Your engineer asks for a rescan of that one control as soon as the change is made. The finding closes only when the rescan passes, or when the next assessment, or your CNAPP, no longer sees it.
Requirements that depended on it update on the compliance page at the same time.
Public EBS snapshots, core-bankingRescan passedMade private 8 of 8 in the kit Still open snap-0f2e77, with the owner Requirements cleared 2, updated on the compliance page
Then keep it closed.
Exposure stays closed when the cloud refuses to reopen it.
A fixed bucket is fixed until the next template creates a new one. The lasting fix is a rule in the cloud itself that does not allow it.
- 07
A guardrail for each way in.
When an exposure keeps coming back, your analyst writes a prevention plan aimed at where it comes from: a guardrail for the organisation, a default for each account, a fix to the template, or a check in the pipeline.
The plan is honest about limits. An organisation policy cannot read address ranges, so open admin ports are stopped in the pipeline, before deployment, instead.
Guardrails, AWSFrom the prevention libraryExposure Guardrail Note Public buckets Block Public Access for every account, and an organisation policy so nobody can turn it off Replayed first against 90 days of your activity Public snapshots and images An organisation policy that refuses public sharing of AMIs and snapshots, plus the account-level block Sharing with your own accounts still works Admin ports open to the internet Session Manager for admin access, the module fixed at the source, and a pipeline check An organisation policy cannot read address ranges, so this one is caught before deployment Long-lived access keys An organisation policy refusing new IAM users and keys, and a rule that flags any that appear Callers move to roles first - 08
Replayed against your activity before it is agreed.
Before a guardrail is proposed, NxSCORE replays your recent management events against it and shows who it would have stopped, with examples.
“Nobody in 90 days” is a strong reason to go ahead. “One deployment role, twice a week” is a reason to move that pipeline first.
What would this have blocked?Last 90 daysGuardrail No public sharing of AMIs and snapshots Who it would block Nobody in the last 90 days Busy accounts Sampled. Treat counts as a lower bound - 09
Verified after 14 quiet days.
NxSCORE marks a plan verified only after 14 days with no new findings for that issue. If a public bucket turns up after that, the plan goes back to applied, and your analyst finds the path it came through.
Prevention plan: S3 buckets that allow public accessVerified- AgreedYour security team chose the organisation guardrail.
- AppliedYour engineers attached it through the change process.
- Verified14 days with no new public buckets, in any account.
Who does what.
Closing an exposure is quick. Knowing it was safe to close, and that it stays closed, takes three sets of people doing their part.
Your NxSCORE analyst
- Separates what is reachable from what is only marked public
- Asks owners which public resources are meant to be
- Writes the fix kits, and the guardrail that stops each issue reopening
- Replays each guardrail against your activity before it is proposed
Your security team
- Decides the exceptions for resources that should stay public
- Agrees each guardrail, knowing who it would have blocked
Your engineers
- Run the kits, and fix the templates that create public resources
- Move callers off old keys before the keys are removed
- Apply the guardrails through your own change process
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.
Questions teams ask about this.
Our CNAPP already flags public resources. What does NxSCORE add?
Its own checks for what the CNAPP does not test, a separate answer to whether a resource can actually be reached, the usage evidence that says whether closing it is safe, and the guardrail that stops the next release opening it again. Findings both raise are counted once.
Some of our resources are meant to be public. What happens to those?
Your security team records an exception with the reason and an expiry no more than 12 months away. The resource stays visible, marked as accepted, and comes back for review when the exception expires.
Does NxSCORE test our resources from the internet?
No. It reads configuration with a read-only role: addresses, routes, security groups, firewall rules and resource policies. It does not send traffic to your systems.
Which clouds are covered?
AWS, Microsoft Azure and Google Cloud, with the checks listed on this page. The deepest guardrail library is for AWS. On every cloud, the fix is written for your engineers to run.
How fast should exposure be fixed?
Every finding gets a fix-by date from its severity: 30 days for high, 60 for medium and 90 for low, unless your policy says otherwise. Your team can set shorter ones, and the high date is always the shortest.
Will a guardrail break our deployments?
It might, which is why it is replayed first. For an organisation policy, NxSCORE reads the last 90 days of your CloudTrail management events and shows who it would have blocked, with examples, before your team agrees to it.
Start with the exposure that keeps coming back.
Connect one account with the read-only role. Your analyst shows you what is reachable, what is meant to be public, a fix kit for the rest, and the guardrail that would have kept the repeat ones closed.