clean up grammar spelling

Author: afzaljasani

docs/cloud/features/security/security.md

@@ -1,13 +1,13 @@
 # Security Overview
 
 
-At Tobiko, we treat security as a first class citizen because we know how valuable your data assets are. Our team follows and executes security best practices across each layer of our product. 
+At Tobiko, we treat security as a first-class citizen because we know how valuable your data assets are. Our team follows and executes security best practices across each layer of our product. 
 
 ## Tobiko Cloud Standard Deployment
 
 Our standard Tobiko Cloud deployment consists of several components that are each responsible for different parts of the product. 
 
-Below is a diagram of the components along with their description. 
+Below is a diagram of the components along with their descriptions. 
 
 ![tobiko_cloud_standard_deployment](./tcloud_standard_deployment.png){ width=80% height=60% style="display: block; margin: 0 auto" }
 
@@ -18,11 +18,11 @@ Below is a diagram of the components along with their description.
 
 ## Tobiko Cloud Hybrid Deployment
 
-For some customers, our hybrid deployment option is a great fit. It provides a seamless experience with Tobiko Cloud but in your own VPC and infrastructure.  
+For some customers, our hybrid deployment option is a great fit. It provides a seamless experience with Tobiko Cloud but within your own VPC and infrastructure.  
 
 In a hybrid deployment, Tobiko Cloud does not execute tasks directly with the engine. Instead, it passes tasks to the executors hosted in your environment, which then execute the tasks with the engine. 
 
-Executors are Docker containers that connect to both Tobiko Cloud and your SQL engine. They pull work tasks from the Tobiko Cloud scheduler and execute them with your SQL engine. This is a pull-only mechanism authenicated through an OAuth Client ID/Secret. Whitelist IPs in your network to allow reaching Tobiko Cloud IPs from the executor: 34.28.17.91, 34.136.27.153, 34.136.131.20
+Executors are Docker containers that connect to both Tobiko Cloud and your SQL engine. They pull work tasks from the Tobiko Cloud scheduler and execute them with your SQL engine. This is a pull-only mechanism authenticated through an OAuth Client ID/Secret. Whitelist IPs in your network to allow reaching Tobiko Cloud IPs from the executor: 34.28.17.91, 34.136.27.153, 34.136.131.20
 
 Below is a diagram of the components along with their description. 
 
@@ -36,17 +36,17 @@ Below is a diagram of the components along with their description.
 
 ## Internal Code Practices
 
-Our coding standards are guidelines we enforce throughout the organization to write, maintain, and collaborate on code effecively. These practice ensure consistency, maintainability, realibility, and most importantly, trust. 
+Our coding standards are guidelines we enforce throughout the organization to write, maintain, and collaborate on code effectively. These practice ensure consistency, maintainability, reliability, and most importantly, trust. 
 
 Below you will find a few examples of our interal code requirements. 
 
-- We have signed commits, required approvers, and signed docker artifacts.
-- Each commit to main is approved by someone different than the author.
-- We follow the standard of signing commits and then registering the key with GitHub. [Github Docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
+- We used signed commits, required approvers, and signed Docker artifacts.
+- Each commit to main must be approved by someone other than the author.
+- We follow the standard of signing commits and registering the key with GitHub. [Github Docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
 - Binary is signed using cosign and OIDC for keyless. [Signing docs](https://docs.sigstore.dev/cosign/signing/overview/)
-- Attestations are created that certify an image. We us GCP Binary Authorization to enforce this. [Attestation docs](https://cloud.google.com/binary-authorization/docs/key-concepts#attestations)
-- Encryption is a key feature of our security posture as well. This is enforced at each stage of access. For example, the state database automatically encrypts all data. Credentials are also securely encrypted and stored. 
-- We backup each state database nightly as well as before upgrades. These are stored indefinitely.
+- Attestations are created to certify an image. We use GCP Binary Authorization to enforce this. [Attestation docs](https://cloud.google.com/binary-authorization/docs/key-concepts#attestations)
+- Encryption is a key feature of our security posture and is enforced at each stage of access. For example, the state database automatically encrypts all data. Credentials are also securely encrypted and stored. 
+- We back up each state database nightly and before upgrades. These backups are stored indefinitely.
 
 
 ## Physical Property 
@@ -61,9 +61,10 @@ Revoke access for the GitHub user account associated with the compromised key an
 
 ### If someone steals a laptop, what's our continuity plan in protecting code?
 
-- All employee devices are monitored for appropriate encryption and password policies
-- Laptop protection is done through file encryption for Vanta
-- Mandatory lock screen after a timeout
-- We have a procedure for the disposal of an IT asset to mitigate keys being compromised through inappropriate disposal
-- See above for PGP key protection
+- All employee devices are monitored for proper encryption and password policies.
+- Laptop protection is enforced through file encryption via Vanta.
+- Mandatory lock screen after a timeout.
+- We follow a formal IT asset disposal procedure to prevent key compromise through improper hardware disposal.
+- See above for PGP key protection.
+- Binaries are signed using Cosign and OIDC for keyless signing.