Reporting security vulnerabilities via Github Private security vulnerability ?

[Jarek Potiuk <ja...@potiuk.com>]

Hello everyone here,

I have recently seen the announcement that GitHub enabled security
vulnerability private reporting to be managed globally for
organisations:

https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability

Since currently we are using security@ in our policy, I was just
wondering if there are ways the GitHub reporting can be leveraged as
well (Additionally to mailing lists maybe rather than replacing it for
projects that already use GitHub)

I am not sure if that is needed or necessary, or whether it could
fit-in the current process? Or maybe we do not want to use it at all
(there are certain properties of using a mailing list that make it
less noisy than Github reporting I think and I believe we have some
integrations that make it easier to manage than issues reported in
multiple repos).

Just wanted to raise it here, maybe people do not realise that as of
recently this capability exists in GitHub.

Or maybe someone already uses it and has some experiences to share?

J.

---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org

Re: Reporting security vulnerabilities via Github Private security vulnerability ?

[Jonathan Leitschuh <jo...@gmail.com>]

As a security researcher, I would greatly appreciate this!

I personally significantly prefer using GHSA to disclose vulnerabilities.
Being able to use GitHub flavored markdown for disclosures is wonderful for
formatting detailed information.

Additionally, the exact lines that are vulnerable can be rendered in the
advisory body simply by adding a permanent link to the lines within the
advisory. This lets me include details like exploitation path information
in the disclosure in a way that renders really nicely.

Just my two cents.

Cheers,
Jonathan Leitschuh

On Sat, Jan 28, 2023 at 2:38 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Hello everyone here,
>
> I have recently seen the announcement that GitHub enabled security
> vulnerability private reporting to be managed globally for
> organisations:
>
>
> https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability
>
> Since currently we are using security@ in our policy, I was just
> wondering if there are ways the GitHub reporting can be leveraged as
> well (Additionally to mailing lists maybe rather than replacing it for
> projects that already use GitHub)
>
> I am not sure if that is needed or necessary, or whether it could
> fit-in the current process? Or maybe we do not want to use it at all
> (there are certain properties of using a mailing list that make it
> less noisy than Github reporting I think and I believe we have some
> integrations that make it easier to manage than issues reported in
> multiple repos).
>
> Just wanted to raise it here, maybe people do not realise that as of
> recently this capability exists in GitHub.
>
> Or maybe someone already uses it and has some experiences to share?
>
> J.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
> --
Jonathan Leitschuh
OSS Security Researcher
Dan Kaminsky Fellowship @ Human Security
GitHub Star <https://stars.github.com/profiles/jlleitschuh/>
Twitter - JLLeitschuh <https://twitter.com/JLLeitschuh>

Re: Reporting security vulnerabilities via Github Private security vulnerability ?

[Arnout Engelen <en...@apache.org>]

On Wed, Jul 5, 2023 at 9:11 AM Hen <ba...@apache.org> wrote:

> I suggested to GitHub's product owner for this that they add
> the ability to redirect/notify an email address so that groups like the ASF
> with a clear email-based security reporting process could connect the PVR
> into their existing processes, rather than having to build a completely new
> secondary process to support any reports they get on GitHub.


Thanks! Since there is an API[0] to list privately-reported
vulnerabilities, we could probably even arrange such notifications
ourselves.

On Wed, Jul 5, 2023 at 9:24 AM Jarek Potiuk <ja...@potiuk.com> wrote:

> It would be great if we could switch eventually to the Github reporting
> mechanism.
>

I don't think 'switching' is on the table, we want to continue to allow
reporters to submit reports via email. It is definitely interesting as an
additional channel, though.


> It helps A LOT when it comes to managing the issues, organising discussions
> about them, linking, labelling and all the kinds of things that make Github
> a fantastic "issue management" solution.
>

I'm happy it is working so well, though it might in part be so helpful
because of the hopefully-temporary situation that you have unusually many
issues in flight ;).


> the pain we have is that this requires manually copying the security
> reports and creating an issue for every such report manually and occasional
> switching issue/mail. (...) We keep the
> link to the mailing discussion in the Github Issue of ours, so it is not
> overwhelming and workable, but it adds quite an extra overhead.
>
> It would be great if we could remove that step, and get rid of the separate
> project we have. I think we have already proven how useful it is to have
> organised this way and it helped us to organise and manage our security
> issue handling, so getting the Github private reporting working and
> integrated with our expectations would be a significant improvement.
>

