feat: add rule AZ-CMP-005 Trusted Launch (Secure Boot + vTPM) check

[shariqueahmad108-ship-it]

What

Implements Rule 1 of #269 — AZ-CMP-005, flagging Generation 2 VMs that don't have Trusted Launch (Secure Boot and vTPM) fully enabled. (Per the issue's Coordination note, the Managed Identity rule was descoped, so this PR is the sole remaining scope.)

Follows the scanner/rules/ one-file-per-rule template, with the matching remediation playbook and compliance-framework mappings.

Detection logic

• Compliant → security_type == "TrustedLaunch" and both uefi_settings.secure_boot_enabled and v_tpm_enabled are True.
• Gen1 = NOT_APPLICABLE. A VM's list_all() representation doesn't carry its Hyper-V generation, so the rule resolves the OS disk's hyper_v_generation (via azure_client.get_disk(), the same pattern AZ-CMP-002 uses) to confirm a VM is Gen2 before flagging. A readable Gen1 disk reports V1 and is skipped — no false finding against hardware that can't run Trusted Launch.
• security_type == "TrustedLaunch" but Secure Boot / vTPM off is Gen2-only by definition, so it's flagged without needing a disk lookup.
• Confidential VMs (Secure Boot + vTPM by construction) are out of scope and skipped.
• Unknown generation (OS disk unreadable / missing) is deliberately left unflagged — an unreadable disk could be Gen1, and the issue explicitly asks that Gen1 not produce a false finding. This mirrors the repo's existing "never treat an indeterminate result as a violation" stance (AZ-CMP-002). Trade-off: a Gen2 VM whose disk generation can't be read is a possible false negative; I erred toward zero Gen1 false positives, but happy to switch to surfacing it as a distinct low-severity/unknown result if you'd prefer the AZ-CMP-002 treatment.

Compliance mappings (all four framework JSONs)

Framework	Control	Rationale
NIST CSF	PR.DS-6	Firmware/software integrity verification (Secure Boot + vTPM measured boot)
ISO 27001	A.12.5.1	Installation of software on operational systems — only signed boot code runs
SOC 2	CC6.8	Prevents/detects unauthorized software at boot
CIS	N/A-CMP-005	CIS Azure Foundations 2.0.0 has no dedicated Trusted Launch recommendation, so this uses the repo's existing N/A convention (as in AZ-KV-001) rather than a fabricated control id — glad to renumber if there's a preferred mapping.

Tests

Six unit tests added to tests/test_rules_compute.py (mock-based, no network):

• compliant TrustedLaunch → no findings
• Gen2 (disk V2) without a security profile → one MEDIUM finding
• TrustedLaunch declared but vTPM off → flagged without a disk lookup
• Gen1 (disk V1) → NOT_APPLICABLE, no finding
• unknown generation (disk unreadable) → not flagged
• Confidential VM → not flagged

231 passed   # full rule-test suite (tests/test_rules_*.py + test_pqc_rules.py)
ruff check .            → clean
ruff format --check .   → clean

Honest testing note

I don't have an Azure subscription, so I could not run the issue's "tested against a real Azure free-trial subscription" step — the live checkboxes below are left unchecked for a maintainer/reviewer to confirm. The rule is fully covered by the unit tests above (compliant / non-compliant / Gen1 / unknown / confidential) and the fixtures mirror the real SDK attribute shapes (SecurityProfile.security_type, UefiSettings.secure_boot_enabled / v_tpm_enabled, Disk.hyper_v_generation).

Test plan (from the issue)

• Compliant case returns no findings (unit)
• Non-compliant case returns correct finding (unit)
• Gen1 VMs return NOT_APPLICABLE, not a false finding (unit)
• CLI playbook written (fix_az_cmp_005.sh)
• All four compliance framework JSONs updated
• Tested against a real Azure free-trial subscription (needs maintainer — no Azure access on my side)

Closes #269

[parthrohit22]

nice work @shariqueahmad108-ship-it ,
Solid rule. I like that you didn't just flag every VM without Trusted Launch - you actually resolve Gen1 vs Gen2 via the OS disk and treat "can't determine" as NOT_APPLICABLE instead of guessing, which keeps this from throwing false positives on VMs that physically can't support it. Confidential VM carve-out is a nice touch too. Verified the SDK fields (security_type, uefi_settings, secure_boot_enabled, v_tpm_enabled, hyper_v_generation) against the real azure-mgmt-compute models, all match. 562 passed, clean lint. No conflict with #275's AZ-CMP-006. LGTM, approving.

[Vishnu2707]

One thing before merge though, the playbook uses RG=$1 and VM=$2 directly, with set -u that'll just crash instead of showing the usage message if someone runs it with no args. Same issue @TFT444 flagged on KV-006 before, just needs ${1:-} and ${2:-} like fix_az_net_016.sh already does. That should be a quick fix though.

[Vishnu2707]

please use ${1:-} and ${2:-} like how it is present in fix_az_net_016.sh to avoid further bugs

[shariqueahmad108-ship-it]

Good catch @Vishnu2707 — fixed in 3415de1. Switched to ${1:-}/${2:-} (matching fix_az_net_016.sh) so a no-arg or partial-arg run prints the usage message and exits 1 instead of tripping set -u on an unbound variable. Verified both the zero-arg and one-arg cases now print usage cleanly. Thanks for the review!

[TFT444]

Single blocking issue: fix_az_cmp_005.sh uses RG=\ and VM=\ with set -u at the top. Running the script without arguments crashes before the usage message is printed. Change both to \ and , matching the pattern in fix_az_net_016.sh. Everything else looks good.

[shariqueahmad108-ship-it]

Thanks @TFT444 — that one's already handled: fix_az_cmp_005.sh was updated in 3415de1 to use RG="${1:-}" / VM="${2:-}" (lines 9-10, matching fix_az_net_016.sh), so a no-arg run prints the usage message and exits 1 instead of tripping set -u. Vishnu2707 raised the same point earlier and it's fixed on the current head. Could you re-check 3415de1? Happy to adjust if you're seeing something different.

[TFT444]

@shariqueahmad108-ship-it branch have conflict solve it please
thank u