- 🇺🇸United States effulgentsia
With respect to security policy, while the security of dev dependencies is less critical than the security of production dependencies, we still don't want a requirement or side-effect of contributing to or maintaining core to be exposing your machine to security vulnerabilities. I have come across GitHub repositories where people report security vulnerabilities as public issues prior to those issues being fixed. Such issues usually don't yet have CVE identifiers, and security audit tools don't necessarily pick them up.
Because of this, I think it would be ideal for our dev dependencies to at a minimum have a security policy that states to not report security issues as public issues, and to instead contact the maintainer privately. This could be as simple as one or two sentences in a README.
However, I recognize that we already have some dev dependencies that don't have even that as an explicitly stated policy, and that the JS ecosystem doesn't yet have a culture of having such a policy for every single commonly used package that's out there. So, I'm conflicted on what the best balance between security and practicality would be for us with respect to JS dev/build packages.
- 🇬🇧United Kingdom catch
Our current policy tends to be that we document what the security policy is, even if that policy is 'nothing', then based on the specific character of the dependency, nothing might be fine or it might not be.
However documenting what it is often depends on opening an issue against projects asking them if they don't have one clearly documented, which sometimes results in a nice policy being written up, sometimes results in a 'won't fix'. So I guess the question really comes down to, do we want to make opening that issue a requirement for dev dependencies if there's not otherwise documentation of a security policy.
A further aspect to this is 'dependencies of dependencies'.