Security service

[terah]

Hi,

I just read https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/ and thought I'd add some ideas.

Sorry if this has been discussed before or is outside the scope of this project.

PHP has this security advisory service for packages: https://github.com/FriendsOfPHP/security-advisories

It would be useful for your dep tool to tell you that certain deps have known security issues.

[sdboyer]

It's a great suggestion, and not out of scope at all! We definitely need something like this.

Up until now, I've been more focused on the mechanics of dealing with insecure versions within the solver itself (I intend to model it after Cargo's yanking system). I haven't done a ton of thinking about what the service would look like that provides the information - obviously, we don't have anything like a crates.io to rely on for it right now.

Frankly, I'd love it if someone volunteered to step up and take some ownership over working out a design and API for such a system. hint hint 😉

[terah]

Hi Sam,

This is a project I'd enjoy getting my teeth into however I'm over committed for the next couple of months and it'd be irresponsible for me to take on another project right now. I will follow golang/dep but if someone else wants to pick up this component of it then go right ahead.

[sdboyer]

of course, i totally understand. i'd much rather people be honest about what their commitments are than overextend. the latter just ends up putting me in an awkward position!

hopefully we'll have it well underway by a couple months from now, but if not, well :)

[Alex-Wauters]

For similar examples, node has https://nodesecurity.io/ and for Java there's Owasp Dependency Checker. The latter is quite cumbersome as it needs to download the entire NIST NVD Data Feeds.

[nathany]

So what would this be? A Go-specific list of CVEs for version tags that dep caches locally and uses when resolving dependencies? Essentially an exclusion list with a specific purpose and error messages.

Something like that could provide the equivalent behaviour of a yanked package, but without having a central repository for the actual code.

Perhaps not entirely related, there are a few security scanning tools for Go such as:

• https://github.com/GoASTScanner/gas

[Alex-Wauters]

Another option which scanners such as GoASTScanner could include is to provide an api which, for a list of dependencies, can provide which versions are insecure and link to the relevant advisories. Someone does have to maintain the highly available list (as builds will depend on it) & ensure it is secure (to avoid DoS by including every package/version).

What the previously mentioned examples don't do and which I think should definitely be included in a Go dep scanner; is to check the version of Go itself (example: CVE-2016-3959). If go dep does not yet provide a standard way on how to define which version of Go should be used during the build (every PaaS will have its own definition on how to specify it, but if there were a standard way they could rely on it instead) it would be a good idea to add it (similar to the engine field in package.json for node).

[sdboyer]

What the previously mentioned examples don't do and which I think should definitely be included in a Go dep scanner; is to check the version of Go itself (example: CVE-2016-3959)

There's a similar need for this independent of the security considerations - simply, being able to indicate (or have the tool infer) the version of Go required by a project. Ideally, I'd like to see us deal with both of these at once.

If we treat them together, though, then it needs its own issue, as the handling of the toolchain version information itself is orthogonal to the security service.

[sdboyer]

So what would this be? A Go-specific list of CVEs for version tags that dep caches locally and uses when resolving dependencies? Essentially an exclusion list with a specific purpose and error messages.

Something like that, yeah. I'm more inclined towards an HA service.

[nathany]

build systems like Maven can not be relied upon to evict old versions.
https://opensource.googleblog.com/2017/03/operation-rosehub.html?m=1

[sdboyer]

From the link she linked to in that post, it seems like we shouldn't have the "lurking in transitive deps" problem if we design this right.

[zacps]

I'd be interested in helping with this.

Trying to brake down the steps we need to do:

1. Resolve package versions
2. Query a service to see if the resolved versions are secure.
3. Refuse to perform operations until the resolved packages are secure (bypass through a flag)

The first issue I can think of is when do this check. Obviously this has to be done every-time we resolve/update. Ideally a command like dep status would also check this. However I think this would make it too slow in normal use. Adding another command to check this is just a recipe for it being forgotten until the the dev updates dependencies. Might not be a problem with git hooks or CI though.

If/when we integrate with the go tool we could refuse to go build with insecure deps but I don't think a check at build is ideal either.

---

In terms of the service there are a few obvious options:

• Use the CVE list
• Use something controlled through version control, like git tags
• Use our own registry that could be updated by package authors or automatically from CVEs, git tags, or both