3 ms·

In the wake of Log4shell I've spent some time thinking about how we can streamline the recovery from such large bugs. I suspect a lot of eyes are on this area n

In the wake of Log4shell I've spent some time thinking about how we can streamline the recovery from such large bugs. I suspect a lot of eyes are on this area now. Do y'all have any plans here? Figuring out what services are impacted by tracking the container images they use, the language runtimes in those images, the packages installed in each language runtime, that sort of thing. Currently this is all a huge manual, often spreadsheet-driven process.

coredog64 5y ago
Isn't that what Dependabot is? Github will already scan known package managers for CVEs for reporting purposes, and if you have the right kind of testing, you can allow Dependabot to manage the toil here. I worked at an i-bank that had their own version of Dependabot and it was great: New version(s) come out and once a week I get a PR to approve that shows that my code still passes tests after the update.
- akkartik 5y ago
  I'm not an expert, but my understanding of the space is that Dependabot shows vulnerabilities in direct dependencies of a repo. After reading greysteil's sibling comment, though, I wonder if something like Snyk does everything I mentioned. Operate at the level of container images and also detect vulnerabilities in indirect dependencies.
  - greysteil 5y ago
    Dependabot and Dependency Graph do detect indirect dependencies in repos (and create alerts and PRs for them) if they’re specified in a lockfile. So if you’re using bundler, npm, yarn, pipenv, composer, etc., and are committing your lockfile, you’re already covered. It’s cases we can’t scan (complicated cases like Gradle, where we really need to execute code to understand the dependencies) that the new API will help with.
greysteil 5y ago
We do a bit here already, and we've got plans to do more. For repositories using a language the GitHub Dependency Graph supports, we automatically create an inventory of the dependencies the repository uses and create alerts if/when any have a vulnerability (via Dependabot alerts and, as a sibling comment has already mentioned, Dependabot update PRs). The next improvement we'd like to ship is an API that lets you upload a list of dependencies to us for repositories in which we can't automatically detect them. A good example is repositories using Gradle for dependency management - it's hard for us to understand the dependency tree there without running a build. With the new API you'll be able to upload a list of dependencies (generated using a Gradle command) to GitHub in CI, and GitHub will then be able to send alerts if/when there's a vulnerability in one of those dependencies, just like we do for repos using other package managers. Your comment specifically mentions containers. That's one area that's a little further off for native GitHub support, but where the open source advisory database should help. Whilst we're currently focussed on scanning source code and surfacing results on repos (not containers), the structured data in the advisory database is just as usable with the results of a container scan. Indeed, I believe all the open source container scanning solutions already use it as a data sources.

coredog64 5y ago

Isn't that what Dependabot is? Github will already scan known package managers for CVEs for reporting purposes, and if you have the right kind of testing, you can allow Dependabot to manage the toil here. I worked at an i-bank that had their own version of Dependabot and it was great: New version(s) come out and once a week I get a PR to approve that shows that my code still passes tests after the update.

akkartik 5y ago
I'm not an expert, but my understanding of the space is that Dependabot shows vulnerabilities in direct dependencies of a repo. After reading greysteil's sibling comment, though, I wonder if something like Snyk does everything I mentioned. Operate at the level of container images and also detect vulnerabilities in indirect dependencies.
- greysteil 5y ago
  Dependabot and Dependency Graph do detect indirect dependencies in repos (and create alerts and PRs for them) if they’re specified in a lockfile. So if you’re using bundler, npm, yarn, pipenv, composer, etc., and are committing your lockfile, you’re already covered. It’s cases we can’t scan (complicated cases like Gradle, where we really need to execute code to understand the dependencies) that the new API will help with.

greysteil 5y ago

We do a bit here already, and we've got plans to do more. For repositories using a language the GitHub Dependency Graph supports, we automatically create an inventory of the dependencies the repository uses and create alerts if/when any have a vulnerability (via Dependabot alerts and, as a sibling comment has already mentioned, Dependabot update PRs). The next improvement we'd like to ship is an API that lets you upload a list of dependencies to us for repositories in which we can't automatically detect them. A good example is repositories using Gradle for dependency management - it's hard for us to understand the dependency tree there without running a build. With the new API you'll be able to upload a list of dependencies (generated using a Gradle command) to GitHub in CI, and GitHub will then be able to send alerts if/when there's a vulnerability in one of those dependencies, just like we do for repos using other package managers. Your comment specifically mentions containers. That's one area that's a little further off for native GitHub support, but where the open source advisory database should help. Whilst we're currently focussed on scanning source code and surfacing results on repos (not containers), the structured data in the advisory database is just as usable with the results of a container scan. Indeed, I believe all the open source container scanning solutions already use it as a data sources.