Re: Documenting which commit(s) fix a vulnerability

[Mark J Cox <mj...@apache.org>]

As Jarek states, a number of our projects already use the "defects" field
in our CVE process tool to populate the link to the PR containing the fix
so that it becomes public at the time the CVE does.  But in the UI we don't
make it clear that this is recommended or how to use the field properly.
It simply currently states "Project specific bug ids e.g. TOMCAT-5222
(optional, this is not used for the Mitre entry).

So therefore we should make it automatically appear in the references of
the CVE.org entry, and we should update that text to make it clear that
this is recommended and how to use it.  I've added
https://github.com/apache/security-vulnogram/issues/69

Regards, Mark


On Sun, Jan 22, 2023 at 6:21 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Yes. I think committing a change is not the time to link information and
> adding detailed exploit scenarios does more harm than good.
> Release time is the right time IMHO to announce the reference to PR and
> announce it together.
>
> And I think we have all that we need - no more tooling is needed, maybe it
> would be good to make the PR URL as a requirement to be added by the
> security team - but it is more the question of release/CVE managers to
> remember to add it.
>
> Example automated email from our system with CVE from two days ago (
> https://github.com/apache/airflow/pull/28811 - is reference to PR that
> fixed it - with 'patch' type).
> You can add the PR URL  as soon as you create it or merge it in
> https://cveprocess.apache.org/ - so that you do not have to remember to
> add
> it at release time or search for PR. Also this "patch" URL is automatically
> recognised and reported (and easy to automatically retrieve) by all systems
> that keep information about CVEs - mitre and the like (see
> https://www.cve.org/CVERecord?id=CVE-2023-22884).
>
> ### The example CVE announcement follows
>
> https://lists.apache.org/thread/olwx8qj210qxwy95hshb6yb4dp34ovch
>
> CVE-2023-22884: Apache Airflow, Apache Airflow MySQL Provider: Arbitrary
> file read via MySQL provider in Apache Airflow
> Severity: important
>
> Description:
>
> Improper Neutralization of Special Elements used in a Command ('Command
> Injection') vulnerability in Apache Software Foundation Apache Airflow,
> Apache Software Foundation Apache Airflow MySQL Provider.This issue affects
> Apache Airflow: before 2.5.1; Apache Airflow MySQL Provider: before 4.0.0.
>
> Credit:
>
> Son Tran from VNPT - VCI (reporter)
>
> References:
>
> https://github.com/apache/airflow/pull/28811
> https://airflow.apache.org/
> https://www.cve.org/CVERecord?id=CVE-2023-22884
>
> J.
>
> On Sun, Jan 22, 2023 at 5:05 PM Dominik Psenner <dp...@gmail.com>
> wrote:
>
> > Agree. And in this case the tagged source git repository cannot contain
> the
> > security information in the release. It can only be added later with
> > another commit.
> >
> > Further, adding documentation that outlines attack vectors to black hats
> is
> > a no go for me.
> >
> > Consumers tend to not update their dependencies in a timely manner. This
> > may not even be the fault of a consumer, but a side effect of many
> causes.
> > The dependency supply chain, maintenance windows(or the lack of), ... It
> > often takes months if not years to update. Users who are aware of the
> risk,
> > will take measurements. Or they don't and have to accept the
> consequences.
> >
> > Some solutions already provide great visibility of known CVE
> > vulnerabilities from the versions available through application
> inventory.
> > I am not mentioning actual products, but there are many that I know of
> and
> > even more that I do not know of. The default for users should be easy and
> > straight forward:
> >
> > Update to the latest available version.
> >
> > And again, if users are doing their job, they may take additional
> > measurements if deemed necessary. As-secure as-possible zero trust
> > environments should be the standard.
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> >
> > On Sun, Jan 22, 2023, 15:37 Gary Gregory <ga...@gmail.com> wrote:
> >
> > > This is backward IMO. We want to obfuscate information when a security
> > > issue has been reported to us. It's only post release that we want to
> > > advertise that a CVE is fixed or addressed.
> > >
> > > Gary
> > >
> > > On Sun, Jan 22, 2023, 09:17 PJ Fanning <fa...@gmail.com> wrote:
> > >
> > > > I'm not against having some standard but this secom one does not
> > impress
> > > > me.
> > > >
> > > > * at the time of the commit, it is pretty unlikely the committer will
> > > > know the CWE id or CVSS score
> > > > * why describe the issue in detail? there should just be a link to
> URL
> > > > or some such
> > > > * the info about the users involved is in git - why duplicate it in
> > > > the commit message?
> > > >
> > > > For me, simply linking to the Github issue or some other page that
> > > > describes the issue is enough. Those pages can be living documents
> > > > that can be updated over time, as more info becomes available. A git
> > > > commit should ideally not be edited to keep updating its commit
> > > > message.
> > > >
> > > > Some issues might require multiple commits and many independent
> > > > developers to get the full fix in place. And those commits might be
> > > > interspersed with other commits not directly related to the security
> > > > issue that might touch the same area of code. So it may not be easy
> in
> > > > some cases to cherry pick the security fix - that fork maintainers
> > > > might need to rebase their fork to a newer branch of the upstream
> > > > project.
> > > >
> > > >
> > > > On Tue, 17 Jan 2023 at 15:29, Jonathan Leitschuh
> > > > <jo...@gmail.com> wrote:
> > > > >
> > > > > Just something I want to put on everyone's radar is a proposed
> format
> > > for
> > > > > security fix commit messages called SECOM:
> > > > > https://github.com/TQRG/secom
> > > > >
> > > > > Cheers,
> > > > > Jonathan Leitschuh
> > > > >
> > > > > On Mon, Jan 16, 2023 at 5:36 PM Gilles Sadowski <
> > gilleseran@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le lun. 16 janv. 2023 à 23:14, Jarek Potiuk <ja...@potiuk.com> a
> > > > écrit :
> > > > > > >
> > > > > > > The GH-provided identifier may be also unique, it could be
> nicer
> > > > > > > than the git-provided one, but it may also not exist (if there
> > was
> > > > > > > no PR associated with the change)!
> > > > > > >
> > > > > > > It exists. Always. For now we only allow the changes coming
> > through
> > > > > > GitHub
> > > > > > > PRs. If you would like to make a contribution that is not
> coming
> > > > through
> > > > > > GH
> > > > > > > PR, we will figure out how to create one by creating PR for the
> > > > person
> > > > > > from
> > > > > > > their branch that we will push to the repo.
> > > > > > > I am super happy to create one for you or anyone else who comes
> > > with
> > > > one
> > > > > > > via sending email or whatever other way works with GitBox.
> > > > > > >
> > > > > > > It has not happened for the last 4 years (that's my tenure in
> the
> > > > > > project)
> > > > > > > but if it will, I am super happy to help with it regardless. We
> > are
> > > > open
> > > > > > to
> > > > > > > any contributions.
> > > > > >
> > > > > > Great, thanks!  I'm not in a position to contribute to your
> > project;
> > > > > > I'm just increasingly worried that ASF projects seem to assume
> > > > > > that everyone is OK with using GH.
> > > > > >
> > > > > > Regards,
> > > > > > Gilles
> > > > > >
> > > > > > >> [...]
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > security-discuss-unsubscribe@community.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > security-discuss-help@community.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > security-discuss-unsubscribe@community.apache.org
> > > > For additional commands, e-mail:
> > > > security-discuss-help@community.apache.org
> > > >
> > > >
> > >
> >
>