SQL databases should have vulnerability findings resolved

What does the recommendation "SQL databases should have vulnerability findings resolved" check?

Flags any Azure SQL database whose Defender for Cloud SQL Vulnerability Assessment scan has returned unresolved findings: misconfigurations, excessive permissions, surface-area weaknesses and unprotected sensitive data measured against a rule baseline drawn from Microsoft's best practices. It reports the state of the most recent scan, so it only fires where vulnerability assessment is actually running, and it stays silent if no scan has completed rather than warning that scanning is off. It does not scan SQL Server on Azure VMs or Arc-enabled machines (a separate recommendation covers those), and it does not patch the database engine or detect runtime SQL injection attacks: it grades the configuration, not the live traffic.

Why does "SQL databases should have vulnerability findings resolved" matter?

Vulnerability assessment findings are the standing weaknesses an attacker reaches for once they have any foothold: a login granted db_owner it never needed, Transparent Data Encryption left off, server auditing disabled, or a column of personal data sitting unmasked in plain sight. Each unresolved finding widens the blast radius of a single compromised credential and can turn a contained incident into a reportable data breach with regulatory and customer-notification costs attached. Because every result is benchmarked against Microsoft's baseline, an open High finding is concrete, dated evidence that the database has drifted from a configuration an auditor expects, which feeds directly into SOC 2, ISO 27001 and PCI DSS scope and is exactly the artefact an assessor asks to see resolved.

How do I fix "SQL databases should have vulnerability findings resolved"?

1. Confirm the scan is current first: enable SQL Vulnerability Assessment in express configuration, which is the default for Microsoft Defender for SQL and needs no storage account, or repair the storage account behind classic configuration so a fresh scan can complete and the findings you act on reflect today's state.
2. Open the recommendation in Microsoft Defender for Cloud, work the findings worst-first by severity, and remediate each at source: revoke the offending grant, set 'Transparent data encryption' to On, enable auditing on the logical server, or apply Dynamic Data Masking to exposed columns rather than dismissing the alert.
3. For a finding that reflects a setting your environment genuinely needs, approve the current result as the baseline so the rule passes against your intended state; in express configuration the approval takes effect immediately, in classic it applies on the next scan, and either way future drift from that approved state still surfaces.

# Step 1: close coverage gaps. Enable the scanning plans on the subscription.
SUB="/subscriptions/00000000-0000-0000-0000-000000000000"

az security pricing create --name VirtualMachines --tier Standard
az security pricing create --name SqlServers       --tier Standard
az security pricing create --name Containers       --tier Standard

# Step 2: list the machines that still have no assessment solution attached.
az security assessment list \
  --query "[?metadata.displayName=='Machines should have a vulnerability assessment solution' && status.code=='Unhealthy'].resourceDetails.id" \
  -o tsv

# Step 3: ratchet it shut. Enforce that the plans stay enabled estate-wide,
# so no new subscription can become an unscanned blind spot. Assign the
# built-in initiative 'Configure Microsoft Defender for Cloud plans'
# (DeployIfNotExists), which turns the Servers, SQL and Containers plans
# back on wherever they are missing.
az policy assignment create \
  --name enable-defender-plans \
  --display-name "Configure Microsoft Defender for Cloud plans" \
  --policy-set-definition f08c57cd-dbd6-49a4-a85e-9ae77ac959b0 \
  --scope "$SUB" \
  --mi-system-assigned --location uksouth