-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VOTE - Adopt Advise as a Sandbox project for the OpenSSF #152
Comments
I am for this, but it should be warned when not to use Advise. For instance, the current VINCE programs requires a minimum embargo period of 45 days once VINCE becomes involved. If this is too long a period for a given case, VINCE should not be contacted. |
I am also in favor, and biased. @eslerm, the embargo period is a policy choice of the operator and isn't enforced by the code, although it is hard coded to set the default due date. This should probably be a config option. If this moves forward the OpenSSF should chose a default embargo period, or perhaps not to have a default, although in practice I've found having a starting point makes the negotiation quicker. |
Thank you for explaining how that is set @zmanion. Can an operator shorten the policy during a coordination? I would be for a default maximum embargo of 90 days :) I don't opt for a coordinated release date (CRD) or minimum embargo without a good reason (e.g., a request from the reporter or needing to coordinate publication with others/announcements). Many vulnerabilities do not need elaborate coordination. In those cases, setting a date automatically can slow down their patches. |
Just to add my two cents to this thread. Advise != VINCE. VINCE is an open source tool being actively developed by an FFRDC as a CVD prototype. Advise is being developed independently of VINCE. |
Yes, the embargo length is decided by the operator. A default can be set if desired. This happens to be true for both CERT/CC VINCE and Advise, but this issue is only about Advise. |
I vote to agree to accept this project |
I vote to ACK this project. |
I vote in favor of this. |
I vote in favour of adopting this project within the OpenSSF |
I vote in favor. |
Hearing no counter opinions or dissenting opinions, we will move forward with the IP transfer process with LF Legal. Thanks to those that shared their thoughts on this. |
@zmanion has presented to the working group several times now about VINCE (now called "Advise"). Advise(1) is an open source tool that provides a platform to manage coordinated vulnerability disclosures.
It is proposed that the OpenSSF accept the donation of Advise as a Sandbox project within the Vulnerability Disclosures Working Group, work with the existing project members to make Advise an option for open source projects to manage and coordinate their intake of security vulnerabilities, and assist the project team in enhancements and evangelism of the project within the upstream open source community. This directly falls in line with previous plans the group discussed(2) around the creation of an opens source SIRT, as a key capability security teams should have.
This proposal does NOT have anything to do with existing implementations of VINCe/Advise and the services currently being provided. It is purely about the donate of the code to the Foundation for curation, enhancement, and evangelism alongside out other CVD & Vuln metadata efforts.
If the WG agrees with this path forward, we would work with the project to complete the necessary paperwork(3) for the foundation to adopt Advise as a Sandbox project within this working group.
(1) - https://github.com/vu-ls/advise
(2) - https://github.com/ossf/SIRT/blob/main/plan/2.0%20Identify%20Core%20Services%20and%20Processes.md
(3) - https://github.com/ossf/tac/blob/main/process/project-lifecycle.md
The text was updated successfully, but these errors were encountered: