Hook Scorecard as a CI/CD solution, prevent bad deps from being added in code

[inferno-chromium]

No description provided.

[dlorenc]

Great idea!

I think we'd have to create a separate hook per language-package-manager that can parse out the dependency files and then call the scorecard tool.

It's probably going to be easier to do those hooks in whatever language we're handling.

Do we need a separate repo for each of those, or just one to hold them all?

[inferno-chromium]

Great idea!

I think we'd have to create a separate hook per language-package-manager that can parse out the dependency files and then call the scorecard tool.

It's probably going to be easier to do those hooks in whatever language we're handling.

Do we need a separate repo for each of those, or just one to hold them all?

Probably one to hold them all.

By default, we run all the hooks in the CI run. If it does not find package lock file for a particular pkg manager, it bails out. Different hooks can be different jobs in the CI run.

[inferno-chromium]

we need to make atleast one check run in cicd pipeline.

[ristomcgehee]

I think I'd like to start work on this issue. Here are some of my thoughts:

• Snyk has multiple open source projects that parse dependency files. They are all written for node.js, so if we are willing to have a dependency on Node, we could support many languages without a great deal of work. Here's a partial list of dependency parsers:
  • node.js
  • .NET
  • Go
  • Maven
• I would think most users would want to specify a minimum score necessary for dependencies. If so, this issue would be dependent on !346.
• I think users would also want a way to specify certain dependencies that can be allowed to be below the minimum score. This would be useful in an existing project where the goal would be to not add new dependencies below the minimum score.
• Users might also want to specify certain checks that must pass, e.g. enforcing that "Active" has a score of 10.
• Users can include a yaml file to specify options mentioned in previous bullets.

Thoughts on these points?

[kimsterv]

Bullets 2 - 4 all make sense to me!

For bullet 1, maybe it can be built in such a way to be pluggable so if there are other projects that parse dependency files, users would have options?

[ristomcgehee]

I do like the idea of a pluggable architecture. I think it would be good for our project to compile in parsers for at least the popular dependency files. That way the user can download a single binary, and it will work out of the box. We can then have an option for the user to configure their own parser.

I cloned one of the Snyk repos I mentioned, and I don't think that will be useful here. They are interested in constructing a graph of all dependencies which is not exactly useful to us.

I did find another project that looks more promising: https://github.com/aquasecurity/go-dep-parser. This can parse dependencies for go.mod, npm, pipenv, composer, and more. Since it's written in Go, we could could easily incorporate it. There are some dependency files that include include the git repo such as composer.lock. For these ones, we might want to write our own parser so it can read the repo directly and not have to look it up with a web call.

[azeemshaikh38]

Let's discuss this in our upcoming bi-weekly.

[laurentsimon]

did we forget to discuss this in the last meeting?
btw, there's also Google's deps.dev which offers a REST API and would do all the heavy lifting for us.

[ristomcgehee]

did we forget to discuss this in the last meeting?

I saw it wasn't on the agenda, but I didn't bring it up because I'll be working on another issue first. Plus I'll be pretty busy the next few weeks getting our house ready to list.

btw, there's also Google's deps.dev which offers a REST API and would do all the heavy lifting for us.

I'll definitely give that look!

[afmarcum]

Is this something that still needs to be discussed or can it be closed until it comes up again? Allowing 7 days for feedback.

[spencerschrock]

Going to point to ossf/scorecard-action#1070, as that seems to be relevant discussion. This can be re-opened here as needed.