Can it work with normal push instead of just pull request?

[umeshnebhani733]

We are not using a pull requests, we tried using it for normal push as follows, however it seems to be not working as we want it to be.

Here is our usecase:

• We want to ensure no one is pushing a code with lib having a licence outside of allowed list of license. If that happens pipeline should fail
• We have collected a list of allowed license approved from a legal department & want to enforce it for all push happening on any pipeline in future.

Here is how my pipeline looks like `name: Dependency Review

on: push: branches:

• main paths-ignore:
• '.talismanrc' pull_request: branches:
• main

permissions: contents: write

jobs: dependency-review: runs-on: ubuntu-latest steps:

• name: Checkout Repository uses: actions/checkout@v4

• name: Set up JDK 17 uses: actions/setup-java@v2 with: distribution: 'adopt' java-version: '17'

• name: Dependency Review uses: actions/dependency-review-action@v4 with: config-file: './.github/dependency-review-config.yml' base-ref: ${{ github.event.pull_request.base.sha || github.event.before || github.sha }} head-ref: ${{ github.event.pull_request.head.sha || github.sha }}

• name: Show Review Results run: | echo "Licenses Denied: ${{ steps.dependency-review.outputs.licenses_denied }}" echo "Vulnerabilities: ${{ steps.dependency-review.outputs.vulnerabilities }}"

• name: 'Report' if: ${{ failure() }} run: | echo "Review failed. Licenses Denied: ${{ steps.dependency-review.outputs.licenses_denied }}" echo "Vulnerabilities: ${{ steps.dependency-review.outputs.vulnerabilities }}"`

  2 problems i am facing: 1) scan the existing licences n highlight if there are any licences not part of allowed list 2) even for new code change its not working as we expect for normal push

[ebickle]

@umeshnebhani733 I'm not on the GitHub team, but have looked into something similar.

The dependency review action depends on a difference API; that's why it doesn't work on push and is not very likely they'll add support for it.

If you don't building your own solution:

• Create a custom GitHub app - it doesn't need to be fancy, just handle the push webhook
• On a push, check if any created/updated/deleted files have the filename of a known package manager you care about (e.g. package.json, package-lock.json, 'requirements.txt`... I think I identified around 30 of them, but in my case I wanted to line up with everything Dependabot supports. Only continue if a "package manager file" was updated.
• Call the SBOM API to get a flat list of the repository's dependencies and their licenses (licenseConcluded and licenseDeclared). Compare the license against your allowed/prohibited list and create an issue in your issue tracker to follow up with the team.

If you use dependency submission, you'll also have to worry about race conditions with that workflow since it will also run on a push and update the dependency list. An artificial delay in GitHub app processing could help here, I suppose :D It's also worth noting some things could still slip through the cracks - a push with a very large number of changes won't fire the push webhook. But catching 99.99% of the changes is likely better than 0%.

Another idea I had passed to me from a GitHub support rep is using repository custom properties to store metadata - you could have an invalid_license: boolean custom property that the GitHub app updates. Then to find all the non-compliant repos, you can just grab the list directly from the repositories list or via API (assuming the app keeps the property updated).

It's not an insignificant amount of work, but once you have the app you can use it to drive a lot of custom security behavior. It was worth it in our case.