[openstack-dev] [neutron] How to handle security issues in external repos?

Jeremy Stanley fungi at yuggoth.org
Fri Jul 3 21:03:24 UTC 2015

On 2015-07-03 22:01:38 +0200 (+0200), Henry Gessau wrote:
> The question now arises about what to do when a security issue is
> found in such an external repository that integrates with Neutron.
>  - How should such security issues be managed?

The OpenStack Vulnerability Management Team (VMT) follows a
documented process[1] which can basically be reused by any
project-team when needed.

>  - Should the OpenStack security team be involved?

The OpenStack VMT directly oversees vulnerability reporting and
disclosure for a subset[2] of OpenStack source code repositories.
However we're still quite happy to answer any questions you might
have about vulnerability management for your own projects even if
they're not part of that set. Feel free to reach out to us in public
or in private.

Also, the VMT is an autonomous subgroup of the much larger OpenStack
Security project-team[3]. They're a knowledgeable bunch and quite
responsive if you want to get their opinions or help with
security-related issues (vulnerabilities or otherwise).

>  - Does a CVE need to be filed?

It can vary widely. If a commercial distribution such as Red Hat is
redistributing a vulnerable version of your software then they may
assign one anyway even if you don't request one yourself. Or the
reporter may request one; the reporter may even be affiliated with
an organization who has already assigned/obtained a CVE before they
initiate contact with you.

>  - Do the maintainers need to publish OSSN or equivalent documents?

OpenStack Security Advisories (OSSA) are official publications of
the OpenStack VMT and only cover VMT-supported software. OpenStack
Security Notes (OSSN) are published by editors within the OpenStack
Security project-team on more general security topics and may even
cover issues in non-OpenStack software commonly used in conjunction
with OpenStack, so it's at their discretion as to whether they would
be able to accommodate a particular issue with an OSSN.

However, these are all fairly arbitrary labels, and what really
matters in the grand scheme of things is that vulnerabilities are
handled seriously, fixed with due urgency and care, and announced
widely--not just on relevant OpenStack mailing lists but also
preferably somewhere with broader distribution like the Open Source
Security mailing list[4]. The goal is to get information on your
vulnerabilities, mitigating measures and fixes into the hands of the
people using your software in a timely manner.

>  - Anything else to consider here?

The OpenStack VMT is in the process of trying to reinvent itself so
that it can better scale within the context of the "Big Tent." This
includes making sure our policy/process documentation is more
consumable and reusable even by project-teams working on software
outside the scope of our charter. It's a work in progress, and any
input is welcome on how we can make this function well for everyone.

[1] https://security.openstack.org/vmt-process.html
[2] https://wiki.openstack.org/wiki/Security_supported_projects
[3] http://governance.openstack.org/reference/projects/security.html
[4] http://oss-security.openwall.org/wiki/mailing-lists/oss-security
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150703/0bef864e/attachment.pgp>

More information about the OpenStack-dev mailing list