37
controls/core/src/COR.SRC.001.patch_review.md
Normal file
37
controls/core/src/COR.SRC.001.patch_review.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id: "COR.SRC.001"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
||||
---
|
||||
|
||||
# Code Review
|
||||
|
||||
## Purpose
|
||||
|
||||
Requiring pull requests and code reviews ensures higher code quality and
|
||||
security by allowing multiple team members to catch bugs, inefficiencies, and
|
||||
potential vulnerabilities before code is merged. It also promotes collaboration,
|
||||
knowledge sharing, and accountability within the team. This process helps
|
||||
prevent issues in production and maintains adherence to coding standards.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Github
|
||||
|
||||
1. Open your GitHub repository and go to settings.
|
||||
2. In "Branche"s, click "Add Rule".
|
||||
3. Enter the branch name (e.g. "main") in the branch name pattern field.
|
||||
4. Enable: "Require a pull request before merging"
|
||||
5. Click Create or Save to apply the rule
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of branch protection rules configuration
|
||||
- Documentation of PR review process
|
||||
- Sample PR showing enforced requirements
|
||||
35
controls/core/src/COR.SRC.002.enable_code_scanning.md
Normal file
35
controls/core/src/COR.SRC.002.enable_code_scanning.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: "COR.SRC.002"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "15m"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC4.1", "CC8.1"]
|
||||
---
|
||||
|
||||
# Configure Code Scanning
|
||||
|
||||
## Purpose
|
||||
|
||||
It ensures that potential security flaws are detected early. This proactive
|
||||
approach strengthens your security posture and helps maintain high code quality.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Github
|
||||
|
||||
1. Go to the "Security" tab of your repository.
|
||||
2. Click on "Set up code scanning".
|
||||
3. Select "Set up this workflow" under "CodeQL Analysis".
|
||||
4. Review the YAML file and commit it to your repository.
|
||||
|
||||
Code scanning will now run every time code is pushed to the repository, and
|
||||
results will appear in the Security tab.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of code scanning results from Security tab
|
||||
- Sample of resolved security alerts
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id: "COR.SRC.003"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC4.1", "CC8.1"]
|
||||
---
|
||||
|
||||
# Configure Dependancy Vulnerability Alerts
|
||||
|
||||
## Purpose
|
||||
|
||||
It ensures your project stays secure and up-to-date without manual tracking of
|
||||
dependencies. It also reduces the risk of using outdated or insecure libraries
|
||||
in your codebase.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Github
|
||||
|
||||
1. Go to your repository on GitHub.
|
||||
2. Click on the "Settings" tab.
|
||||
3. On the left sidebar, click "Security & analysis".
|
||||
4. Under "Dependabot alerts", ensure "Dependency graph" and "Dependabot security
|
||||
updates" are enabled.
|
||||
5. GitHub will now alert you to any vulnerable dependencies and automatically
|
||||
open pull requests to fix them.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of Dependabot configuration screen
|
||||
- Sample of dependency update PRs
|
||||
- Vulnerability alert history
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: "COR.SRC.004"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-08"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
||||
---
|
||||
|
||||
# Document your Development Lifecycle
|
||||
|
||||
## Purpose
|
||||
|
||||
Formalizing a proper development lifecycle helps your engineer in their jobs and
|
||||
helps you to scale your team. It reduces the chances of human error.
|
||||
|
||||
## Implementation
|
||||
|
||||
Write a document with your development lifecycle. It should include: planning,
|
||||
analysis, design, coding, testing, and maintenance. Don’t forget secure coding
|
||||
practices (eg code review) and quality.
|
||||
|
||||
## Evidence
|
||||
|
||||
- System development lifecycle document
|
||||
Reference in New Issue
Block a user