Start using github security advisories

Joseph Reynolds jrey at linux.ibm.com
Fri Oct 29 01:22:18 AEDT 2021


On 10/28/21 8:43 AM, Patrick Williams wrote:
> ...snip...
> I want to reiterate three things:
>
>      1. In Github, security advisories are different from issues.  Security
>         advisories are suppose to be able to be collaborated on in private
>         without the repository itself being private.  Only when you are ready to
>         reveal the security advisory can you switch it to be public.

That matches my understanding.  The entire openbmc/security-response 
repo will be private to the OpenBMC security response team.
In this repo we will:
A. Track reported vulnerabilities under openbmc/security-response/issues.
B. Work on draft security advisories.

We don't have the exact workflow worked out.  I was thinking we could 
publish the security advisories under openbmc/openbmc/security.


Security advisory notes:
- The term "security advisory" as used here means the public 
announcement of a security vulnerability together with a mitigation 
(such as a fix or a workaround).  The OpenBMC security response team 
works on the security advisory in private, and then publishes these 
advisories when ready.  See the [guidelines][].
- IBM X-Force collects "security advisories" from all sources and 
publishes "security advisories" which it calls "security bulletins".  
The main distinction is advisories are input to the process, and 
bulletins are output.


[guidelines]: 
https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team-guidelines.md

>      2. We have two webhooks for Discord now: one for issues and one for code
>         changes.  Security advisories are not currently covered.  If you make an
>         issue in a public repository anyone can see it, even if it isn't covered
>         by a Discord webhook, so "limiting the awareness by avoiding the Discord
>         webhook" isn't really what you want anyhow.  You need to make sure the
>         information you want to be kept private is private (and again security
>         advisories are suppose to be the way to do that).

We plan to test the confidentiality of the openbmc/security-response 
repo with respect to discord.

>      3. Having a private repository means you cannot report any security
>         advisories (or issues) in a public way.  Today if someone goes to
>         https://github.com/openbmc/security-response they get a 404 (unless they
>         have explicit access to the private repository).

I was thinking we could publish the security advisories under 
openbmc/openbmc/security.
We are still trying to figure out the workflow.



More information about the openbmc mailing list