modifications to assessment docs per 06122019 meeting notes

assessments/README.md

@@ -1,61 +1,40 @@
 # Security Assessments
 
 ## Goals
-The [security assessment process](guide) is designed to accelerate the adoption
-of cloud native technologies, based on the following goals and assumptions:
+
+The [security assessment process](guide) is designed to accelerate the adoption of cloud native technologies, based on the following goals and assumptions:
 
 ### 1) Reduce risk across the ecosystem
 
 The primary goal is to reduce the risk from malicious attacks and accidental breaches of privacy. This process supports that goal in two ways:
 
-   * Clear and consistent process for communication increases detection &
-   reduces time to resolve known or suspected vulnerability issues
-   * A collaborative evaluation process increases domain expertise
-   within each participating project.
+   * Clear and consistent process for communication increases detection & reduces time to resolve known or suspected vulnerability issues
+   * A collaborative evaluation process increases domain expertise within each participating project.
 
 ### 2) Accelerate adoption of cloud native technologies
 
-Security reviews are a necessary, yet time consuming process, where each
-company, organization and project must perform its own reviews to ensure
-that it meets its unique commitments to its own users and stakeholders.
-In open source, simply finding security-related information can be a very
-time consuming part of the the process. The process is designed to enable improved discovery of security information & streamlined security reviews in multiple ways:
+Security reviews are a necessary, time intensive process. Each company, organization and project must perform its own reviews to ensure that it meets its unique commitments to its own users and stakeholders.
+In open source, simply finding security-related information can be overwhelmingly difficult and a time consuming part of the security review. The CNCF security assessment, hereafter "security assessment," process is intended to enable improved discovery of security information & assist in streamlining internal and external security reviews in multiple ways:
 
    * Consistent documentation reduces review time
    * Established baseline of security-relevant information reduces Q&A
-   * Clear rubric for security profile enables organizations to align their
-   risk profile with project’s risk profile and effectively allocate resources
-   (for review and needed project contribution)
+   * Clear rubric for security profile enables organizations to align their risk profile with the project’s risk profile and effectively allocate resources (for review and needed project contribution)
    * Structured metadata allows for navigation, grouping and cross-linking
 
-We expect that this process will raise awareness of how specific open source
-projects affect the security of a cloud native system; however, separate
-activities may be needed to achieve that purpose using materials generated by
-the assessements.
+We expect that this process will raise awareness of how specific open source projects affect the security of a cloud native system; however, separate activities may be needed to achieve that purpose using materials generated by the assessements.
 
 ## Outcome
 
-Each project assessment will:
-1. ensure a clear description of the project's design goals with respect to
-security
-2. uncover design flaws and document known limitations
-3. document next steps toward increasing security of the project itself and/or
-increasing the applications of the project toward increasing security of the
-cloud native ecosystem
-
-Due to the nature and timeframe for the analysis, *this review is not meant
-to subsume the need for a professional security audit of the code*.  Audits
-of implementation vulnerabilities and similar issues at that level are not
-intended to be covered by this assessment.  The purpose of this effort is to
-uncover design flaws and to obtain a clear articulation of what the project's
-design goals and security properties are intended to be.
+Each project's security assessment shall include a description of:
+1. the project's design goals with respect to security
+2. any aspects of design and configuration that could introduce risk
+3. known limitations, such as expectations or assumptions that aspects of security, whole or in part, are to be handled by upstream or downstream dependencies or complementary software
+4. next steps toward increasing security of the project itself and/or increasing the applications of the project toward a more secure cloud native ecosystem
+
+Due to the nature and timeframe for the analysis, *this review is not meant to subsume the need for a professional security audit of the code*.  Audits of implementation-specific vulnerabilities, improper deployment configuration, etc. are not in scope of a security assessment.  A security assessmet is intended to uncover design and configuration flaws and to obtain a clear, comprehensive articulation of the project's design goals and aspirations while documenting the intended security properties enforced, fulfilled, or executed by said project.
 
 ## Process
 
-The project assessment is intended to be a collaborative process for
-the benefit of the project and the community, where the primary content is
-generated by the [project lead](guide/project-lead.md) and revised based on feedback
-from [security reviewers](guide/security-reviewer.md) and other members of the
-working group (WG).
+The security assessment is a collaborative process for the benefit of the project and the community, where the primary content is generated by the [project lead](guide/project-lead.md) and revised based on feedback from [security reviewers](guide/security-reviewer.md) and other members of the SIG.
 
 See [security assessment guide](guide) for more details.

assessments/guide/README.md

@@ -1,6 +1,6 @@
-To provide the CNCF’s TOC with effective
-information about the security of different projects,
-this document outlines the procedure by which a project should be evaluated.
+# Purpose
+
+To provide the CNCF’s TOC with effective information about the security of different projects, this document outlines the procedure by which a project should be evaluated.
 
 ## Roles
 
@@ -9,38 +9,26 @@ this document outlines the procedure by which a project should be evaluated.
 
 ## Steps
 
-1. Create tracking issue
+1. [Create tracking issue](https://github.com/cncf/sig-security/issues/new?assignees=&labels=assessment&template=security-assessment.md&title=%5BAssessment%5D+Project+Name)
    * Issue may be a request from TOC liason or project itself
 2. Project provides self-assessment
    * [project lead](project-lead.md) responds to the issue with draft document (see [outline](outline.md))
-   * issue assigned to lead [security reviewer](security-reviewer.md) who
-   will recruit a second reviewer, if one not already assigned, and facilitate
-   the process
+   * issue assigned to lead [security reviewer](security-reviewer.md) who will recruit a second reviewer, if one not already assigned, and facilitate the process
 3. Inital review
-   * Upon request by the project, security reviewer may do an inital review to
-   verify completeness, ask for clarifications and provide quick feedback
-   * Project posts their document to the group mailing list, allowing at least
-   one week for review before presenting to the WG
+   * Upon request by the project, security reviewer may do an inital review to verify completeness, ask for clarifications and provide quick feedback
+   * Project posts their document to the group mailing list, allowing at least one week for review before presenting to the SIG
 4. Presentation
-   * Project lead presents to WG
-   * This will be recorded as part of standard WG process
+   * Project lead presents to SIG
+   * This will be recorded as part of standard SIG process
 5. Final assessment
    * Reviewers provide final feedback with recommendations
    * Either project lead or reviewers may request further WG discussion
    * Project lead prepares a PR to /assessments/project-docs/project-name/
 
 ## Additional Process Notes
 
-Iteration is expected; however, we expect quick turnaround (at most a week).
-In rare cases unrelated issues can unexpectedly interrupt the process and
-it may be appropriate to address specific concerns rather than continuing with
-the assessment. We encourage open communication between project lead and s
-ecurity reviewers:
-
-* At any time, the project lead may request additional time to respond
-  to feedback from security reviewers
-* Project lead or lead security reviewer may pause the process where a delay
-  of over a week cannot be accomodated by the review team. Simply close
-  the github issue with a note to SIG co-chairs.
+Iteration is expected; however, we expect quick turnaround (at most a week). In rare cases unrelated issues can unexpectedly interrupt the process and it may be appropriate to address specific concerns rather than continuing with the assessment. We encourage open communication between project lead and security reviewers:
+* At any time, the project lead may request additional time to respond   to feedback from security reviewers
+* Project lead or lead security reviewer may pause the process where a delay of over a week cannot be accomodated by the review team. Simply close the github issue with a note to SIG co-chairs.