Skip to content

Azure keyvault_logging_enabled false-fails with AuditEvent diagnostic category #11656

Description

@davletd

Issue search

  • I have searched the existing issues and this bug has not been reported yet

Which component is affected?

  • Prowler CLI/SDK

Cloud Provider (if applicable)

  • Azure

Steps to Reproduce

  1. Configure an Azure Key Vault diagnostic setting that enables the explicit AuditEvent log category.

  2. Azure ARM returns the diagnostic setting logs in this shape:

    category categoryGroup enabled
    AuditEvent null true
    AzurePolicyEvaluationDetails null false
  3. Run Prowler for Azure with the keyvault_logging_enabled check.

  4. Inspect the result for that Key Vault.

Expected behavior

keyvault_logging_enabled should pass when Key Vault audit logging is enabled through the explicit AuditEvent category.

Actual Result with Screenshots or Logs

Prowler reports the Key Vault as FAIL with a message that the vault does not have a diagnostic setting with audit logging.

The current check implementation only considers category groups:

log.category_group == "audit" and log.enabled
log.category_group == "allLogs" and log.enabled

It does not treat log.category == "AuditEvent" and log.enabled as compliant, even though Azure diagnostic settings may represent Key Vault audit logging with category: AuditEvent and categoryGroup: null.

How did you install Prowler?

From pip package (pip install prowler)

Environment Resource

Workstation / CI runner consuming Prowler OCSF output from Azure scans.

OS used

macOS

Prowler version

Observed on Prowler 5.15.1. The same category-group-only condition is still present on current master at the time of reporting.

Python version

Python 3.12 for local reproduction tests.

Pip version

Not applicable to the upstream code inspection; local validation used the repository uv environment.

Context

The check title and remediation describe Key Vault audit logging / AuditEvent, but the implementation requires audit and allLogs category groups. This can produce false failures where Azure shows AuditEvent logging enabled but does not populate categoryGroup for the diagnostic setting logs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugprovider/azureIssues/PRs related with the Azure providerseverity/lowBug won't result in any noticeable breakdown of the execution.status/waiting-for-revisionWaiting for maintainer's revision

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions