Merge "Update vulnerability:managed policy"

reference/tags/vulnerability_managed.rst

@@ -83,27 +83,19 @@ Requirements
    reduce the number of people who have knowledge of them prior to
    public disclosure.
 
-5. The deliverable's repos should undergo a review, audit, or threat
-   analysis looking for obvious signs of insecure design or risky
-   implementation which could imply a large number of future
-   vulnerability reports. The review, audit, or threat analysis may
-   be done by the project team itself or an impartial third party.
-   In the event the project team involved in the tagging performs
-   the review, audit, or threat analysis, the results must be
-   validated by a third party.  The VMT doesn't stipulate which
-   third party would perform this review or validation; for example
-   members of the OpenStack Security Group (OSSG) might volunteer
-   to provide their expertise or some other third party including
-   sponsoring companies of a project may offer assistance. As much
-   as anything this is a measure to keep the VMT's workload down,
-   since it is by necessity a group of constrained size and some
-   of its processes simply can't be scaled safely.  Finally, the
-   results of the review, audit, or threat analysis must
-   be proposed as a gerrit review in the :repo:`openstack/security-analysis`
-   repository and accepted by the OpenStack Security Group (OSSG).  Acceptance
-   by the OpenStack Security Group (OSSG) of the documentation does
-   not constitute a third party approval unless the OpenStack Security
-   Group (OSSG) agrees in advance to acting as a third party approver.
+5. Projects are encouraged to undertake a review, audit, or threat
+   analysis of the deliverable in order to proactively identify
+   likely security weaknesses. In the event the project team
+   performs it, the results should ideally also be validated by a
+   third party (which could just be other members of the community
+   not involved directly in that project). If possible, the results
+   should be proposed to the :repo:`openstack/security-analysis`
+   repository in Gerrit and reviewed or refined there. Refreshing
+   the analysis immediately following each major release is
+   suggested, but an outdated analysis is still more useful than
+   none at all. This is a recommendation in order to keep the VMT's
+   workload to a necessary minimum, but is not a requirement for
+   adding the tag.
 
 6. All repos for the deliverable covered should have automated
    testing for important features. Tests need to be feasible for the
@@ -115,6 +107,27 @@ Requirements
    disclosure, and also decreases the chance of creating additional
    work for the VMT issuing errata later.
 
+7. The VMT will not track or issue advisories for external software
+   components. Only source code provided by official OpenStack
+   project teams is eligible for support from the VMT. For example,
+   base operating system components included in a server/container
+   image or libraries vendored into compiled binary artifacts are
+   not within the VMT's scope.
+
+8. Deliverables must tag releases to qualify for VMT oversight.
+   Vulnerabilities warrant advisories if they appear in official
+   releases or on supported stable branches. Vulnerabilities only
+   present in master since the last release, or only on branches
+   under extended maintenance, will not have their disclosure
+   coordinated by the VMT. Pre-releases, release candidates and
+   milestones are not considered official releases for the purpose
+   of this policy.
+
+9. Embargoes for privately-reported vulnerabilities shall not last
+   more than 90 days, except under unusual circumstances. Following
+   the embargo expiration, reports will be publicly visible
+   regardless of whether an advisory has been issued.
+
 Tag application process
 =======================
 
@@ -130,4 +143,4 @@ able to adequately handle these vulnerabilities. Care should be
 taken to only discontinue vulnerability management for future
 non-patch releases, while continuing to handle vulnerabilities on
 already existing ``stable`` release branches if at all possible
-until such time as they reach end-of-life.
+until such time as they reach extended maintenance or end-of-life.