Merge pull request #14 from nadgowdas/changes

Few updates to embargo notification and VMT freshness

guide.md

@@ -135,7 +135,7 @@ When companies offer your project as a managed service or your project is critic
 
 Embargoed notification is *not* about avoiding PR issues or providing high-profile users with preferential treatment; it is about protecting users from damaging exploits by giving preparation time to the distributors and providers that control those users’ systems. It can also give distributors a chance to test and qualify the patch across diverse environments and report problems that can be fixed prior to public release. This extra testing validation can be valuable for complex patches. Make sure someone on the VMT is monitoring for replies to the embargo announcement.
 
-Using an embargoed notification is not without risk. An embargoed notification is expanding the number of people with early awareness and adds extra time between when the vulnerability is discovered and when it’s patched. As the [Project Zero team states](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html), *“We have observed several unintended outcomes from vulnerability sharing under embargo arrangements, such as: increased risk of leaks, slower patch release cycles, and inconsistent criteria for inclusion.”* When deciding to use an embargoed notification, consider the severity and exploitability of your vulnerability, the patching complexity (does the provider actually need the time to prepare, or this is an easily rolled out patch?), the resource cost in running and managing an embargoed notification cycle, and the breadth of your embargo list.
+Using an embargoed notification is not without risk. An embargoed notification is expanding the number of people with early awareness and adds extra time between when the vulnerability is discovered and when it’s patched. As the [Project Zero team states](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html), *“We have observed several unintended outcomes from vulnerability sharing under embargo arrangements, such as: increased risk of leaks, slower patch release cycles, and inconsistent criteria for inclusion.”* When deciding to use an embargoed notification, consider the severity and exploitability of your vulnerability, the patching complexity (does the provider actually need the time to prepare, or this is an easily rolled out patch?), the resource cost in running and managing an embargoed notification cycle, and the breadth of your embargo list. For every vulnerability (irrespective of its severity), not all users  are equally affected. For instance, if the  vulnerability exploit is on network vector and some users have strong network security controls in place, they might not be affected  by it. So the notifications can include some details on code path that is being exploited and  in which security settings it is affected.
 
 If an embargo list is relevant to your project, you will want to create a restricted, read-only announcement list that is administered by your VMT. The VMT is responsible for approving access requests and maintaining an accurate list (e.g. removing outdated members), but it is the provider’s responsibility to request access to your list. List the requirements and directions for requesting access in your security documentation.
 
@@ -220,14 +220,14 @@ See [`Runbook.md`]( https://github.com/google/oss-vulnerability-guide/blob/main/
 
 ## Publishing your vulnerability management process
 
-It can be beneficial to both reporters and users to publish what your project does when it receives a security issue, and if you have a time-based disclosure deadline (eg 90 days). This helps reporters follow the process along, and helps users have context for how an issue was handled when they see a disclosure.
+It can be beneficial to both reporters and users to publish what your project does when it receives a security issue, and if you have a time-based disclosure deadline (eg 90 days). This helps reporters follow the process along, and helps users have context for how an issue was handled when they see a disclosure. Also, one problem is the lack of visibility into if VMT is active. Some projects might publish their VMT process while the project was active. But, over time, as project age, it might not be active. So some heartbeat communication (monthly/quarterly) from VMT to confirm their active state could be helpful. Also, VMT for individual projects should report more details  on how actively they resolved the issues (mean time to resolve).
 
 
 ## Troubleshooting the process
 
 **Our reporter isn't very responsive**
 
-After the initial report, how responsive your responder is is up to them (that’s the “coordination” part of Coordinated Vulnerability Disclosure). If you receive a report that you are not able to reproduce and have tried multiple times to reach the reporter, send them a polite, final note that you were not able to reproduce the issue and will not be issuing a security advisory. Encourage them to reopen the issue if they are able to reproduce in the future.
+After the initial report, how responsive your responder is is up to them (that’s the “coordination” part of Coordinated Vulnerability Disclosure). If you receive a report that you are not able to reproduce and have tried multiple times to reach the reporter, send them a polite, final note that you were not able to reproduce the issue and will not be issuing a security advisory. Encourage them to reopen the issue if they are able to reproduce in the future. 
 
 
 **Patch development isn't going well**