I think the main missing piece of the puzzle is that the API doesn't expose
comments on advisories, so AFAICS we have no mechanism to copy those to the
project security mailinglist. This is needed so we create an archive there,
and members who are not part of the GitHub repo also get notified. Let's
highlight that to GH. We could also experiment with using their email
notifications for that somehow, but that seems brittle.


Kind regards,

Arnout

[0]
https://docs.github.com/en/rest/security-advisories/repository-advisories?apiVersion=2022-11-28

On Wed, Jul 5, 2023 at 9:11 AM Hen <ba...@apache.org> wrote:
>
> > On Mon, Jun 5, 2023 at 3:06 AM Arnout Engelen <en...@apache.org>
> wrote:
> >
> > > On Wed, Feb 1, 2023 at 6:33 PM Arnout Engelen <en...@apache.org>
> > wrote:
> > > > On Sat, Jan 28, 2023 at 8:38 PM Jarek Potiuk <ja...@potiuk.com>
> wrote:
> > > > > Since currently we are using security@ in our policy, I was just
> > > > > wondering if there are ways the GitHub reporting can be leveraged
> as
> > > > > well (Additionally to mailing lists maybe rather than replacing it
> > for
> > > > > projects that already use GitHub)
> > > > >
> > > > > I am not sure if that is needed or necessary, or whether it could
> > > > > fit-in the current process? Or maybe we do not want to use it at
> all
> > > > > (there are certain properties of using a mailing list that make it
> > > > > less noisy than Github reporting I think and I believe we have some
> > > > > integrations that make it easier to manage than issues reported in
> > > > > multiple repos).
> > > > >
> > > > > Just wanted to raise it here, maybe people do not realise that as
> of
> > > > > recently this capability exists in GitHub.
> > > >
> > > > I think it could indeed be interesting.
> > >
> > > The feature to create a temporary private fork for an advisory could
> > > also be attractive for some projects.
> > >
> > > > As you mention, if we'd
> > > > support this it would be opt-in per project, and complement rather
> > > > than replace any part of our usual policy - all actual discussion
> > > > around a vulnerability should still happen on a list (perhaps bridged
> > > > to the GitHub report somehow).
> > >
> > > GitHub have since updated their REST API to also expose security
> > > advisories that are still private[0]. Unfortunately this does not yet
> > > appear to support fetching or adding comments.
> > >
> > > > We'd also have to be careful to avoid
> > > > confusion such as people accidentally requesting CVE's through the
> > > > GitHub CNA instead of our own.
> > >
> > > This is still a concern: by default the UI shows a big green 'Request
> > > CVE' button to publish the advisory and request a CVE through the
> > > GitHub CNA. One workaround to avoid this could be to have a script
> > > that listens for new advisories and links them to a 'dummy'
> > > placeholder CVE. This would avoid accidentally using the GitHub CNA,
> > > and we could monitor for any published advisories still linked to the
> > > 'dummy' placeholder.
> > >
> >
> > Just as FYI; I suggested to GitHub's product owner for this that they add
> > the ability to redirect/notify an email address so that groups like the
> ASF
> > with a clear email-based security reporting process could connect the PVR
> > into their existing processes, rather than having to build a completely
> new
> > secondary process to support any reports they get on GitHub.
> >
> > Hen
> >
>


-- 
Arnout Engelen
ASF Security Response
Committer on Apache Pekko
Committer on NixOS
Independent Open Source consultant

Re: Reporting security vulnerabilities via Github Private security vulnerability ?

[Jarek Potiuk <ja...@potiuk.com>]

Yeah. It would be great if we could switch eventually to the Github
reporting mechanism.

Together with Arnout we have implemented in Airflow a rather elaborated and
complex process to manage reported security issues in a separate, private
github project, where all our discussions, comments etc. are automatically
sent to securty@airflow.apache.org for trackability and inclusivity. It
helps A LOT when it comes to managing the issues, organising discussions
about them, linking, labelling and all the kinds of things that make Github
a fantastic "issue management" solution.

But the pain we have is that this requires manually copying the security
reports and creating an issue for every such report manually and occasional
switching issue/mail. We have templates that are helping with doing it
effectively and we have a manual process to manage those - also Arnout
keeps track of our issues in the ASF security team records, but it's
generally quite a bit of pain to manage this `mail <-> issue` linkage. For
example, every time when we communicate with the reporter we need to
actually switch to the original email and communicate there. We keep the
link to the mailing discussion in the Github Issue of ours, so it is not
overwhelming and workable, but it adds quite an extra overhead.

