Remove vulnerability:managed tag references
The TC has decided to no longer continue the "governance tags" experiment, so the VMT has moved the repos and expectations previously tracked by that tag into the security site. Overhaul the security review instructions to refer to the correct location and structure for this information, as well as a long-overdue cleanup of references to the no longer extant OSSP. Change-Id: I1a172016014b64d88199faaff6a6414aae50ccee
This commit is contained in:
parent
06aeaae4bb
commit
fee8939ca6
|
@ -3,12 +3,11 @@ Security review
|
||||||
===============
|
===============
|
||||||
|
|
||||||
The goal of security review in the OpenStack community is to identify
|
The goal of security review in the OpenStack community is to identify
|
||||||
weaknesses in design or implementation of OpenStack projects. While rare,
|
weaknesses in design or implementation of OpenStack projects. While rare, these
|
||||||
these weaknesses could potentially have catastrophic effects on the security of
|
weaknesses could potentially have catastrophic effects on the security of an
|
||||||
an OpenStack deployment, and therefore work should be undertaken to minimize
|
OpenStack deployment, and therefore work should be undertaken to minimize the
|
||||||
the likelihood of these defects in released projects. The OpenStack Security
|
likelihood of these defects in released projects. Over the course of a security
|
||||||
Project asserts that once a security review of a project has been completed,
|
review, the following should be known and documented:
|
||||||
the following are known and documented:
|
|
||||||
|
|
||||||
- All entry points into a system
|
- All entry points into a system
|
||||||
- What assets are at risk
|
- What assets are at risk
|
||||||
|
@ -19,43 +18,35 @@ the following are known and documented:
|
||||||
- An agreed set of findings and/or defects
|
- An agreed set of findings and/or defects
|
||||||
- How the project interacts with external dependencies
|
- How the project interacts with external dependencies
|
||||||
|
|
||||||
A common reason to perform a security review on an OpenStack project is to
|
A common reason to perform a security review on an OpenStack deliverable
|
||||||
enable that project to achieve the *vulnerability:managed* governance tag. The
|
repository is to assist with Vulnerability Management Team (VMT) oversight. The
|
||||||
OpenStack Vulnerability Management Team (VMT) applies the
|
OpenStack VMT lists `overseen repositories
|
||||||
`vulnerability:managed tag
|
<https://security.openstack.org/repos-overseen.html>`_ where the report
|
||||||
<https://governance.openstack.org/reference/tags/vulnerability_managed.html>`_
|
reception and disclosure of vulnerabilities is managed by the VMT. While not a
|
||||||
to projects where the report reception and disclosure of vulnerabilities is
|
strict requirement, some form of security review, audit or threat analysis
|
||||||
managed by the VMT. One of the requirements for gaining the tag is that
|
helps everyone more easily pinpoint areas where a system is more prone to
|
||||||
some form of security review, audit or threat analysis has been performed on
|
vulnerabilities and solve them before they become a problem for users.
|
||||||
the project.
|
|
||||||
|
|
||||||
The OpenStack Security Project (OSSP) has worked with the VMT to agree that an
|
The OpenStack VMT suggests that an architectural review of the recommended
|
||||||
architectural review of the best practice deployment for a project is an
|
deployment for a project is an appropriate form of security review, balancing
|
||||||
appropriate form of security review, balancing the need for review with the
|
the need for review with the resource requirements for a project of the scale
|
||||||
resource requirements for a project of the scale of OpenStack. Security
|
of OpenStack. Security architecture review is also often referred to as *threat
|
||||||
architecture review is also often referred to as *threat analysis*, *security
|
analysis*, *security analysis* or *threat modeling*. In the context of
|
||||||
analysis* or *threat modeling*. In the context of OpenStack security review,
|
OpenStack security review, these terms are synonymous for an architectural
|
||||||
these terms are synonymous for an architectural security review which may
|
security review which may identify defects in the design of a project or
|
||||||
identify defects in the design of a project or reference architecture, and may
|
reference architecture, and may lead to further investigative work to verify
|
||||||
lead to further investigative work to verify parts of the implementation.
|
parts of the implementation.
|
||||||
|
|
||||||
There are two routes that an OpenStack project may take to complete a security
|
Security review is expected to be the normal route for new projects and for
|
||||||
review:
|
cases where third parties have not performed security reviews or are unable to
|
||||||
|
share their results. Information for projects that require a security review
|
||||||
#. Review by OpenStack Security Project
|
will be available in the upcoming security review process.
|
||||||
#. Review by a third party review body, with validation from the OpenStack
|
|
||||||
Security Project
|
|
||||||
|
|
||||||
Security review by the OSSP is expected to be the normal route for new projects
|
|
||||||
and for cases where third parties have not performed security reviews or are
|
|
||||||
unable to share their results. Information for projects that require a security
|
|
||||||
review by the OSSP will be available in the upcoming security review process.
|
|
||||||
|
|
||||||
In cases where a security review has already been performed by a third party,
|
In cases where a security review has already been performed by a third party,
|
||||||
or where a project prefers to use a third party to perform their review,
|
or where a project prefers to use a third party to perform their review,
|
||||||
information on how to take the output of that third party review and submit it
|
information on how to take the output of that third party review and submit it
|
||||||
to the OSSP for validation will be available in the upcoming third party
|
for validation will be available in the upcoming third party security review
|
||||||
security review process.
|
process.
|
||||||
|
|
||||||
In either case, the requirements for documentation artefacts are similar - the
|
In either case, the requirements for documentation artefacts are similar - the
|
||||||
project must provide an architecture diagram for a best practise deployment.
|
project must provide an architecture diagram for a best practise deployment.
|
||||||
|
|
Loading…
Reference in New Issue