refactor(preflight-checks): update workflow to use orchestrator and streamline permissions

[sudeeshna21]

• This PR Adds .github/workflows/qcom-preflight-checks.yml to run automated Qualcomm preflight checks on every PR and push to main. This workflow enforces project quality and compliance standards by running:

  Semgrep scan – static code analysis for security/bug patterns
  Dependency review – flags vulnerable or license-incompatible dependencies
  Repolinter check – validates repo structure against project standards
  Copyright/license check – ensures all files have proper license headers
  Commit email check – verifies commits are made with approved email addresses
  These checks help maintain code quality, security, and open-source compliance across contributions.

• Adds .github/dependabot.yml to enable automated dependency updates via GitHub Dependabot. It is configured to:

  Monitor GitHub Actions workflow dependencies (.github/workflows/)
  Check for updates daily and automatically open PRs when newer versions of used actions are available
  This ensures CI/CD workflows always use up-to-date, patched versions of GitHub Actions, reducing exposure to known vulnerabilities in third-party actions.

[R-Bower]

@sudeeshna21

Semgrep scan – static code analysis for security/bug patterns

• The semgrep scan takes ~10 minutes, sometimes more. I moved this from every PR to daily at 6am. I'd prefer to disable this on every PR.

[mynameistechno]

@njjetha do you know if with the updated Semgrep config (community edition) is the scan is faster than previous?

• The semgrep scan takes ~10 minutes, sometimes more. I moved this from every PR to daily at 6am. I'd prefer to disable this on every PR.

This is more of QPSI requirement, but I think a reasonable alternative is to disable for PRs and leave on for Pushes. I will ask them about this next time we sync I.e. when a PR is merged it'll run, and as long as you're reviewing the Critical/High severity (especially before a release!), that might be ok.

That said, ideally you'd catch security vulnerabilities before they get merged.

[mynameistechno]

@R-Bower are you sure it wasn't running on PR?

[njjetha]

@njjetha do you know if with the updated Semgrep config (community edition) is the scan is faster than previous?

• The semgrep scan takes ~10 minutes, sometimes more. I moved this from every PR to daily at 6am. I'd prefer to disable this on every PR.

This is more of QPSI requirement, but I think a reasonable alternative is to disable for PRs and leave on for Pushes. I will ask them about this next time we sync I.e. when a PR is merged it'll run, and as long as you're reviewing the Critical/High severity (especially before a release!), that might be ok.

That said, ideally you'd catch security vulnerabilities before they get merged.

@R-Bower Previously, Semgrep was executed on the entire repository for every pull request, regardless of the files changed.
Now, Semgrep runs only on the files modified in the PR, which significantly reduces execution time and improves efficiency.
Once the changes are merged, Semgrep will continue to run on the complete repository as usual, unless specific files or directories are excluded using the .semgrepignore file.

[njjetha]

LGTM !

[R-Bower]

@mynameistechno I replied here FYI.

[R-Bower]

@njjetha do you know if with the updated Semgrep config (community edition) is the scan is faster than previous?

• The semgrep scan takes ~10 minutes, sometimes more. I moved this from every PR to daily at 6am. I'd prefer to disable this on every PR.

This is more of QPSI requirement, but I think a reasonable alternative is to disable for PRs and leave on for Pushes. I will ask them about this next time we sync I.e. when a PR is merged it'll run, and as long as you're reviewing the Critical/High severity (especially before a release!), that might be ok.
That said, ideally you'd catch security vulnerabilities before they get merged.

@R-Bower Previously, Semgrep was executed on the entire repository for every pull request, regardless of the files changed. Now, Semgrep runs only on the files modified in the PR, which significantly reduces execution time and improves efficiency. Once the changes are merged, Semgrep will continue to run on the complete repository as usual, unless specific files or directories are excluded using the .semgrepignore file.

This is much faster than it was before, cool. I've merged the changes from this PR in another PR