It would be great if we could remove that step, and get rid of the separate
project we have. I think we have already proven how useful it is to have
organised this way and it helped us to organise and manage our security
issue handling, so getting the Github private reporting working and
integrated with our expectations would be a significant improvement.

J.


On Wed, Jul 5, 2023 at 9:11 AM Hen <ba...@apache.org> wrote:

> On Mon, Jun 5, 2023 at 3:06 AM Arnout Engelen <en...@apache.org> wrote:
>
> > On Wed, Feb 1, 2023 at 6:33 PM Arnout Engelen <en...@apache.org>
> wrote:
> > > On Sat, Jan 28, 2023 at 8:38 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> > > > Since currently we are using security@ in our policy, I was just
> > > > wondering if there are ways the GitHub reporting can be leveraged as
> > > > well (Additionally to mailing lists maybe rather than replacing it
> for
> > > > projects that already use GitHub)
> > > >
> > > > I am not sure if that is needed or necessary, or whether it could
> > > > fit-in the current process? Or maybe we do not want to use it at all
> > > > (there are certain properties of using a mailing list that make it
> > > > less noisy than Github reporting I think and I believe we have some
> > > > integrations that make it easier to manage than issues reported in
> > > > multiple repos).
> > > >
> > > > Just wanted to raise it here, maybe people do not realise that as of
> > > > recently this capability exists in GitHub.
> > >
> > > I think it could indeed be interesting.
> >
> > The feature to create a temporary private fork for an advisory could
> > also be attractive for some projects.
> >
> > > As you mention, if we'd
> > > support this it would be opt-in per project, and complement rather
> > > than replace any part of our usual policy - all actual discussion
> > > around a vulnerability should still happen on a list (perhaps bridged
> > > to the GitHub report somehow).
> >
> > GitHub have since updated their REST API to also expose security
> > advisories that are still private[0]. Unfortunately this does not yet
> > appear to support fetching or adding comments.
> >
> > > We'd also have to be careful to avoid
> > > confusion such as people accidentally requesting CVE's through the
> > > GitHub CNA instead of our own.
> >
> > This is still a concern: by default the UI shows a big green 'Request
> > CVE' button to publish the advisory and request a CVE through the
> > GitHub CNA. One workaround to avoid this could be to have a script
> > that listens for new advisories and links them to a 'dummy'
> > placeholder CVE. This would avoid accidentally using the GitHub CNA,
> > and we could monitor for any published advisories still linked to the
> > 'dummy' placeholder.
> >
>
> Just as FYI; I suggested to GitHub's product owner for this that they add
> the ability to redirect/notify an email address so that groups like the ASF
> with a clear email-based security reporting process could connect the PVR
> into their existing processes, rather than having to build a completely new
> secondary process to support any reports they get on GitHub.
>
> Hen
>

Re: Reporting security vulnerabilities via Github Private security vulnerability ?

[Hen <ba...@apache.org>]

On Mon, Jun 5, 2023 at 3:06 AM Arnout Engelen <en...@apache.org> wrote:

> On Wed, Feb 1, 2023 at 6:33 PM Arnout Engelen <en...@apache.org> wrote:
> > On Sat, Jan 28, 2023 at 8:38 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> > > Since currently we are using security@ in our policy, I was just
> > > wondering if there are ways the GitHub reporting can be leveraged as
> > > well (Additionally to mailing lists maybe rather than replacing it for
> > > projects that already use GitHub)
> > >
> > > I am not sure if that is needed or necessary, or whether it could
> > > fit-in the current process? Or maybe we do not want to use it at all
> > > (there are certain properties of using a mailing list that make it
> > > less noisy than Github reporting I think and I believe we have some
> > > integrations that make it easier to manage than issues reported in
> > > multiple repos).
> > >
> > > Just wanted to raise it here, maybe people do not realise that as of
> > > recently this capability exists in GitHub.
> >
> > I think it could indeed be interesting.
>
> The feature to create a temporary private fork for an advisory could
> also be attractive for some projects.
>
> > As you mention, if we'd
> > support this it would be opt-in per project, and complement rather
> > than replace any part of our usual policy - all actual discussion
> > around a vulnerability should still happen on a list (perhaps bridged
> > to the GitHub report somehow).
>
> GitHub have since updated their REST API to also expose security
> advisories that are still private[0]. Unfortunately this does not yet
> appear to support fetching or adding comments.
>
> > We'd also have to be careful to avoid
> > confusion such as people accidentally requesting CVE's through the
> > GitHub CNA instead of our own.
>
> This is still a concern: by default the UI shows a big green 'Request
> CVE' button to publish the advisory and request a CVE through the
> GitHub CNA. One workaround to avoid this could be to have a script
> that listens for new advisories and links them to a 'dummy'
> placeholder CVE. This would avoid accidentally using the GitHub CNA,
> and we could monitor for any published advisories still linked to the
> 'dummy' placeholder.
>

