Skip to content

app_function_application_insights_enabled bug resulting in false positives #7298

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
b3n-j4m1n opened this issue Mar 19, 2025 · 2 comments · May be fixed by #7763
Open

app_function_application_insights_enabled bug resulting in false positives #7298

b3n-j4m1n opened this issue Mar 19, 2025 · 2 comments · May be fixed by #7763
Assignees
Labels
bug provider/azure Issues/PRs related with the Azure provider severity/high Bug capable of collapsing large parts of the execution.

Comments

@b3n-j4m1n
Copy link

Steps to Reproduce

prowler azure --check app_function_application_insights_enabled

Expected behavior

check is only looking for APPINSIGHTS_INSTRUMENTATIONKEY environment variable and not APPLICATIONINSIGHTS_CONNECTION_STRING, either or both means Application Insights is enabled, currently if only APPLICATIONINSIGHTS_CONNECTION_STRING exists Prowler will report it as a FAIL when it is actually a PASS.

Actual Result with Screenshots or Logs

n/a

How did you install Prowler?

Cloning the repository from github.com (git clone)

Environment Resource

workstation

OS used

Windows

Prowler version

5.4.0

Pip version

24.0

Context

suggested updates:

prowler\providers\azure\services\app\app_service.py

...
instrumentation_key=getattr(
    component, "instrumentation_key", "Not Found"
        ),
    connection_string=getattr(
        component, "connection_string", "Not Found"
        ),
...
...
class Component(BaseModel):
    resource_id: str
    resource_name: str
    location: str
    instrumentation_key: str
    connection_string: str
...

prowler\providers\azure\services\app\app_function_application_insights_enabled\app_function_application_insights_enabled.py

...
if function.enviroment_variables.get(
                    "APPINSIGHTS_INSTRUMENTATIONKEY", ""
                ) in [
                    component.instrumentation_key
                    for component in appinsights_client.components[
                        subscription_name
                    ].values()
                ] or function.enviroment_variables.get(
                    "APPLICATIONINSIGHTS_CONNECTION_STRING", ""
                ) in [
                    component.connection_string
                    for component in appinsights_client.components[
                        subscription_name
                    ].values()
...
@b3n-j4m1n b3n-j4m1n added bug status/needs-triage Issue pending triage labels Mar 19, 2025
@HugoPBrito HugoPBrito self-assigned this Mar 19, 2025
@HugoPBrito
Copy link
Member

Good catch @b3n-j4m1n !

Would you like to open a pull request with those changes?

@HugoPBrito HugoPBrito added severity/high Bug capable of collapsing large parts of the execution. provider/azure Issues/PRs related with the Azure provider and removed status/needs-triage Issue pending triage labels Mar 19, 2025
@puchy22 puchy22 linked a pull request May 16, 2025 that will close this issue
8 tasks
@puchy22
Copy link
Member

puchy22 commented May 16, 2025

Hi @b3n-j4m1n, you were right — we've added support for the APPLICATIONINSIGHTS_CONNECTION_STRING, you can check that changes in the PR #7763. We also realized that we were marking checks as FAIL if the Application Insights instance wasn’t in the same subscription as the App Function. This could lead to false positives when the App is actually connected to an Application Insights component in a different subscription or tenant.

To address this, we’ve now changed the logic to simply check whether either APPINSIGHTS_INSTRUMENTATIONKEY or APPLICATIONINSIGHTS_CONNECTION_STRING is present in the configuration. We understand this isn’t a perfect solution, since those values could point to a non-existent or misconfigured Application Insights resource — but at the moment, we don’t have the resources to validate that.

We’d love to hear your thoughts on this approach. Do you think it’s a reasonable compromise for now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug provider/azure Issues/PRs related with the Azure provider severity/high Bug capable of collapsing large parts of the execution.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants