fix(scanner): resolve COR-001-004 scanner correctness issues (#151)

[safidnadaf]

What does this PR do?

Fixes four scanner correctness bugs: case-sensitive direction check and ignored plural source prefixes in az_net_003, a false positive on API failure in az_db_002, and a KeyError on malformed ARM IDs.

Type of change

[x] Bug fix

Testing

[x] Returns correct JSON output
[x] No hardcoded credentials or secrets

Related issue

Closes #151

Checklist

[x] I have not committed any real Azure credentials

Details

COR-001: direction check is now case-insensitive
COR-002: now checks both singular and plural source prefix fields
COR-003: API failures now skip the resource instead of falsely flagging it
COR-004: malformed ARM IDs no longer cause a crash

Added 9 regression tests covering all four fixes. All tests pass locally (16/16 affected, 83/83 full suite).

[Vishnu2707]

@ritiksah141 , can u have a look at this, if this will be disrupted by the new PR or not. Do provide your reviews as well.

[Vishnu2707]

@parthrohit22, @SHAURYAKSHARMA24 , can you do the initial review of this PR pls.

[ritiksah141]

I reviewed this end to end and checked the interaction with the newer infra/CI work.

Functional review:

• The scanner fixes look correct for the stated COR-001 through COR-004 issues.
• I do not see a runtime disruption because this PR only touches scanner rule logic, the Azure client helper, and scanner tests.
• GitHub reports the PR as mergeable against dev.
• A merge preview shows overlap in the same six files with latest dev, but no conflict markers. That should be an auto-merge/update concern rather than a manual conflict.

Blocking issue:

1. The branch is not passing the newer format gate from dev.

   Current dev now has ruff format --check . in CI. Running the formatter check locally against the files touched in this PR fails:

   ruff format --check scanner/azure_client.py scanner/rules/az_db_002.py scanner/rules/az_net_003.py tests/helpers/mock_azure.py tests/test_rules_database.py tests/test_rules_network.py

   Result:

   Would reformat: scanner/azure_client.py
   Would reformat: scanner/rules/az_db_002.py
   Would reformat: scanner/rules/az_net_003.py
   Would reformat: tests/helpers/mock_azure.py
   Would reformat: tests/test_rules_database.py
   Would reformat: tests/test_rules_network.py
   6 files would be reformatted
   

   Example locations include tests/test_rules_network.py:8, tests/test_rules_network.py:109, scanner/rules/az_db_002.py:36, and scanner/rules/az_net_003.py:51. Please rebase or merge latest dev, run ruff format on the touched files, and push so the PR is validated under the newer CI workflow.

Validation I ran locally:

ruff check scanner/azure_client.py scanner/rules/az_db_002.py scanner/rules/az_net_003.py tests/helpers/mock_azure.py tests/test_rules_database.py tests/test_rules_network.py
ruff format --check scanner/azure_client.py scanner/rules/az_db_002.py scanner/rules/az_net_003.py tests/helpers/mock_azure.py tests/test_rules_database.py tests/test_rules_network.py
pytest tests/test_rules_network.py tests/test_rules_database.py
pytest tests/test_rules_network.py tests/test_rules_database.py tests/test_clean_scan.py
pytest
bandit -r scanner/ -ll

Results:

• Focused rule tests passed: 16 passed.
• Rule plus clean-scan tests passed: 24 passed.
• Targeted ruff check passed.
• ruff format --check failed on the six touched files.
• Full pytest had one local AI vector-store failure in tests/test_ai_hallucination_guard.py::TestHallucinationGuard::test_vector_store_purity due ONNX Runtime not being able to create a working directory under the local temp path. That does not appear related to this scanner PR.
• bandit -r scanner/ -ll reports existing scanner findings in scanner/nvd_client.py and scanner/rules/az_db_004.py, not in the files changed by this PR.

Once the formatting/update is fixed, I think the scanner logic itself is in good shape.

[SHAURYAKSHARMA24]

Requesting changes.

The scanner fixes are in the right direction, but I found production-path issues that are not covered by the current tests.

1. AZ-NET-003 may fail with real Azure SDK enum-backed fields.

The rule normalises direction and access using str(...) and compares against "inbound" / "allow". However, the Azure SDK model allows these fields to be either plain strings or enum values (SecurityRuleDirection, SecurityRuleAccess). If an SDK enum instance is returned, stringifying it may not produce "Inbound" / "Allow", so the rule can miss real non-compliant NSG rules even though the mock-string tests pass.

Please normalise enum values safely, for example by checking .value when present, and add regression coverage using azure.mgmt.network.models.SecurityRule rather than only SimpleNamespace/string-backed mocks.

2. AZ-DB-002 has the same enum-normalisation risk.

The SQL auditing policy model allows state to be either a string or BlobAuditingPolicyState. The current logic uses str(getattr(policy, "state", "Disabled")).lower() != "enabled". If a real SDK enum is returned, an enabled policy may be treated as disabled, creating a false positive. The existing test passes because it uses state="Enabled" as a plain string.

Please normalise the policy state safely and add regression coverage using the real Azure SQL auditing policy model.

3. Current dev CI is still not satisfied.

The current dev workflow runs both:

ruff check .
ruff format --check .

The six touched files still need to be formatted against the current dev gate. Please update the branch from dev, run formatting on the touched files, and rerun CI.

Non-blocking follow-ups:

• parse_resource_id() returning resource_group="" avoids the KeyError, but scanner rules should explicitly skip/log malformed IDs instead of silently calling downstream API helpers with an empty resource group.
• For AZ-NET-003, findings triggered through source_address_prefixes should include the matched plural source prefix in metadata/evidence.
• Consider IPv6 unrestricted source ranges such as ::/0 and plural destination port ranges in follow-up coverage.

Because the production SDK-model paths are not properly covered, I cannot approve this as a scanner-correctness fix yet.