@@ -10,12 +10,12 @@ frameworks:
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
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
|
||||
|
||||
@@ -23,8 +23,7 @@ production and maintains adherence to coding standards.
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
|
||||
@@ -10,9 +10,9 @@ frameworks:
|
||||
---
|
||||
|
||||
## Purpose
|
||||
It ensures that potential security flaws are detected early. This
|
||||
proactive approach strengthens your security posture and helps
|
||||
maintain high code quality.
|
||||
|
||||
It ensures that potential security flaws are detected early. This proactive
|
||||
approach strengthens your security posture and helps maintain high code quality.
|
||||
|
||||
## Implementation
|
||||
|
||||
@@ -23,8 +23,8 @@ maintain high code quality.
|
||||
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.
|
||||
Code scanning will now run every time code is pushed to the repository, and
|
||||
results will appear in the Security tab.
|
||||
|
||||
## Evidence
|
||||
|
||||
|
||||
@@ -10,9 +10,10 @@ frameworks:
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
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
|
||||
|
||||
@@ -21,13 +22,13 @@ or insecure libraries in your codebase.
|
||||
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.
|
||||
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
|
||||
|
||||
|
||||
@@ -11,15 +11,14 @@ frameworks:
|
||||
|
||||
## 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.
|
||||
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.
|
||||
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
|
||||
|
||||
|
||||
@@ -10,11 +10,11 @@ frameworks:
|
||||
---
|
||||
|
||||
## Purpose
|
||||
SPF (Sender Policy Framework) prevents email spoofing by defining
|
||||
which mail servers are authorized to send emails on behalf of your
|
||||
domain. It helps receiving mail servers verify that incoming email
|
||||
from a domain comes from a host authorized by that domain's
|
||||
administrators.
|
||||
|
||||
SPF (Sender Policy Framework) prevents email spoofing by defining which mail
|
||||
servers are authorized to send emails on behalf of your domain. It helps
|
||||
receiving mail servers verify that incoming email from a domain comes from a
|
||||
host authorized by that domain's administrators.
|
||||
|
||||
## Implementation
|
||||
|
||||
@@ -41,4 +41,3 @@ administrators.
|
||||
- Screenshot of published SPF DNS record
|
||||
- Email header samples showing SPF pass
|
||||
- Documentation of authorized senders
|
||||
|
||||
|
||||
@@ -10,10 +10,11 @@ frameworks:
|
||||
---
|
||||
|
||||
## Purpose
|
||||
DKIM (DomainKeys Identified Mail) helps prevent email spoofing by
|
||||
adding a digital signature to outgoing messages, allowing receiving
|
||||
mail systems to verify that emails genuinely came from your domain and
|
||||
weren't modified in transit.
|
||||
|
||||
DKIM (DomainKeys Identified Mail) helps prevent email spoofing by adding a
|
||||
digital signature to outgoing messages, allowing receiving mail systems to
|
||||
verify that emails genuinely came from your domain and weren't modified in
|
||||
transit.
|
||||
|
||||
## Implementation
|
||||
|
||||
@@ -24,7 +25,8 @@ weren't modified in transit.
|
||||
3. Select your domain and click "Generate new record".
|
||||
4. Copy the DKIM TXT record provided by Google.
|
||||
5. Add this TXT record to your DNS.
|
||||
6. After DNS propagation, return to Admin console and click "Start authentication".
|
||||
6. After DNS propagation, return to Admin console and click "Start
|
||||
authentication".
|
||||
|
||||
## Evidence
|
||||
|
||||
|
||||
@@ -15,16 +15,18 @@ frameworks:
|
||||
---
|
||||
|
||||
## Purpose
|
||||
DMARC (Domain-based Message Authentication, Reporting, and
|
||||
Conformance) is a policy framework that builds upon SPF and DKIM. It
|
||||
tells receiving servers what to do when emails fail SPF or DKIM
|
||||
checks, and provides reporting on authentication results.
|
||||
|
||||
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a
|
||||
policy framework that builds upon SPF and DKIM. It tells receiving servers what
|
||||
to do when emails fail SPF or DKIM checks, and provides reporting on
|
||||
authentication results.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Google Workspace
|
||||
|
||||
1. Create a Google Group named `dmarc-report@example.com` which is assecible from external users.
|
||||
1. Create a Google Group named `dmarc-report@example.com` which is assecible
|
||||
from external users.
|
||||
2. Create DMARC record in monitoring mode:
|
||||
```
|
||||
Record: _dmarc.example.com
|
||||
@@ -38,5 +40,6 @@ checks, and provides reporting on authentication results.
|
||||
authentication of emails.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of DMARC DNS record
|
||||
- Sample aggregate reports
|
||||
|
||||
@@ -11,10 +11,9 @@ frameworks:
|
||||
|
||||
## Purpose
|
||||
|
||||
Implement email filtering and warning systems to reduce phishing risks
|
||||
and protect employees from malicious emails. This reduces mental load
|
||||
on employees and decreases company risk exposure through email-based
|
||||
attacks.
|
||||
Implement email filtering and warning systems to reduce phishing risks and
|
||||
protect employees from malicious emails. This reduces mental load on employees
|
||||
and decreases company risk exposure through email-based attacks.
|
||||
|
||||
## Implementation
|
||||
|
||||
|
||||
Reference in New Issue
Block a user