process: document the VMT vulnerability management process - #1291
process: document the VMT vulnerability management process#1291vdemeester wants to merge 1 commit into
Conversation
The reporter-facing security policy lives in tektoncd/.github, but the team-side process the VMT actually follows is undocumented. New contributors have no way to learn how triage, embargoed fix development, or publication work, and there is no written expectation of what VMT membership involves. Add process/security-vmt.md covering scope, intake, triage states and timelines, private fix development, publication, the weekly digest, membership, and escalation. It links to the security policy rather than duplicating it. Several points are marked TODO where the team has not yet decided: downstream pre-notification, the on-call rotation model, and the inactivity threshold for offboarding. Triage and fix-time objectives are proposals and need VMT agreement.
tekton-robot
added
kind/documentation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
tekton-robot
added
the
size/L
theakshaypant
left a comment
theakshaypant
left a comment
There was a problem hiding this comment.
Thanks for adding this documentation @vdemeester!
The comments are mostly clarifications for myself rather than asking for changes in the doc.
| distributors. | ||
|
|
||
| > TODO: decide whether to offer downstream distributors advance notice, and if | ||
| > so, how membership of that list is granted. Raise at a community meeting. |
There was a problem hiding this comment.
This is interesting, we cannot have just a mailing list for downstream distributors, can we? If we do, how do we ensure the people signing up are legit and not just signing up to discover these vulns.
There was a problem hiding this comment.
Exactly, I am not sure yet on this, probably need to do some research on how other projects handle this.
|
|
||
| When the fix is released: | ||
|
|
||
| 1. **Publish the GHSA** on the affected repository, with the CVSS vector, |
There was a problem hiding this comment.
The publish should happen only after atleast all 4 LTS versions have the fix, right?
There was a problem hiding this comment.
yes. Ideally the backport PR are also in the private fork so when merging, all is merged at the same time and we can publish quickly.. Sadly, GitHub often tends to give Unicorn page when trying to do that..
There was a problem hiding this comment.
If I'm not mistaken, the private fork is only alive for a single PR.
Will try creating multiple PRs on such a private fork and report back here.
There was a problem hiding this comment.
@theakshaypant no no you can create as much PR as you want on the private fork created on the GHSA, they just all (the open one) get merged at the same time when you merge them.
| being transparent about the disagreement is better than an argument nobody can | ||
| see. | ||
|
|
||
| If a vulnerability is being actively exploited, skip the process. Fix it, ship |
There was a problem hiding this comment.
How would one know if the vuln is being actively exploited?
Not asking to include the explanation in the doc, this is for me.
There was a problem hiding this comment.
Well we don't know until we do 😹 maybe the reporter is stating it is actively used, or we have proofed / discovered it is exploited ?
| effectively a public exploit should be added *after* publication, or written | ||
| so that it does not read as an exploit. | ||
| - Fixes must be backported to every affected supported LTS branch. A fix that | ||
| lands only on `main` is not complete. |
There was a problem hiding this comment.
In the past I have seen not being able to merge the fix to main directly and requesting someone that can bypass branch protections (you :p) to merge the fix.
Is that something that should be documented to avoid confusion for new vmt members?
There was a problem hiding this comment.
Good point, we should probably document and we should also explore if there is a way around this somehow ?
3 participants
Changes
Adds
process/security-vmt.md, a team-facing document for the Tekton Vulnerability Management Team (VMT), plus a TOC entry inprocess/README.md.Today there is no written VMT process anywhere. The reporter-facing policy lives in
tektoncd/.github/SECURITY.mdand is intentionally not duplicated here — this doc links to it and covers what happens on the team side.Sections: scope, intake, triage (states / CVSS / SLO table), fix development (private forks, embargo), publication, weekly digest & staleness, membership (job, assignment, joining, permissions, leaving), escalation.
Why draft
This is opened as a draft to gather VMT and community feedback, not to merge as-is. Several points are proposals rather than descriptions of current practice:
SECURITY.md.TODOblocks remain in the doc, each needing a team decision:Feedback on the numbers and on the three TODOs is exactly what I'm looking for. Happy to split this up or move sections elsewhere if reviewers prefer.
/kind documentation