Correcting grammar from PR #1411

.github/ISSUE_TEMPLATE/joint-review.md

@@ -1,7 +1,7 @@
 ---
-name: Joint security review
+name: Joint security assessment
 about: To request a joint review or track progress on active review
-title: "[Security Review] Project Name"
+title: "[Security Assessment] Project Name"
 labels: "triage-required"
 assignees: ''
 

CODE-OF-CONDUCT.md

@@ -32,7 +32,7 @@ In keeping with this commitment, we offer the following guidelines:
      Charter][charter],
      the open source license, and to be used for the equal benefit of all
      members of the community.  Further information on use of work may be found
-     in [Security Reviews:
+     in [Security Assessments:
      Outcome][review-outcome]
 
 ## Incident handling and escalation

CONTRIBUTING.md

@@ -108,7 +108,7 @@ contributions to our documentation.
 
 ### Reporting Security Issues
 
-This group engages in [security reviews] of projects to improve their security
+This group engages in [security assessments] of projects to improve their security
 posture. Discussions about potential issues must adhere to the project's
 security reporting process and remain close-held to ensure responsible
 disclosure.
@@ -197,7 +197,7 @@ Here are some additional sources for good content guidelines:
 [CODE-OF-CONDUCT.md]: CODE-OF-CONDUCT.md
 [help is needed]: https://github.com/cncf/tag-security/labels/help%20wanted
 [communication channels]: README.md#Communications
-[security reviews]: /community/assessments/README.md
+[security assessments]: /community/assessments/README.md
 [CNCF Slack guidelines]: https://github.com/cncf/foundation/blob/main/slack-guidelines.md
 [code of conduct]: ./CODE-OF-CONDUCT.md
 [CNCF Style Guide]: https://github.com/cncf/foundation/blob/main/style-guide.md

README.md

@@ -91,7 +91,7 @@ Each group, led by a responsible leader, reaches consensus on issues and manages
 | [Commons](/community/working-groups/commons/README.md) | Eddie Knight | Marco De Benedictis |
 | [Compliance](/community/working-groups/compliance/README.md) | Anca Sailer, Robert Ficcaglia | Brandt Keller |
 | [Controls](/community/working-groups/controls/README.md) | Jon Zeolla | Brandt Keller |
-| [Security Reviews](/community/assessments/README.md) | Justin Cappos | Eddie Knight |
+| [Security Assessments](/community/assessments/README.md) | Justin Cappos | Eddie Knight |
 | [Software Supply Chain](/community/working-groups/supply-chain-security/README.md) | Michael Lieberman, John Kjell | Marina Moore |
 
 ## Additional information
@@ -100,6 +100,6 @@ Each group, led by a responsible leader, reaches consensus on issues and manages
 
 For [CNCF project proposal process](https://github.com/cncf/toc/blob/main/process)
 create a
-new [security review issue](https://github.com/cncf/tag-security/issues/new?assignees=&labels=assessment&template=security-assessment.md&title=%5BAssessment%5D+Project+Name)
+new [security assessment issue](https://github.com/cncf/tag-security/issues/new?assignees=&labels=assessment&template=security-assessment.md&title=%5BAssessment%5D+Project+Name)
 with a
 [self-assessment](/community/assessments/guide/self-assessment.md).

community/assessments/guide/README.md

@@ -116,7 +116,7 @@ and facilitate the process.
 
 In order to remediate unfair advantage or ethical issues all reviewers are
 required to provide a statement indicating all hard and soft conflicts they
-maintain prior starting the security review.
+maintain prior starting the security assessment.
 
 * **Lead security reviewer and additional security reviewers** comment any
      conflict of interest in the project's assessment ticket using the below format:

community/assessments/guide/joint-assessment.md

@@ -99,14 +99,14 @@ or overwhelming the servers)
 The joint-assessment is initially created by the project team and then
 collaboratively developed with the [security reviewers](security-reviewer.md) as
 part of the project's TAG-Security Security Assessment (TSSA) Process.
-Information about the TAG-Security Review can be found in the [CNCF TAG-Security
+Information about the TAG-Security Assessment can be found in the [CNCF TAG-Security
 Review Process Guide](./README.md).
 
 This document does not intend to provide a security audit of [project] and is
 not intended to be used in lieu of a security audit.  This document provides
 users of [project] with a security focused understanding of [project] and when
 taken with the [self-assessment](self-assessment.md) provide the community with
-the TAG-Security Review of the project.  Both of these documents may be used and
+the TAG-Security Assessment of the project.  Both of these documents may be used and
 references as part of a security audit.
 
 ## Intended Use

community/assessments/guide/project-lead.md

@@ -1,6 +1,6 @@
 # Project lead
 
-In the context of the project security review and self-assessment, the
+In the context of the project security assessment and self-assessment, the
 "project lead" should be someone on the security team for the project.  For new
 or smaller projects without an established security team, this could be a
 project maintainer or they may delegate to a regular contributor with an

community/assessments/guide/security-reviewer.md

@@ -64,10 +64,10 @@ of the reviewer and with authorization.
 ### Required
 
 Unless approved by TAG-Security chairs, the lead reviewer will have previously
-performed a CNCF security review.  Exemptions to this are reviewed case by
+performed a CNCF security assessment.  Exemptions to this are reviewed case by
 case upon established need by the CNCF TAG-Security chairs in order to bootstrap
 the process as appropriate.  If a lead reviewer has not previously performed a
-security review, and the chairs concur with them fulfilling the role, it is
+security assessment, and the chairs concur with them fulfilling the role, it is
 encouraged that at least 1 additional reviewer have experience and be leveraged
 as the delegate or designee by the lead.
 
@@ -183,7 +183,7 @@ The Security Assessment Facilitator or a TAG-Security chair must review the
 Lead Security Reviewer conflict-of-interest assertion.
 
 If any hard conflicts, or multiple significant soft conflicts, are presented,
-then a TAG-Security chair must approve the security review team. Reasons for
+then a TAG-Security chair must approve the security assessment team. Reasons for
  accepting and rejecting conflicts should be documented.
 
 In most cases, the existence of a hard conflict will prevent a TAG member from

community/assessments/projects/buildpacks/self-assessment.md

@@ -427,7 +427,7 @@ Native Ecosystem:
     * Additional work on image reproducibility
 * **CNCF Requests**
 
-    We would welcome a third-party security review.
+    We would welcome a third-party security assessment.
 
 ## **Appendix**
 

community/assessments/projects/flatcar/self-assessment.md

@@ -12,7 +12,7 @@ Authors: Danielle Tal and Thilo Fromm
 
 [the Appendix](#heading=h.7dxoyq24wwg8))
 
-This self-assessment thoroughly reflects on Flatcar Container Linux’ security mechanisms and processes, and lists and assesses security documentation. The document aims to provide a foundation for a [joint security review](/community/assessments/guide/joint-assessment.md) of the Flatcar project; target audience is [joint assessment reviewers](/community/assessments/guide/security-reviewer.md).
+This self-assessment thoroughly reflects on Flatcar Container Linux’ security mechanisms and processes, and lists and assesses security documentation. The document aims to provide a foundation for a [joint security assessment](/community/assessments/guide/joint-assessment.md) of the Flatcar project; target audience is [joint assessment reviewers](/community/assessments/guide/security-reviewer.md).
 
 
 # Metadata

community/assessments/projects/harbor/self-assessment.md

@@ -1027,7 +1027,7 @@ All new features must pass human review as well as automated testing. The projec
 
 
 *   Golint and Govet for managing compiler warnings, coding style, and correctness
-*   Gosec is used before each release as part of the internal security review
+*   Gosec is used before each release as part of the internal security assessment
 *   Black Duck Binary analysis is run every night for application security testing used to find security vulnerabilities that can make an application susceptible to attack
 
 

community/assessments/projects/openfga/joint-assessment.md

@@ -158,14 +158,14 @@ With this information, OpenFGA can be queried in different ways:
 The joint-assessment is initially created by the project team and then
 collaboratively developed with the security reviewers as
 part of the project's TAG-Security Security Assessment (TSSA) Process.
-Information about the TAG-Security Review can be found in the [CNCF TAG-Security
-Review Process Guide](https://tag-security.cncf.io/assessments/guide/).
+Information about the TAG-Security Assessment can be found in the [CNCF TAG-Security
+Assessment Process Guide](https://tag-security.cncf.io/assessments/guide/).
 
 This document does not intend to provide a security audit of OpenFGA and is
 not intended to be used in lieu of a security audit.  This document provides
 users of the project with a security focused understanding of OpenFGA and, when
 taken with the [self-assessment](./self-assessment.md), provide the community with
-the TAG-Security Review of the project.  Both of these documents may be used and
+the TAG-Security Assessment of the project.  Both of these documents may be used and
 referenced as inputs to a separate security audit.
 
 OpenFGA is a project that provides a security service and as such, any defect
@@ -384,7 +384,7 @@ could have catastrophic consequences to the organization.
     - malicious code protection is employed;
     - component and OpenFGA app related events are monitored and detected;
     - the correct configuration and operation of security features is tested and verified;
-    - information is checked for accuracy, completeness, validity, and authenticity. This is especially imporant in verifying and testing the model
+    - information is checked for accuracy, completeness, validity, and authenticity. This is especially important in verifying and testing the model
       syntax and semantics
 - Supply Chain Integrity and Attacks: How will risks related to OpenFGA itself, and its dependencies be assessed and tracked and remediated?
 - Incident Response, Disaster Recovery, Continuity, SRE: How will use of OpenFGA affect existing plans for responding to, investigating, and remediating
@@ -409,18 +409,18 @@ could have catastrophic consequences to the organization.
   - Malicious developers injecting malicious code or designs
 - Developer/App Design Failures
   - incorrect use of OpenFGA outside its intended design/goals
-  - incorrect confiuration of OpenFGA store, keys, certs, etc
+  - incorrect configuration of OpenFGA store, keys, certs, etc
   - incorrect definition of app code using OpenFGA to check relationships, conditions
   - incorrect or missing error handling code or corner cases
   - logging or leaking sensitive information
   - lack of stress and performance testing
   - not using the latest secure releases
 - OpenFGA/App Operations Failures
   - failure to check the provenance and integrity of code used
-  - failure to check the provenance and integrity of confiuration used
+  - failure to check the provenance and integrity of configuration used
   - failure to check the provenance and integrity of model(s) used
   - failure to secure keys, OIDC TLS, or database encryption and access control and auditing
-  - failute to plan for continuity and disaster recovery
+  - failure to plan for continuity and disaster recovery
   - failure to plan for security incident response
   - OpenFGA API service unavailable at runtime, either failing in a secure closed way, or due to DoS attack
   - Store database unavailable at runtime, either failing in a secure closed way, or due to DoS attack
@@ -450,7 +450,7 @@ should be considered outside the scope of this review.
 Opportunities for improvement identified include:
 
 - Implement FGA for server API
-- Relook at user-defined API tokens as an authentication mechanism for API
+- Re-look at user-defined API tokens as an authentication mechanism for API
 - Make all installation scripts "secure by default"
 - Validate best practices such as using strong API token and avoiding PII
 
@@ -464,7 +464,7 @@ tokens present several weak points that result in the findings below.
 The project recommends oauth for secure authentication to the API. The recommendation
 is to mark shared API tokens as a relatively insecure method of authentication and
 that his be avoided in a production environment. This recommendation can be
-updated both in the documentation as well as a WARNING can be emmitted in the logs
+updated both in the documentation as well as a WARNING can be emitted in the logs
 when authentication via shared API tokens is enabled.
 
 The recommendation to enable Fine Grained Authorization for the API is being
@@ -479,14 +479,14 @@ and performing authorization on the proxy.
 |Weakness|Env vars are accessible to anyone with access to the container. There cannot be further permissions set on these like files. Keys further give access to stores and models.|
 |MITRE classification|TA0001: Initial Access -> T1078: Valid Accounts<br>TA0003: Persistence -> T1078: Valid Accounts<br>TA0004: Privilege Escalation -> T1078: Valid Accounts|
 |Actors|openfga.server|
-|Suggested Mitigation|Secrets mounted in filesystem can be restricted with permissions. Alternatively, <br>SPIFFE/ Spire integration may offer a much high level of security (specifically using x.509 SVIDs).|
+|Suggested Mitigation|Secrets mounted in filesystem can be restricted with permissions. Alternatively, <br>SPIFFE/ Spire integration may offer a much high level of security (specifically using x.509 <!-- cSpell:ignore SVIDs -->).|
 |Impact (High/ Med/ Low)|High|
 |Likelihood (High/ Med/ Low)|Low|
 
 |Summary|Authenticating with shared keys allows keys to be added to the list.|
 |--|--|
 |Discovered in self-assessment?|No|
-|Weakness|Shared API keys are open to manipulation and bruteforcing since they are fixed keys.|
+|Weakness|Shared API keys are open to manipulation and brute-forcing since they are fixed keys.|
 |MITRE classification|TA0003: Persistence -> T1136: Create Account|
 |Actors|openfga.server|
 |Suggested Mitigation|Being able to manipulate keys in the container requires access to container. However, impact will be high as openfga access will allow attackers to assign themselves arbitrary privileges.<br>Mitigations include, the ability to rotate keys on a frequent basis and forcing these API tokens to be mounted as files (can be permission controlled) instead of environment variables. Don't use shared keys. Use OAuth or SPIFFE.|
@@ -507,7 +507,7 @@ and performing authorization on the proxy.
 ### Setting secure defaults for install
 
 This section has findings related to default install options that can be made more
-secure. The artifacts analysed in this section include the helm chart for installation
+secure. The artifacts analyzed in this section include the helm chart for installation
 and default configuration options.
 
 
@@ -686,7 +686,7 @@ Artifacts included with each release:
 
 | Aspect | Details |
 |--------|---------|
-| Secure Development Practices | Optional secure development training is provided by Okta. | Security Review is done for every feature addition. |
+| Secure Development Practices | Optional secure development training is provided by Okta. | Security Assessment is done for every feature addition. |
 | Code Quality and Testing | CodeQL is used on every pull request. The team is confident in the test coverage. |
 | Binary Management | CLOMonitor check passes, and the team is aware of the dangers of allowing binaries in the project. |
 | OpenSSF Scorecard | Badge present. Score is 9.3, well above the average of 4. |

community/assessments/projects/openfga/self-assessment.md

@@ -524,7 +524,7 @@ The [list](https://github.com/openfga/community/blob/main/ADOPTERS.md) of projec
 
 The list of related projects is available as a [community resource](https://github.com/openfga/community/blob/main/related-projects.md)
 
-### Third Party Security Reviews
+### Third Party Security Assessments
 
 <!-- markdown-link-check-disable -->
 [Trail Of Bits](https://www.trailofbits.com/) published a [Comparative Language Security Assessment](https://github.com/trailofbits/publications/blob/master/reports/Policy_Language_Security_Comparison_and_TM.pdf) that evaluates Cedar, Rego and OpenFGA.