[BUG] Multiple <env>.bicepparam creates multiple issues for findings in main.bicep

[o-l-a-v]

Existing rule

Azure.AppService.WebSecureFtp

Description of the issue

This happens with multiple rules, but let's take Azure.AppService.WebSecureFtp as an example.

We have a main.bicep that creates a br/public:avm/res/web/site:0.3.5 with siteConfig: {} that takes no parameters, so bicepparam should not affect this. In other works: All siteConfig: {} settings and values are defined inside main.bicep.

We then have multiple <env>.bicepparam, let's say test.bicepparam and prod.bicepparam.

Events:

• PSRule code scanning with https://github.com/marketplace/actions/psrule created one issue per <env>.bicepparam.
• We add siteConfig: {ftpsState: 'FtpsOnly'} to main.bicep and trigger a new PSRule scan.
• Only the issue tied to prod.bicepparam gets closed.

Error messages

None

Reproduction

See description.

Version of PSRule

2.9.0

Version of PSRule for Azure

1.36.0

Additional context

No response

[BernieWhite]

Hi @o-l-a-v, thanks for reporting the issue. Let me try to understand the issues here as it seems there may be more then one.

1. You are using br/public:avm/res/web/site:0.3.5 with siteConfig: {} and this is failing on several rules. Let's take Azure.AppService.WebSecureFtp for now.
2. The problem is being reported in test.bicepparam and prod.bicepparam and any other .bicepparam files that consume your custom main.bicep.
3. After addressing the problem in main.bicep the problem is fixed for prod.bicepparam but not in the other test.bicepparam files.

If this correct? or have I missed any key points here?

---

For (1), this is expected because the siteConfig: { } doesn't address several cases.

For (2), this is expected because PSRule for Azure operates based on what resources would deployed. Since test and prod are each individual cases they should each flag issues.

I agree however that a we could do better identifying the lines from main.bicep that are the cause of the issue. We intend to fix this however there is no timeline for a resolution at this time.

For (3), that is not intended behaviour from the sounds of it.

Can confirm you are exporting to SARIF and using GitHub Advanced Security? or is this reported in the pipeline output?

If you are exporting to SARIF can you scan please save the .sarif file with an artifact upload, then download and manually verify if the issues are still reported in the .sarif file after the pipeline completes/ fails.

[o-l-a-v]

I can only confidently confirm 2) for now.

After I created the issue I saw PSRule reported that Bicep failed to compile some environment, that might've impacted 3).

We changed the inputPath input parameter to point to the prod bicepparam file, instead of providing no value, and thus scanning the whole repo. It seems to behave as expected now.

Would like to not get spammed with three code scanning alerts for dev, stage and prod bicepparam using the same main.bicep in the future. And pointing to the problematic file (main.bicep) with correct line and character, would also be helpful. Looking forward to improvements here. 😊