detekt / sarif4k

Kotlin data bindings for the Static Analysis Results Interchange Format (SARIF)
Apache License 2.0
15 stars 7 forks source link

Add default workflow for Gradle's dependency-submission action #89

Closed BraisGabin closed 5 months ago

BraisGabin commented 5 months ago

https://github.com/gradle/actions/blob/v3.0.0/dependency-submission/README.md#general-usage

Also from the README:

The gradle/actions/dependency-submission action provides the simplest (and recommended) way to generate a dependency graph for your project. This action will attempt to detect all dependencies used by your build without building and testing the project itself.

The dependency graph snapshot is generated via integration with the GitHub Dependency Graph Gradle Plugin, and submitted to your repository via the GitHub Dependency Submission API. The generated snapshot files can be submitted in the same job, or saved for submission in a subsequent job.

The generated dependency graph includes all of the dependencies in your build, and is used by GitHub to generate Dependabot Alerts for vulnerable dependencies, as well as to populate the Dependency Graph insights view.

(This is basically a cherry-pick from this PR: https://github.com/detekt/detekt/pull/6933)

BraisGabin commented 5 months ago

It's scary the list of dependencies that this simple project has: https://github.com/detekt/sarif4k/network/dependencies

TWiStErRob commented 5 months ago

I think for this to be as useful as #90 was, an admin (@BraisGabin @cortinico @chao2zhang?) has to press a button somewhere here: image

because this page is empty: https://github.com/detekt/sarif4k/security/dependabot

Compare with detekt.

BraisGabin commented 5 months ago

Done, now it isn't empty.

TWiStErRob commented 5 months ago

"Great"... thanks.

BraisGabin commented 5 months ago

And now it's empty. I must say that handle this kind of vulnerabilities is a PITA. It's completely different a vulnerability on gradle than a vulnerability that we introduce on the artifact that we release.

TWiStErRob commented 5 months ago

It doesn't mean we're providing vulnerable code, it means WE (our CI and our local machines) ARE vulnerable. We actually use XML because Gradle parses POM files. There's nothing we can do about this though other than report it to Gradle and keep it up to date.