53
controls/core/infra/COR.INF.001_list_your_assets.md
Normal file
53
controls/core/infra/COR.INF.001_list_your_assets.md
Normal file
@@ -0,0 +1,53 @@
|
|||||||
|
---
|
||||||
|
id: "COR.INF.001"
|
||||||
|
category: "core/infra"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "1h"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC2.1", "CC4.1"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# List of your Assets
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
The assets that are storing or processing data are potential vulnerabilities
|
||||||
|
that could be exploited. ⇒ You need to know which assets your company has in
|
||||||
|
order to be able to properly manage and secure them.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
If you don’t have one, create an inventory of all your assets that have the
|
||||||
|
potential to store or process data. This inventory should include:
|
||||||
|
|
||||||
|
- description of the device
|
||||||
|
- location
|
||||||
|
- owner
|
||||||
|
- operating status
|
||||||
|
|
||||||
|
### Google Cloud Platform
|
||||||
|
|
||||||
|
GCP Asset inventory can fulfil this for you if you implement it with systematic
|
||||||
|
tracking and monitoring:
|
||||||
|
|
||||||
|
1. Go to the **GCP console** and enable **Cloud Asset Inventory API**
|
||||||
|
2. Navigate to **API & Services** section, and enable **Cloud Asset API** for
|
||||||
|
the relevant projects
|
||||||
|
3. Identify which assets you want to monitor. You should include (if relevant):
|
||||||
|
1. Compute instances (e.g., VMs)
|
||||||
|
2. Storage (e.g., Cloud Storage Buckets)
|
||||||
|
3. Networking components (e.g., firewalls)
|
||||||
|
4. IAM policies and permissions
|
||||||
|
5. Encryption keys (Cloud KMS)
|
||||||
|
6. Logging (Cloud Audit Logs)
|
||||||
|
4. Set up **automatic collection** of assets using **GCP Cloud Scheduler** or
|
||||||
|
**GCP Cloud Functions** to regularly query and capture inventory snapshots
|
||||||
|
(that way you can maintain a record of changes) OR use glcoud commands/API
|
||||||
|
calls: `gcloud asset search-all-resources --scope=projects/your-project-id`
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot of your GCP asset inventory list
|
||||||
190
controls/core/infra/COR.INF.002_scan_security_updates.md
Normal file
190
controls/core/infra/COR.INF.002_scan_security_updates.md
Normal file
@@ -0,0 +1,190 @@
|
|||||||
|
---
|
||||||
|
id: "COR.INF.002"
|
||||||
|
category: "core/infra"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-08"
|
||||||
|
estimate-time: "1h"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC4.1", "CC6.8", "CC7.1"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Scan for security updates
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
An automated security scanning software on your infrastructure components
|
||||||
|
enables you to fix potential vulnerabilities as soon as they are uncovered.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
### 1/2 - Enable GCP security
|
||||||
|
|
||||||
|
1. Log in to your **Google Cloud Platform** account and navigate to the
|
||||||
|
**Security Command Center**.
|
||||||
|
2. Click **Enable** to activate the Security Command Center for your project or
|
||||||
|
organization.
|
||||||
|
3. If other members of your team need access, go to **IAM & Admin** > **IAM**
|
||||||
|
and assign to them the appropriate roles (**Security Center Admin** or
|
||||||
|
**Viewer**)
|
||||||
|
4. In the **Security Command Center dashboard**, look for **Security sources**
|
||||||
|
and click **Configure** or **Manage Sources**:
|
||||||
|
- **Asset Inventory**: Enables continuous tracking of assets within your GCP
|
||||||
|
project or organization.
|
||||||
|
- **Security Health Analytics**: Automatically scans your resources for
|
||||||
|
common vulnerabilities and misconfigurations.
|
||||||
|
- **Event Threat Detection**: Monitors your logs for suspicious activity and
|
||||||
|
potential threats.
|
||||||
|
- **Web Security Scanner**: Scans your public-facing web applications for
|
||||||
|
known vulnerabilities.
|
||||||
|
5. For each service you want to enable, click on it and follow the prompts to
|
||||||
|
activate it. Configure any necessary settings, such as defining which
|
||||||
|
resources should be scanned or monitored.
|
||||||
|
6. Integrate with other GCP services, such as **Cloud Logging** and **Cloud
|
||||||
|
Monitoring,** to collect detailed logs and metrics.
|
||||||
|
7. Save to update your settings. Verify that each service is active on the
|
||||||
|
Security Sources page.
|
||||||
|
|
||||||
|
### 2/3 - Enable Artifact registry
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
ℹ️
|
||||||
|
|
||||||
|
If you are already using Artifact Registry, make sure **Continuous scanning** is
|
||||||
|
enabled
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
1. Log in to your **Google Cloud Platform** account and navigate to **Artifact
|
||||||
|
Registry** under **Storage**.
|
||||||
|
2. Click **Enable API**
|
||||||
|
3. If other team members need access, go to **IAM & Admin** > **IAM** and assign
|
||||||
|
them appropriate roles:
|
||||||
|
- **Artifact Registry Admin**: Full access to manage repositories and
|
||||||
|
artifacts.
|
||||||
|
- **Artifact Registry Writer**: Permission to push artifacts to repositories.
|
||||||
|
- **Artifact Registry Reader**: Read-only access to repositories.
|
||||||
|
4. In **Artifact Registry**, click **Create Repository** and configure the
|
||||||
|
repository:
|
||||||
|
- **Name**: Set a name for your repository.
|
||||||
|
- **Location**: Choose a region or multi-region where the artifacts will be
|
||||||
|
stored.
|
||||||
|
- **Format**: Select the artifact type (e.g., Docker, npm, Maven).
|
||||||
|
- Enable **Continuous Scanning** to automatically scan for known
|
||||||
|
vulnerabilities in container images.
|
||||||
|
5. Click **Create**
|
||||||
|
6. For Docker images, run the following command to configure Docker
|
||||||
|
authentication with `gcloud`: (For other formats like **npm** or **Maven**,
|
||||||
|
follow the instructions in the **Setup instructions** section of your
|
||||||
|
repository).
|
||||||
|
|
||||||
|
```bash
|
||||||
|
gcloud auth configure-docker
|
||||||
|
```
|
||||||
|
|
||||||
|
7. Push artifacts to your repository:
|
||||||
|
- For Docker:
|
||||||
|
```bash
|
||||||
|
docker tag IMAGE_NAME LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME
|
||||||
|
docker push LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME
|
||||||
|
```
|
||||||
|
- For other formats, use the respective package manager (e.g., `npm publish`,
|
||||||
|
`mvn deploy`).
|
||||||
|
8. Verify your repository by navigating to **Artifact Registry > Repositories**,
|
||||||
|
and confirm that the uploaded artifacts appear in the repository.
|
||||||
|
|
||||||
|
### 3/3 - Implement alerts in Slack
|
||||||
|
|
||||||
|
1. Navigate to **Pub/Sub, c**lick **Create Topic**, give it a name (e.g.,
|
||||||
|
`security-artifact-alerts`) and click **Create**
|
||||||
|
2. On the topic you created, click **Create Subscription**, choose a name for
|
||||||
|
the subscription (e.g., `security-artifact-alerts-subscription`), and choose
|
||||||
|
**Pull** as the delivery type..
|
||||||
|
3. Go to the **Security Command Center**, click on **Settings** or
|
||||||
|
**Notifications**, choose **Create Notification**, provide a name for the
|
||||||
|
notification (e.g., `critical-findings-notification`) and select the
|
||||||
|
**resource type** (**Project** or **Organization**) to scope the
|
||||||
|
notification.
|
||||||
|
4. Define conditions for sending notifications, such as:
|
||||||
|
|
||||||
|
- **Severity** (e.g., only send alerts for high or critical severity
|
||||||
|
findings).
|
||||||
|
- **Finding types** (e.g., vulnerability detection, unauthorized access
|
||||||
|
attempts).
|
||||||
|
|
||||||
|
Use filters like:
|
||||||
|
|
||||||
|
```json
|
||||||
|
severity="CRITICAL"
|
||||||
|
```
|
||||||
|
|
||||||
|
5. Choose the **Pub/Sub topic** you created (`security-artifact alerts`) and
|
||||||
|
confirm the connection by allowing **Security Command Center** to publish to
|
||||||
|
this topic.
|
||||||
|
6. Go to **Artifact Registry** > **Repositories** and select a repository.
|
||||||
|
Navigate to **Settings** > **Notifications**.
|
||||||
|
7. Click **Add Notification** and select relevant event types:
|
||||||
|
- **Vulnerability Findings**
|
||||||
|
- **Failed Artifact Uploads**
|
||||||
|
- **Unauthorized Access**
|
||||||
|
8. Link this notification to the same **Pub/Sub topic**
|
||||||
|
(`security-artifact-alerts`).
|
||||||
|
9. Go to Slack API and click **Create New App**. Choose **From scratch**, name
|
||||||
|
the app and select your workspace.
|
||||||
|
10. In the app settings, go to **Incoming Webhooks** and toggle the switch to
|
||||||
|
**Activate Incoming Webhooks**. Click **Add New Webhook to Workspace** and
|
||||||
|
choose the channel where you want to post alerts. Copy the **Webhook URL**
|
||||||
|
provided after adding it - you will use it on GCP.
|
||||||
|
11. Go to **OAuth & Permissions** in the app settings and add the required
|
||||||
|
scope: `chat:write` and `incoming-webhook`
|
||||||
|
12. Send a test message to the channel using the **Webhook URL**:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl -X POST -H 'Content-type: application/json' --data '{"text":"Test alert from GCP Security and Artifact"}' YOUR_SLACK_WEBHOOK_URL
|
||||||
|
```
|
||||||
|
|
||||||
|
1. Go to **Cloud Functions** in **Google Cloud Console**, click **Create
|
||||||
|
Function** and provide a name (e.g., `send-alerts-to-slack`), choose
|
||||||
|
**Trigger type** as **Pub/Sub** and select your topic
|
||||||
|
(`security-artifact-alerts`). Set the runtime environment to **Python.**
|
||||||
|
2. Use the following example code to forward alerts to Slack: (replace
|
||||||
|
`YOUR_SLACK_WEBHOOK_URL` with your Slack incoming webhook URL)
|
||||||
|
|
||||||
|
```python
|
||||||
|
import base64
|
||||||
|
import json
|
||||||
|
import requests
|
||||||
|
|
||||||
|
def send_alert_to_slack(event, context):
|
||||||
|
# Decode the Pub/Sub message
|
||||||
|
pubsub_message = base64.b64decode(event['data']).decode('utf-8')
|
||||||
|
alert = json.loads(pubsub_message)
|
||||||
|
|
||||||
|
# Prepare the Slack webhook URL and message format
|
||||||
|
slack_webhook_url = 'YOUR_SLACK_WEBHOOK_URL' # <= To replace
|
||||||
|
message = {
|
||||||
|
'text': f"New Alert: {alert.get('finding', 'No details')} - Severity: {alert.get('severity', 'Unknown')} - Type: {alert.get('eventType', 'Unknown')}"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Send the alert to Slack
|
||||||
|
response = requests.post(slack_webhook_url, json=message)
|
||||||
|
|
||||||
|
if response.status_code != 200:
|
||||||
|
raise ValueError(f"Request to Slack returned an error {response.status_code}, the response is: {response.text}")
|
||||||
|
```
|
||||||
|
|
||||||
|
1. Set the entry point to `send_alert_to_slack` and deploy the function (wait
|
||||||
|
for it to activate).
|
||||||
|
2. Generate a test alert or monitor new alerts in **Security Command Center** to
|
||||||
|
verify that alerts are sent to your Slack channel.
|
||||||
|
- For Security Command Center: Simulate a high-severity finding.
|
||||||
|
- For Artifact Registry: Upload a vulnerable artifact or simulate
|
||||||
|
unauthorized access.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot of GCP Security enabled on your project
|
||||||
|
- Screenshot of GCP Security enabled on your registry
|
||||||
|
- Screenshot of Artifact Registry enabled on your registry
|
||||||
|
- Screenshot of an alert received OR of its configuration
|
||||||
@@ -0,0 +1,57 @@
|
|||||||
|
---
|
||||||
|
id: "COR.INF.003"
|
||||||
|
category: "core/infra"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-08"
|
||||||
|
estimate-time: "1h"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC6.1"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# IAM for database authentication
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
You want to ensure that only the proper people can access your production
|
||||||
|
database. You also want to avoid the burden of managing another list of users or
|
||||||
|
rotating credentials.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
### **Set Up Custom IAM Roles for Database Access**
|
||||||
|
|
||||||
|
1. In **Google Cloud Console**, go to **IAM & Admin** > **Roles**.
|
||||||
|
2. Click **Create Role** and define a custom role with only the necessary
|
||||||
|
permissions for your database (for a read-only role:
|
||||||
|
`cloudsql.instances.connect`, `cloudsql.instances.get`)
|
||||||
|
3. Save the role.
|
||||||
|
|
||||||
|
### **Assign Least Privilege Roles to Users or Service Accounts**
|
||||||
|
|
||||||
|
1. Go to **IAM & Admin** > **IAM**
|
||||||
|
2. Click **Add** to assign the custom role to specific users or service accounts
|
||||||
|
that require production database access.
|
||||||
|
3. In the **New principals** field, enter the email of the user or service
|
||||||
|
account.
|
||||||
|
4. Under **Role**, choose the custom role you created.
|
||||||
|
5. **Save**
|
||||||
|
|
||||||
|
### **Enable IAM Database Authentication (Cloud SQL Only)**
|
||||||
|
|
||||||
|
1. Go to **Cloud SQL** > **Instances**
|
||||||
|
2. Select your production database instance.
|
||||||
|
3. Under **Connections**, find the **Database Authentication** section and
|
||||||
|
enable **IAM database authentication** (allows users with the necessary IAM
|
||||||
|
roles to authenticate with their IAM credentials).
|
||||||
|
|
||||||
|
### Test access
|
||||||
|
|
||||||
|
1. In **Cloud Audit Logs** (under **Logging** > **Logs Explorer**), search for
|
||||||
|
`cloudsql.googleapis.com` to view access logs.
|
||||||
|
2. Verify that access is limited to authorized users.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot showing IAM is active on your Cloud SQL
|
||||||
88
controls/core/infra/COR.INF.004_short_live_auth_ci.md
Normal file
88
controls/core/infra/COR.INF.004_short_live_auth_ci.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
id: "COR.INF.004"
|
||||||
|
category: "core/infra"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "1h"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC6.1", "CC6.3"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Plug GCP & Github
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Having credentials to manage can become a nightmare (especially if you need to
|
||||||
|
change/rotate them often) - it quickly becomes time consuming. It is the same
|
||||||
|
with lifetime tokens - someone leaving and you need to change them.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
### **1. Create a Workload Identity Pool in GCP**
|
||||||
|
|
||||||
|
1. In **Google Cloud Console**, go to **IAM & Admin** > **Workload Identity
|
||||||
|
Federation**.
|
||||||
|
2. Click **Create Pool**, name it (e.g., `github-pool`), and set a
|
||||||
|
**description**.
|
||||||
|
3. Select **Provider type:** **OIDC** (OpenID Connect).
|
||||||
|
4. Under **Provider details**, enter: **Issuer URL**:
|
||||||
|
`https://token.actions.githubusercontent.com`
|
||||||
|
5. Click **Create** to finish setting up the pool.
|
||||||
|
|
||||||
|
### 2. **Create a Workload Identity Provider in the Pool**
|
||||||
|
|
||||||
|
1. In the pool, go to **Providers** and click **Add Provider**.
|
||||||
|
2. Name the provider (e.g., `github-provider`).
|
||||||
|
3. Set **Issuer URL** to `https://token.actions.githubusercontent.com`.
|
||||||
|
4. **Attribute mapping**: Add a mapping to verify the GitHub repository:
|
||||||
|
1. `google.subject` → `assertion.sub`
|
||||||
|
2. `attribute.repository` → `assertion.repository`
|
||||||
|
3. `attribute.ref` → `assertion.ref`
|
||||||
|
4. `attribute.owner` → `assertion.repository_owner`
|
||||||
|
5. Click **Create** to add the provider.
|
||||||
|
|
||||||
|
### 3. **Grant IAM Permissions on GCP**
|
||||||
|
|
||||||
|
1. Go to **IAM & Admin** > **IAM**.
|
||||||
|
2. Find the GCP service account you want GitHub Actions to use, or create a new
|
||||||
|
one.
|
||||||
|
3. Click **Add Principal** and specify the **Workload Identity Pool** (in the
|
||||||
|
format:
|
||||||
|
`principal://iam.googleapis.com/projects/PROJECT_ID/locations/global/workloadIdentityPools/POOL_ID/attribute.repository/OWNER/REPO`).
|
||||||
|
4. Assign the necessary **roles** (e.g., `Viewer`, `Editor`) to allow access to
|
||||||
|
resources.
|
||||||
|
|
||||||
|
### 4. **Configure GitHub Actions to Use Workload Identity**
|
||||||
|
|
||||||
|
1. In your **GitHub repository**, go to **Settings** > **Secrets and
|
||||||
|
variables** > **Actions**.
|
||||||
|
2. Add a new secret (e.g., `GCP_WORKLOAD_IDENTITY_PROVIDER`) containing the GCP
|
||||||
|
**Workload Identity Provider** details.
|
||||||
|
|
||||||
|
### 5. **Set Up GitHub Actions Workflow**
|
||||||
|
|
||||||
|
- In your **GitHub Actions workflow YAML file** (e.g.,
|
||||||
|
`.github/workflows/deploy.yml`), add steps to authenticate:
|
||||||
|
```yaml
|
||||||
|
jobs:
|
||||||
|
deploy:
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- name: Configure Google Cloud authentication
|
||||||
|
uses: google-github-actions/auth@v0
|
||||||
|
with:
|
||||||
|
workload_identity_provider:
|
||||||
|
${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
|
||||||
|
service_account: YOUR_GCP_SERVICE_ACCOUNT_EMAIL
|
||||||
|
- name: Run GCP commands
|
||||||
|
run: gcloud projects list
|
||||||
|
```
|
||||||
|
|
||||||
|
This setup enables secure, temporary access from **GitHub Actions** to **GCP**
|
||||||
|
resources without needing to store long-term credentials.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot of your Github actions workflow.
|
||||||
34
controls/core/infra/COR.INF.005_manage_service_account.md
Normal file
34
controls/core/infra/COR.INF.005_manage_service_account.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
id: "COR.INF.005"
|
||||||
|
category: "core/infra"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "30m"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC6.3"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Manage your service accounts
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
You don’t want to use the “default” service account, it has way too many
|
||||||
|
permissions - it is a super administrator. Even GCP is asking you not to use it,
|
||||||
|
it is only here for legacy reasons. In the same idea, grant your service
|
||||||
|
accounts only what is necessary.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
### Google Cloud Platform
|
||||||
|
|
||||||
|
1. Make sure the default service account is not used by any service - if it is
|
||||||
|
the case, create a new service account (with only View and/or Edit
|
||||||
|
permission) and use it.
|
||||||
|
2. Make sure all your service accounts are only Viewer or Editor - you shouldn’t
|
||||||
|
have any admin or owner.
|
||||||
|
3. Delete the default service account if not used anymore
|
||||||
|
|
||||||
|
Note: if you have IaC, it does make sense to have a service account as Admin,
|
||||||
|
but except in this kind of specific case: no admin
|
||||||
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
id: "COR.INF.006"
|
||||||
|
category: "core/infra"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "1h"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC5.3", "CC7.1", "CC7.2", "CC8.1"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Keep an history of all your changes
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Infrastructure as Code (IaC) makes sure all your infrastructure changes are done
|
||||||
|
in a standardized and repeatable process - the chance of human error is lower.
|
||||||
|
Moreover, IaC enables version control and peer reviews. When growing, you will
|
||||||
|
have to do it - the earlier the better (later, it can become really painful).
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
**Option 1:** If you don’t want an IaC, in the evidence section, provide a
|
||||||
|
screenshot of some log of your infrastructure changes
|
||||||
|
|
||||||
|
**Option 2:** If you already have an IaC, go directly to the evidence section,
|
||||||
|
we only need a screenshot.
|
||||||
|
|
||||||
|
**Option 3:** If you don’t have one, we recommend Terraform - the documentation
|
||||||
|
is available [here](https://developer.hashicorp.com/terraform/tutorials).
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot showing some logs
|
||||||
|
- Screenshot of the query you are performing in GCP to see your logs
|
||||||
@@ -1,14 +1,17 @@
|
|||||||
---
|
---
|
||||||
id: "COD-001"
|
id: "COR.SRC.001"
|
||||||
category: "code"
|
category: "core/src"
|
||||||
revision-version: 1
|
revision-version: 1
|
||||||
revision-date: "2024-01-07"
|
revision-date: "2024-01-07"
|
||||||
estimate-time: "15m"
|
estimate-time: "15m"
|
||||||
|
necessity: "mandatory"
|
||||||
frameworks:
|
frameworks:
|
||||||
- name: "soc2"
|
- name: "soc2"
|
||||||
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
# Code Review
|
||||||
|
|
||||||
## Purpose
|
## Purpose
|
||||||
|
|
||||||
Requiring pull requests and code reviews ensures higher code quality and
|
Requiring pull requests and code reviews ensures higher code quality and
|
||||||
@@ -1,14 +1,17 @@
|
|||||||
---
|
---
|
||||||
id: "COD-002"
|
id: "COR.SRC.002"
|
||||||
category: "code"
|
category: "core/src"
|
||||||
revision-version: 1
|
revision-version: 1
|
||||||
revision-date: "2024-01-07"
|
revision-date: "2024-01-07"
|
||||||
estimate-time: "15m"
|
estimate-time: "15m"
|
||||||
|
necessity: "optional"
|
||||||
frameworks:
|
frameworks:
|
||||||
- name: "soc2"
|
- name: "soc2"
|
||||||
sections: ["CC4.1", "CC8.1"]
|
sections: ["CC4.1", "CC8.1"]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
# Configure Code Scanning
|
||||||
|
|
||||||
## Purpose
|
## Purpose
|
||||||
|
|
||||||
It ensures that potential security flaws are detected early. This proactive
|
It ensures that potential security flaws are detected early. This proactive
|
||||||
@@ -1,14 +1,17 @@
|
|||||||
---
|
---
|
||||||
id: "COD-003"
|
id: "COR.SRC.003"
|
||||||
category: "code"
|
category: "core/src"
|
||||||
revision-version: 1
|
revision-version: 1
|
||||||
revision-date: "2024-01-07"
|
revision-date: "2024-01-07"
|
||||||
estimate-time: "15m"
|
estimate-time: "15m"
|
||||||
|
necessity: "mandatory"
|
||||||
frameworks:
|
frameworks:
|
||||||
- name: "soc2"
|
- name: "soc2"
|
||||||
sections: ["CC4.1", "CC8.1"]
|
sections: ["CC4.1", "CC8.1"]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
# Configure Dependancy Vulnerability Alerts
|
||||||
|
|
||||||
## Purpose
|
## Purpose
|
||||||
|
|
||||||
It ensures your project stays secure and up-to-date without manual tracking of
|
It ensures your project stays secure and up-to-date without manual tracking of
|
||||||
@@ -1,14 +1,17 @@
|
|||||||
---
|
---
|
||||||
id: "COD-004"
|
id: "COR.SRC.004"
|
||||||
category: "code"
|
category: "core/src"
|
||||||
revision-version: 1
|
revision-version: 1
|
||||||
revision-date: "2024-01-08"
|
revision-date: "2024-01-08"
|
||||||
estimate-time: "1h"
|
estimate-time: "1h"
|
||||||
|
necessity: "mandatory"
|
||||||
frameworks:
|
frameworks:
|
||||||
- name: "soc2"
|
- name: "soc2"
|
||||||
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
# Document your Development Lifecycle
|
||||||
|
|
||||||
## Purpose
|
## Purpose
|
||||||
|
|
||||||
Formalizing a proper development lifecycle helps your engineer in their jobs and
|
Formalizing a proper development lifecycle helps your engineer in their jobs and
|
||||||
Reference in New Issue
Block a user