New security advisory tools

[jmacd]

There was an uptick in security advisories, with a bunch arriving for the opentelemetry-collector-contrib repo. Since that repo has a CODEOWNERS file, a tool was helpful to assign the individual owners who are not repository-level maintainers with access to the advisories. Secondly, for many of the new advisories, they are conditioned on allowing unauthorized access to a receiver port. Generally, these are not recommended configurations, and use of untrusted input with many components will lead to poor outcomes. I think the responsible thing to do in these cases is to downgrade the report to an issue, let the matter be resolved in the open and not file a CVE.

1. Tool to assign CODOEWNERS from the repository
2. Tool to downgrade a security advisory to an issue in the same repo, after scrubbing details about the reporter.

[reyang]

There was an uptick in security advisories, with a bunch arriving for the opentelemetry-collector-contrib repo. Since that repo has a CODEOWNERS file, a tool was helpful to assign the individual owners who are not repository-level maintainers with access to the advisories.

Maintainer as a role has been defined here https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer. CODEOWNERS can have OpenTelemetry community members who are not necessarily approvers or maintainers. Also, there are repositories which use https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/main/.github.qkg1.topponent_owners.yml instead of CODEOWNERS file.

Do we want to hold maintainers accountable (the maintainers can decide how they want to delegate and hold others accountable) or we want to hold a new set of folks accountable for security advisories?
If the answer is the latter (we want to hold a new set of folks accountable for security advisories), there are two things we need to socialize and get alignment:

1. Would the maintainers be okay with us putting folks accountable based on what CODEOWNERS file say? And what if they don't show accountability?
2. Do we need to define the role in the community doc (in addition to the roles we already have here https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md)?

[mx-psi]

Can we make sure when adding CODEOWNERS we add context in a comment as to what the security reporting process is, and, specially, that no public discussion of the issue should be had?

A couple more things that would be helpful (not necessary to do on this PR, I can move this to an issue):

1. It would also be helpful (not necessary to do on this PR) to automate creating a private fork of the PR. Not all maintainers have the ability to do that today (I don't at least!)
2. It would be helpful to have some sort of Slack notification on private channels with maintainers when a new security advisory is published. The Slack notification may not contain any private details but it can contain a link to the report (I think that should be safe).

[jmacd]

I meant to create helpful tools, not to settle policy questions of the nature posed above. I think we want to leave the maintainers responsible for advisories, with TC oversight as we have it today. The tool is meant to help maintainers easily assign the codeowners after reviewing the issue(s). As stated above, we need to set expectations for reviewers more clearly, especially about the need for secrecy.

Because of my TC rotation and being approver for collector-contrib, I took up the maintainer role this week and used the experience to develop these tools. I can say that one future-CVE leaked out as a result of my action, it confirms the need to be more careful when adding maintainers. I intend to use the downgrade-advisory script here on about 5 current advisories that are still pending in that repository.

I think we should add this sort of guidance to the recommendations.md document, after #156 merges.

[jmacd]

As a followup, I will work to document our expectations around maintainers assigning/inviting code owners to address vulnerabilities in contrib repositories. The TC has discussed that with the amount of work this implies, maintainers need tools, just not the ones we have here. We discussed a potential automation to create a private slack channel for each advisory, for maintainers, with a button to invite the codeowners using an automatically created private fork in github, for example. First, we will need a Slack registry for maintainers.