Network security groups attached to no subnet and no NIC
What does ZopNight detect here?
An Azure NSG is free, so ZopNight reports detached security groups as a $0 hygiene finding, not a saving. The rule hardcodes zero and ignores pricing entirely. Detection reads the discoverer's associated flag: an NSG linked to 0 subnets and 0 network interfaces protects nothing.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1361 |
| Category | orphan |
| Severity | low |
| Metric | none — pure configuration read |
| Source | nsg_unused.go |
Where it applies
Rules that guard nothing
A network security group only does its job while attached to a subnet or a NIC. Detached, it is a list of allow/deny rules enforcing nothing, usually the residue of a deleted VM or a rebuilt network. The discoverer checks both association surfaces and stamps the NSG’s state; only an explicit not-associated verdict fires the rule. Unknown association state fails safe and is never flagged.
A finding that refuses to invent dollars
NSGs carry no standing charge, so the honest saving from deleting one is exactly $0, and that is what the recommendation says. The rule’s pricing injection is a deliberate no-op: even if a cost entry collided onto the NSG’s identifier, it could not surface as a fabricated saving. The finding rides in ZopNight’s orphan category, which is exempt from the minimum-dollar filter precisely so zero-dollar cleanup work stays visible.
Why bother, then
Orphaned NSGs cost attention rather than money. Every security review, terraform plan, and incident investigation has to reason about them; a stale NSG with permissive rules is a ready-made mistake when someone attaches it to the wrong subnet later. Fewer unowned security objects means a smaller audit surface. In subscriptions several years old it is common to find dozens of these, one per deleted VM, each preserving the inbound rules of a machine that no longer exists.
Find detached NSGs across a subscription
az network nsg list \ --query "[?subnets==null && networkInterfaces==null].{name:name, rg:resourceGroup}" \ -o tableOr inspect one NSG’s associations directly:
az network nsg show -n <nsg> -g <rg> --query "{subnets: subnets, nics: networkInterfaces}"Keep or delete
Some teams intentionally stage NSGs ahead of attachment: a golden ruleset waiting for the next environment. If that is the case, document it where the next reviewer will look. Otherwise delete: the rules are recoverable from source control or the activity log, and recreating an NSG takes minutes.
What the rule never does
No metrics are read, no cost map is consulted, and no automation deletes an NSG on ZopNight’s behalf. The finding is informational. Reader alone reproduces the entire detection.