Protocol for security audits

[wperron]

I think it would be interesting to have a standard to expose known vulnerabilities of third-party modules in the deno toolchain; A standard way for different registries to notify users that the modules they are importing contain known vulnerabilities. We had a discussion on Discord on the subject, using a header like X-Deno-Warning would be a simple solution.

My only issue with hijacking the existing X-Deno-Warning header is that it gets mixed with other warnings like implicit version resolution. Ideally I think something that can be used to check specifically for vulnerabilities and nothing else would be interesting; it could be used in a deno audit command for example, which could then be run periodically or in a CI pipeline.

How vulnerabilities are submitted and how this header would be populated would be a responsibility for each individual registry.

Related to #5840 and #3654

[wperron]

More than happy to provide a small proof of concept for that one too!

[chiefbiiko]

what about these two headers:

• x-deno-audit-vulnerabilities
• x-deno-audit-resolutions

How vulnerabilities are submitted and how this header would be populated would be a responsibility for each individual registry

imho the ecosystem would benefit from consistency in how vulns get reported and also pecularities as the header format

---

4 the vuln ingress part i suggest some sort of centralized vulnerability disclosure program see node.js third-party-modules on hackerone

i could prep all the things to setup a vulnerability disclosure program draft for hackerone if there is support for it ?

[wperron]

I don't really have an opinion about the exact name of the header, though I was thinking on limiting it to only one, criticality and resolution/fix can be crammed into a single header.

I agree that consistency is a good thing, but I would rather see a convention emerge from the community than to enforce one in the runtime. As for centralized vulnerability disclosure program: While I can definitely see the benefits, I think this is something that should come from userland instead, much like the runtime doesn't give preferential treatment to any module registry, I think we shouldn't give preferential treatment to any one source of vulnerabilities. And much like for module registries, hopefully in time we'll see the community aggregate around a few large vulnerability database indexes, something like Snyk for example.

[wperron]

So I made a small PoC for this, you can download the binary for linux here, and use this gist to try it out. The output looks a little something like this:

[wperron]

Just came across this proposal to Go for a central vulnerability database: https://go.googlesource.com/proposal/+/master/design/draft-vulndb.md

While Deno is very different from Go, they both share some commonality, especially with regards to decentralized package management, so maybe there's some inspiration to be had there.

[mxdvl]

Now that we have a lock file, it feels like this could be a matter of simply auditing it.

[CHE1RON]

With Deno hitting v2, I had the same reaction as @alpiua in this post on Reddit:

That's all good, but what's with audit?

Any news on this matter would be greatly appreciated, as this is the one blocker keeping us from migrating to Deno full-on 🤔