Just as FYI; I suggested to GitHub's product owner for this that they add
the ability to redirect/notify an email address so that groups like the ASF
with a clear email-based security reporting process could connect the PVR
into their existing processes, rather than having to build a completely new
secondary process to support any reports they get on GitHub.

Hen

Re: Reporting security vulnerabilities via Github Private security vulnerability ?

[Arnout Engelen <en...@apache.org>]

On Wed, Feb 1, 2023 at 6:33 PM Arnout Engelen <en...@apache.org> wrote:
> On Sat, Jan 28, 2023 at 8:38 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> > Since currently we are using security@ in our policy, I was just
> > wondering if there are ways the GitHub reporting can be leveraged as
> > well (Additionally to mailing lists maybe rather than replacing it for
> > projects that already use GitHub)
> >
> > I am not sure if that is needed or necessary, or whether it could
> > fit-in the current process? Or maybe we do not want to use it at all
> > (there are certain properties of using a mailing list that make it
> > less noisy than Github reporting I think and I believe we have some
> > integrations that make it easier to manage than issues reported in
> > multiple repos).
> >
> > Just wanted to raise it here, maybe people do not realise that as of
> > recently this capability exists in GitHub.
>
> I think it could indeed be interesting.

The feature to create a temporary private fork for an advisory could
also be attractive for some projects.

> As you mention, if we'd
> support this it would be opt-in per project, and complement rather
> than replace any part of our usual policy - all actual discussion
> around a vulnerability should still happen on a list (perhaps bridged
> to the GitHub report somehow).

GitHub have since updated their REST API to also expose security
advisories that are still private[0]. Unfortunately this does not yet
appear to support fetching or adding comments.

> We'd also have to be careful to avoid
> confusion such as people accidentally requesting CVE's through the
> GitHub CNA instead of our own.

This is still a concern: by default the UI shows a big green 'Request
CVE' button to publish the advisory and request a CVE through the
GitHub CNA. One workaround to avoid this could be to have a script
that listens for new advisories and links them to a 'dummy'
placeholder CVE. This would avoid accidentally using the GitHub CNA,
and we could monitor for any published advisories still linked to the
'dummy' placeholder.


Kind regards,

Arnout
[0]: https://docs.github.com/en/rest/security-advisories/repository-advisories
, haven't checked whether the graphql api at
https://docs.github.com/en/graphql/reference/objects#securityadvisory
also has them

---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org

Re: Reporting security vulnerabilities via Github Private security vulnerability ?

[Arnout Engelen <en...@apache.org>]

On Sat, Jan 28, 2023 at 8:38 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> Since currently we are using security@ in our policy, I was just
> wondering if there are ways the GitHub reporting can be leveraged as
> well (Additionally to mailing lists maybe rather than replacing it for
> projects that already use GitHub)
>
> I am not sure if that is needed or necessary, or whether it could
> fit-in the current process? Or maybe we do not want to use it at all
> (there are certain properties of using a mailing list that make it
> less noisy than Github reporting I think and I believe we have some
> integrations that make it easier to manage than issues reported in
> multiple repos).
>
> Just wanted to raise it here, maybe people do not realise that as of
> recently this capability exists in GitHub.

I think it could indeed be interesting. As you mention, if we'd
support this it would be opt-in per project, and complement rather
than replace any part of our usual policy - all actual discussion
around a vulnerability should still happen on a list (perhaps bridged
to the GitHub report somehow). We'd also have to be careful to avoid
confusion such as people accidentally requesting CVE's through the
GitHub CNA instead of our own.


Kind regards,

Arnout

---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org