On 2023-07-11 13:51:02 -0700 (-0700), Ildiko Vancsa wrote: [...]
Related to the above, I wanted to bring up the project’s Vulnerability Management guidelines. While there is some documentation available on the StarlingX wiki[1] currently, it is not the easiest to find. As this is a crucial area, I think it would be a good time to both make sure that the information there is up to date, as well as to make the documentation easier to find. [...]
The main thing I worry about is users not being able to easily find instructions for how the StarlingX maintainers want them to report suspected security vulnerabilities. Some may guess, and may guess poorly, others may give up looking and just disclose it in public. This could result in a (preventable) scramble for everyone trying to deal with the results of those choices. Taking OpenStack as an example, in the footer of every page on openstack.org and related sites there's a "Security" link which goes to a dedicated documentation page about security topics (it uses a different subdomain than the project or docs sites but that's more of a historical implementation detail, if I were redoing it today I'd want to merge all the sites into one). At the very top of that security page is a section[*] which describes in detail how users should safely notify the maintainers of suspected vulnerabilities. Zuul has a similar page[**], linked from the main project documentation TOC (linking to it from more places would probably be a good idea as a future improvement). Once you have a security page, it can also become a convenient place to list your recent security advisories/patches, link to existing vulnerability management process documents, and potentially talk about security-specific features of StarlingX or security-relevant efforts within the StarlingX community as a sort of rallying point. [*] https://security.openstack.org/#how-to-report-security-issues-to-openstack [**] https://zuul-ci.org/docs/zuul/latest/vulnerabilities.html -- Jeremy Stanley