Skip to content

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

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
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 17 additions & 3 deletions .github/workflows/cve_checks.yml
Original file line number Diff line number Diff line change
@@ -2,18 +2,32 @@ name: "Infra: CVE checks"
on:
pull_request:
types: [ "opened", "reopened", "synchronize" ]
paths:
- 'backend/**'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

@yeikel yeikel Apr 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- 'frontend/**'
- 'api/**'
- 'gradle/**'
- 'Dockerfile'
- 'build.gradle'
- 'settings.gradle'
push:
branches: [ "main" ]
paths:
- 'backend/**'
- 'frontend/**'
- 'api/**'
- 'gradle/**'
- 'Dockerfile'
- 'build.gradle'
- 'settings.gradle'
workflow_dispatch:
schedule:
# * is a special character in YAML so you have to quote this string
- cron: '0 8 15 * *'

permissions:
contents: read

jobs:

check-cves:
runs-on: ubuntu-latest

@@ -76,7 +90,7 @@ jobs:

notify:
needs: check-cves
if: ${{ always() && needs.build-and-test.result == 'failure' && github.event_name == 'schedule' }}
if: ${{ always() && needs.check-cves.result == 'failure' && github.event_name == 'schedule' }}
uses: ./.github/workflows/infra_discord_hook.yml
with:
message: "Attention! CVE checks run failed! Please fix them CVEs :("
Loading
Oops, something went wrong.