Update CVE checks workflow to trigger on changes in 'infra/' directory

[Brijeshthummar02]

• Breaking change? (if so, please describe the impact and migration path for existing application instances)

fixes #958

CVE checks will now run only when infrastructure files change. The workflow won't trigger for unrelated application code changes. Notifications will work correctly for scheduled runs if CVE checks fail.

What changes did you make? (Give an overview)

Is there anything you'd like reviewers to focus on?

How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)

• No need to
• Manually (please, describe, if necessary)
• Unit checks
• Integration checks
• Covered by existing automation

Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
• My changes generate no new warnings (e.g. Sonar is happy)
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged

Check out Contributing and Code of Conduct

A picture of a cute animal (not mandatory but encouraged)

[Brijeshthummar02]

@Haarolean what you think, good to go?

[Haarolean]

@Haarolean what you think, good to go?

not quite: It's the other way around - we need to run CVE checks only if the app's code is changed -- be it frontend or backend. So we need to think of list of paths to include here

[Brijeshthummar02]

@Haarolean what you think, good to go?

not quite: It's the other way around - we need to run CVE checks only if the app's code is changed -- be it frontend or backend. So we need to think of list of paths to include here

updated it any further changes needed?

[Brijeshthummar02]

@Haarolean Follow up on this PR.

[Haarolean]

I feel like there's no need to run these if the code itself been changed but not dependencies. What do you think @Brijeshthummar02 ?

cc @yeikel

[yeikel]

My understanding is that this check was designed only for vulnerability scans.

However, there is also a secret scanning feature enabled by default that runs as well.

Based on this, I believe we should not maintain any specific list and instead remove the manual paths configuration altogether, allowing scans to run on any project change, as secrets can theoretically leak in any file.

Alternatively, if we do not intend to use secret scanning, I agree that application-level changes do not need to trigger the CVE scan, and we should consider disabling secret scanning to speed up the CVE scan

Given the value of secret scanning, I suggest we leave it enabled and perform a full project scan as proposed above.

Alternatively, we can split these into two dedicate steps(one for CVE and another for secrets) as needed and maintain the lists. But I think that it ads unnecessary maintenance overhead for very little value. This check runs async and the cost should be low

[Haarolean]

Github offers secret scanning via other tools as well, not sure we need trivy for that but perhaps that won't hurt.

[yeikel]

My understanding is that these secret scans are based on heuristics and rules. It is probably a good idea to have both to benefit from the different rules/attempts to discover secrets