From cfd1ccf1865810327c24faa34610093f1ae3991f Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Thu, 17 Feb 2022 15:37:20 -0800 Subject: [PATCH 1/4] Add baseline security process Signed-off-by: Steve Lasker --- SECURITY.md | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..e9eb890 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,60 @@ +# Security Process and Policy + +This document provides the details on the Veriason security policy and details the processes +surrounding security handling including a how to guide on reporting a security vulnerability +for anything within the Veraison organization. + +## Report A Vulnerability + +We’re extremely grateful for security researchers and users who report vulnerabilities +to the Veraison community. All reports are thoroughly investigated by a set of Veraison maintainers. + +To make a report please email the private security list at ___@___ with the details. + +### When To Send A Report + +You think you have found a vulnerability in a Veraison project or a dependency of a Veraison project. This can be any of the repositories on the [Veraison GitHub organization](https://github.com/veraison). + +### Security Vulnerability Response + +Each report will be reviewed and receipt acknowledged within 3 business days. This will set off the security review process detailed below. + +Any vulnerability information shared with the security team stays within the Veraison project and will not be shared with others unless it is necessary to fix the issue. Information is shared only on a need to know basis. + +We ask that vulnerability reporter(s) act in good faith by not disclosing the issue to others. And we strive to act in good faith by acting swiftly, and by justly crediting the vulnerability reporter(s) in writing. + +As the security issue moves through triage, identification, and release the reporter of the security vulnerability will be notified. Additional questions about the vulnerability may also be asked of the reporter. + +### Public Disclosure + +A public disclosure of security vulnerabilities is released alongside release updates or details that fix the vulnerability. We try to fully disclose vulnerabilities once a mitigation strategy is available. Our goal is to perform a release and public disclosure quickly and in a timetable that works well for users. For example, a release may be ready on a Friday but for the sake of users may be delayed to a Monday. + +CVEs will be assigned to vulnerabilities. Due to the process and time it takes to obtain a CVE ID, disclosures will happen first. Once the disclosure is public the process will begin to obtain a CVE ID. Once the ID has been assigned the disclosure will be updated. + +If the vulnerability reporter would like their name and details shared as part of the disclosure process we are happy to. We will ask permission and for the way the reporter would like to be identified. We appreciate vulnerability reports and would like to credit reporters if they would like the credit. + +## Security Team Membership + +The security team is made up of a subset of the Veraison project maintainers who are willing and able to respond to vulnerability reports. + +### Responsibilities + +* Members MUST be active project maintainers on active (non-deprecated) Veraison projects as defined in [the governance](governance/governance.md) +* Members SHOULD engage in each reported vulnerability, at a minimum to make sure it is being handled +* Members MUST keep the vulnerability details private and only share on a need to know basis + +### Membership + +New members are required to be active maintainers of Veraison projects who are willing to perform the responsibilities outlined above. The security team is a subset of the maintainers. Members can step down at any time and may join at any time. + +From time to time, Veraison projects are deprecated. If at any time a security team member is found to be no longer be an active maintainer on active Veraison projects, this individual will be removed from the security team. + +## Patch and Release Team + +When a vulnerability comes in and is acknowledged, a team - including maintainers of the Veraison project affected - will assembled to patch the vulnerability, release an update, and publish the vulnerability disclosure. This may expand beyond the security team as needed but will stay within the pool of Veraison project maintainers. + +## Disclosures + +Vulnerability disclosures are published as **TBD**. The disclosures will contain an overview, details about the vulnerability, a fix for the vulnerability that will typically be an update, and optionally a workaround if one is available. + +Disclosures will be published on the same day as a release fixing the vulnerability after the release is published. From 7dbe2d33f89ae6b2f3784b982b655fffdf03931a Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Tue, 15 Mar 2022 16:30:28 -0700 Subject: [PATCH 2/4] PR feedback Signed-off-by: Steve Lasker --- SECURITY.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index e9eb890..d656479 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,6 +1,6 @@ # Security Process and Policy -This document provides the details on the Veriason security policy and details the processes +This document provides the details on the Veraison security policy and details the processes surrounding security handling including a how to guide on reporting a security vulnerability for anything within the Veraison organization. @@ -17,19 +17,19 @@ You think you have found a vulnerability in a Veraison project or a dependency o ### Security Vulnerability Response -Each report will be reviewed and receipt acknowledged within 3 business days. This will set off the security review process detailed below. +Each report will be reviewed and receipt acknowledged in a timely manner. This will set off the security review process detailed below. Any vulnerability information shared with the security team stays within the Veraison project and will not be shared with others unless it is necessary to fix the issue. Information is shared only on a need to know basis. -We ask that vulnerability reporter(s) act in good faith by not disclosing the issue to others. And we strive to act in good faith by acting swiftly, and by justly crediting the vulnerability reporter(s) in writing. +We ask that vulnerability reporter(s) act in good faith by not disclosing the issue to others. And we strive to act in good faith by acting swiftly, and by justly crediting the vulnerability reporter(s) in writing (see [Public Disclosure](#public-disclosure)). -As the security issue moves through triage, identification, and release the reporter of the security vulnerability will be notified. Additional questions about the vulnerability may also be asked of the reporter. +As the security issue moves through triage, identification, and release the reporter of the security vulnerability will be notified. Additional questions about the vulnerability map may also be asked from the reporter. ### Public Disclosure A public disclosure of security vulnerabilities is released alongside release updates or details that fix the vulnerability. We try to fully disclose vulnerabilities once a mitigation strategy is available. Our goal is to perform a release and public disclosure quickly and in a timetable that works well for users. For example, a release may be ready on a Friday but for the sake of users may be delayed to a Monday. -CVEs will be assigned to vulnerabilities. Due to the process and time it takes to obtain a CVE ID, disclosures will happen first. Once the disclosure is public the process will begin to obtain a CVE ID. Once the ID has been assigned the disclosure will be updated. +When needed, CVEs will be assigned to vulnerabilities. Due to the process and time it takes to obtain a CVE ID, disclosures will happen first. Once the disclosure is public the process will begin to obtain a CVE ID. Once the ID has been assigned the disclosure will be updated. If the vulnerability reporter would like their name and details shared as part of the disclosure process we are happy to. We will ask permission and for the way the reporter would like to be identified. We appreciate vulnerability reports and would like to credit reporters if they would like the credit. @@ -45,13 +45,13 @@ The security team is made up of a subset of the Veraison project maintainers who ### Membership -New members are required to be active maintainers of Veraison projects who are willing to perform the responsibilities outlined above. The security team is a subset of the maintainers. Members can step down at any time and may join at any time. +New members are required to be active maintainers of Veraison projects who are willing to perform the responsibilities outlined above. The security team is a subset of the maintainers across Veraison sub-projects. Members can step down at any time and may join at any time. -From time to time, Veraison projects are deprecated. If at any time a security team member is found to be no longer be an active maintainer on active Veraison projects, this individual will be removed from the security team. +If at any time a security team member is found to be no longer be an active maintainer on active Veraison sub-projects, this individual will be removed from the security team. ## Patch and Release Team -When a vulnerability comes in and is acknowledged, a team - including maintainers of the Veraison project affected - will assembled to patch the vulnerability, release an update, and publish the vulnerability disclosure. This may expand beyond the security team as needed but will stay within the pool of Veraison project maintainers. +When a vulnerability comes in and is acknowledged, a team - including maintainers of the Veraison project affected - will be assembled to patch the vulnerability, release an update, and publish the vulnerability disclosure. This may expand beyond the security team as needed but will stay within the pool of Veraison project maintainers. ## Disclosures From abb63c8bee584712d193ff794d8b6f6d44ff1921 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Jul 2022 12:49:33 -0700 Subject: [PATCH 3/4] Finalize security.md with the email list and details Signed-off-by: Steve Lasker --- SECURITY.md | 46 ++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 38 insertions(+), 8 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index d656479..0ea00fe 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,19 +1,43 @@ # Security Process and Policy -This document provides the details on the Veraison security policy and details the processes -surrounding security handling including a how to guide on reporting a security vulnerability -for anything within the Veraison organization. +This document provides the details on the veraison/go-cose security policy and details the processes surrounding security handling. + +## Supported Versions + +[go-cose][go-cose] is currently is in active development, moving to a [1.0.0 release][v1.0.0-milestone]. The latest pre-release will be supported until 1.0.0 is released. As 1.0.0 is released, pre-release references will need to be redirected 1.0.0. + +| Version | Supported | +| ------- | ------------------ | +| [v1.0.0-alpha1][v1.0.0-alpha1-release] | :green_check_mark: | ## Report A Vulnerability We’re extremely grateful for security researchers and users who report vulnerabilities -to the Veraison community. All reports are thoroughly investigated by a set of Veraison maintainers. +to the [veraison/go-cose][go-cose] community. All reports are thoroughly investigated by a set of [veraison/go-cose maintainers][go-cose-maintainers]. + +To make a report please email the private security list at go-cose-security@googlegroups.com with details using the following template: + +### Reporting Template -To make a report please email the private security list at ___@___ with the details. +```console +[TO:]: go-cose-security@googlegroups.com +[SUBJECT]: go-cose Security Notification +[BODY]: +Release: v1.0.0-alpha.1 -### When To Send A Report +Summary: +A quick summary of the issue -You think you have found a vulnerability in a Veraison project or a dependency of a Veraison project. This can be any of the repositories on the [Veraison GitHub organization](https://github.com/veraison). +Impact: +Details on how to reproduce the security issue. + +Contact: +Information on who to contact for additional information +``` + +### When To Send a Report + +You think you have found a vulnerability in th [veraison/go-cose][go-cose] project or a dependency of a Veraison project. This can be any of the repositories on the [Veraison GitHub organization](https://github.com/veraison). ### Security Vulnerability Response @@ -55,6 +79,12 @@ When a vulnerability comes in and is acknowledged, a team - including maintainer ## Disclosures -Vulnerability disclosures are published as **TBD**. The disclosures will contain an overview, details about the vulnerability, a fix for the vulnerability that will typically be an update, and optionally a workaround if one is available. +Vulnerability disclosures are published to [security-advisories][security-advisories]. The disclosures will contain an overview, details about the vulnerability, a fix for the vulnerability that will typically be an update, and optionally a workaround if one is available. Disclosures will be published on the same day as a release fixing the vulnerability after the release is published. + +[go-cose]: https://github.com/veraison/go-cose +[security-advisories]: https://github.com/veraison/go-cose/security/advisories +[v1.0.0-alpha1-release]: https://github.com/veraison/go-cose/releases/tag/v1.0.0-alpha.1 +[v1.0.0-milestone]: https://github.com/veraison/go-cose/milestone/2 +[go-cose-maintainers]: https://github.com/veraison/community/blob/main/OWNERS \ No newline at end of file From 2cdc8343bb2e6fa71c74d24ca2b5422360a9c13f Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Fri, 1 Jul 2022 15:44:54 -0700 Subject: [PATCH 4/4] PR Feedback Signed-off-by: Steve Lasker --- SECURITY.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 0ea00fe..1840d0f 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -4,7 +4,7 @@ This document provides the details on the veraison/go-cose security policy and d ## Supported Versions -[go-cose][go-cose] is currently is in active development, moving to a [1.0.0 release][v1.0.0-milestone]. The latest pre-release will be supported until 1.0.0 is released. As 1.0.0 is released, pre-release references will need to be redirected 1.0.0. +[go-cose][go-cose] is currently is in active development, moving to a [1.0.0 release][v1.0.0-milestone]. The latest pre-release will be supported until 1.0.0 is released. As 1.0.0 is released, pre-release references will need to be redirected to 1.0.0. | Version | Supported | | ------- | ------------------ | @@ -15,7 +15,7 @@ This document provides the details on the veraison/go-cose security policy and d We’re extremely grateful for security researchers and users who report vulnerabilities to the [veraison/go-cose][go-cose] community. All reports are thoroughly investigated by a set of [veraison/go-cose maintainers][go-cose-maintainers]. -To make a report please email the private security list at go-cose-security@googlegroups.com with details using the following template: +To make a report please email the private security list at go-cose-security@googlegroups.com with details using the following template: ### Reporting Template @@ -37,13 +37,13 @@ Information on who to contact for additional information ### When To Send a Report -You think you have found a vulnerability in th [veraison/go-cose][go-cose] project or a dependency of a Veraison project. This can be any of the repositories on the [Veraison GitHub organization](https://github.com/veraison). +You think you have found a vulnerability in the [veraison/go-cose][go-cose] project. ### Security Vulnerability Response Each report will be reviewed and receipt acknowledged in a timely manner. This will set off the security review process detailed below. -Any vulnerability information shared with the security team stays within the Veraison project and will not be shared with others unless it is necessary to fix the issue. Information is shared only on a need to know basis. +Any vulnerability information shared with the security team stays within the [veraison/go-cose][go-cose] project and will not be shared with others unless it is necessary to fix the issue. Information is shared only on a need to know basis. We ask that vulnerability reporter(s) act in good faith by not disclosing the issue to others. And we strive to act in good faith by acting swiftly, and by justly crediting the vulnerability reporter(s) in writing (see [Public Disclosure](#public-disclosure)). @@ -63,7 +63,7 @@ The security team is made up of a subset of the Veraison project maintainers who ### Responsibilities -* Members MUST be active project maintainers on active (non-deprecated) Veraison projects as defined in [the governance](governance/governance.md) +* Members MUST be active project maintainers on active (non-deprecated) Veraison projects as defined in the [governance](https://github.com/veraison/community/blob/main/GOVERNANCE.md) * Members SHOULD engage in each reported vulnerability, at a minimum to make sure it is being handled * Members MUST keep the vulnerability details private and only share on a need to know basis @@ -71,7 +71,7 @@ The security team is made up of a subset of the Veraison project maintainers who New members are required to be active maintainers of Veraison projects who are willing to perform the responsibilities outlined above. The security team is a subset of the maintainers across Veraison sub-projects. Members can step down at any time and may join at any time. -If at any time a security team member is found to be no longer be an active maintainer on active Veraison sub-projects, this individual will be removed from the security team. +If at any time a security team member is found to be no longer an active maintainer on active Veraison sub-projects, this individual will be removed from the security team. ## Patch and Release Team