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

[shariqueahmad108-ship-it]

Done — rebased onto the latest dev and resolved the conflicts, @TFT444. The overlaps were purely additive: the compliance-framework JSONs and tests/test_rules_compute.py had gained the AZ-CMP-006/007 entries and tests since this branch was opened, so I kept both those and the AZ-CMP-005 additions. The branch now merges cleanly (no conflicts), all four framework JSONs are valid, and the compute rule tests pass (AZ-CMP-005 and AZ-CMP-007 side by side). Thanks!

[shariqueahmad108-ship-it]

Friendly ping on this one — it's green across all 20 checks and mergeable now that the rebase conflict and the ruff-format issue are both sorted. @TFT444 your original blocker (the set -u arg handling) was fixed back in the earlier commit, so happy for you to re-check or dismiss whenever you have a moment; @parthrohit22 good to merge if you're happy. Thanks both!

[TFT444]

My prior blocking issue (fix_az_cmp_005.sh crashing on missing args under set -u) is resolved in commit 50f5930. The playbook now uses RG="${1:-}" / VM="${2:-}" with the subsequent null-guard, matching the fix_az_net_016.sh pattern exactly as requested.

Blocker resolved

playbooks/cli/fix_az_cmp_005.sh lines 9-10: RG="${1:-}" / VM="${2:-}" are present, followed by the if [ -z "$RG" ] || [ -z "$VM" ] usage guard on lines 12-15. Running the script with no arguments now prints the usage message and exits 1 instead of crashing on unbound variables.

Rule correctness — no new issues found

• SDK fields verified: security_profile.security_type, security_profile.uefi_settings.secure_boot_enabled, uefi_settings.v_tpm_enabled, storage_profile.os_disk.managed_disk.hyper_v_generation all match the real azure-mgmt-compute models.
• azure_client.get_virtual_machines(), azure_client.get_disk(), and azure_client.parse_resource_id() all exist in scanner/azure_client.py.
• Indeterminate handling is correct: security_profile is None causes _trusted_launch_fully_enabled to return False and _os_disk_generation to return None, and the rule skips with no false finding. The uefi variable re-reads from security_profile before building finding metadata so None propagates cleanly.
• The Gen2-without-security-profile case is sound: security_type == "TrustedLaunch" is itself a Gen2 attestation, so no disk lookup is needed for TrustedLaunch-declared-but-vTPM-off.

RULE_ID collision with PR #275 — resolved

PR #275 originally claimed AZ-CMP-005. That was blocked in the #275 review and #275 was subsequently renamed to AZ-CMP-006. No collision exists.

Compliance mappings: All 4 framework JSONs include AZ-CMP-005. NIST CSF PR.DS-6, ISO 27001 A.12.5.1, SOC 2 CC6.8 are legitimate mappings. CIS uses N/A-CMP-005 with a clear rationale (no dedicated CIS Azure Foundations 2.0.0 recommendation), consistent with the existing AZ-KV-001 convention.

Test coverage: 6 tests cover compliant TrustedLaunch, non-compliant Gen2 with no security profile, TrustedLaunch-declared-but-vTPM-off, Gen1 NOT_APPLICABLE, unknown-generation skip, and Confidential VM skip. The intentional false-negative trade-off for unreadable-disk Gen2 VMs is documented and mirrors AZ-CMP-002's stance.

Playbook: bash -n passes. The az vm update invocation uses the correct flags (--security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true).

Note for maintainers: Vishnu2707's CHANGES_REQUESTED review remains active in the GitHub UI (same fix, same commit). The fix commit directly addresses that feedback; a maintainer should ask Vishnu2707 to re-review before merging.

[m-khan-97]

Thanks for the follow-up. I checked the current head (50f5930): the playbook now uses the safe argument defaults and a usage guard before any Azure command. Tanvir has already approved this revision; the remaining changes-requested review is from @Vishnu2707 on that same argument-handling issue. Vishnu, could you re-check the fix and update your review when you have a moment? @parthrohit22, your earlier approval was dismissed, so please refresh it against this head if you are still happy with the changes. Let us clear these through re-review before merging; I have not dismissed anyone’s review.

[parthrohit22]

Re-reviewed 50f5930.

The rule is in good shape and matches the fail-safe design I liked on the first pass:

• Gen1 VMs and VMs whose generation can't be confirmed as V2 are skipped, never flagged.
• security_type == "TrustedLaunch" with Secure Boot / vTPM off is flagged directly (TrustedLaunch is Gen2-only, so no disk lookup needed); everything else resolves the Hyper-V generation from the managed OS disk and only flags a confirmed V2.
• ConfidentialVM is correctly out of scope.
• _trusted_launch_fully_enabled() requires is True for both secure_boot_enabled and v_tpm_enabled, so a missing/None value is not treated as compliant.

fix_az_cmp_005.sh now runs under set -euo pipefail with ${1:-} / ${2:-} and a usage guard before any az call — the arg-handling issue from the earlier reviews is resolved (TFT444 has since approved). Framework mappings follow the existing convention (N/A-CMP-005 for CIS, real control ids for NIST/ISO/SOC2). 6 AZ-CMP-005 tests pass locally, bash -n on the playbook is clean, and all PR checks are green.

Approving. The only outstanding change request is @Vishnu2707's from Aug 17, which predates the set -u fix.