jprdonnelly/opentf
1
0
Fork 0
mirror of https://github.com/opentffoundation/opentf.git synced 2025-12-19 17:59:05 -05:00
Code Issues Packages Projects Releases Wiki Activity

rfc: Revisions to Security Patch Policy

Browse Source 
After adopting our original form of this policy we found out that GitHub's
security advisory feature will not allow us to publish "local-only"
advisories with no severity information, and instead sends copies of any
published advisory to other vulnerability databases. That is therefore not
a suitable way to handle false-positive reports, because distributing them
to other vulnerability databases would likely cause _even more_
false-positive reports from security scanners.

This therefore now describes the compromise we made in practice: we publish
our reasoning for classifying an advisory as false-positive in comments on
the relevant GitHub issue and then close that issue. This also mentions
our efforts to make these issues more discoverable by ensuring that the
advisory ID and affected module path are included in the summary of the
GitHub issue.

This is intended as a description of what we have already been doing in
practice, rather than as a proposal for a new policy.

Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This commit is contained in:
Martin Atkins
2025-09-23 14:30:17 -07:00
parent 2de469a26d
commit b4504c8355
1 changed files with 6 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
rfc/20250314-security-patch-policy.md
View File

@@ -58,6 +58,10 @@ We respond to any valid upstream advisory that was either detected by `govulnche
Our advisory for each report includes a summary of whether and how the report relates to each of the minor release series that are not yet end-of-life. If our response included the issuing of new patch releases in any of those series, we will clearly indicate the minimum patch release in each series that includes the fix.
Our advisory for each report will include a summary of whether and how the report relates to each of the minor release series that are not yet end-of-life. If our response included the issuing of new patch releases in any of those series, we will clearly indicate the minimum patch release in each series that includes the fix.
For reports that we classify as false-positives, we instead publish our reasoning for that decision in comments on the relevant GitHub issue and close the issue without making any changes to the code. We ensure that the summary of these issues includes the Go vulerability database ID (or equivalent from another vulnerability database) and the module path of the main Go module that the advisory relates to so that folks who encounter the same false-positives in the tools they use can find our previous discussion about them.
We will publish _low-severity_ advisories even for reports that we conclude to be false-positives, explaining our reasoning for that decision and indicating that no versions of OpenTofu are affected and no upgrades are required. Such advisories serve to acknowledge that we became aware of the potential for a problem and have actively investigated it, so that those whose own security scanners generate false positives about it can be confident that we are already aware of the (non-)problem and therefore they do not need to re-report it.
> [!NOTE]
>
> The original accepted version of this policy stated that we would publish security advisories with no severity when we conclude that a report is a false-positive, because we hoped to list both the valid and false-positive outcomes together in the same place.
>
> Unfortunately at the time of writing GitHub's security advisory features do not allow publishing a "no severity" advisory without that then being copied into other vulnerability databases and thus potentially causing _even more_ false-positive reporting noise for low-accuracy security scanners, and so we've adopted the compromise of describing false-positives only in the GitHub issue that they were reported in.