You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Official repository to the Security Frameworks by SEAL. This repository contains the entire
4
-
structure and contents of the frameworks. Feel free to suggest from new categories to grammar
5
-
corrections. Collaboration is open to everyone. **This is a work in progress.**
3
+
Official repository to the Security Frameworks by SEAL. This repository contains the entire structure and contents of the frameworks. Feel free to suggest from new categories to grammar corrections. Collaboration is open to everyone. **This is a work in progress.**
6
4
7
-
If you want to know more about the frameworks or take a peek at the live book go to the following
Production will be at [frameworks.securityalliance.org](https://frameworks.securityalliance.org),
12
-
but not yet available.
5
+
If you want to know more about the frameworks or take a peek at the live book go to the following branches: [Main](frameworks.securityalliance.org), [Development](frameworks.securityalliance.dev).
There are currently two ways to collaborate. The first one is by logging from your Vercel account
24
-
and commenting directly on the deployed version of the book, and the second one is by forking the
25
-
repository and creating a pull request.
16
+
There are currently several ways to collaborate:
17
+
18
+
1. Using the "Suggest an edit" button on any page to make quick edits
19
+
2. Contributing to a specific framework through its dedicated branch
20
+
3. Forking the repository and creating a pull request to the develop branch
21
+
4. Commenting directly on the deployed version
22
+
23
+
> ⚠️ Please sign and verify every commit.
24
+
25
+
### Framework-specific branches
26
+
27
+
Before contributing, check if there's a [Steward](src/contribute/stewards.md) for the specific framework you're interested in, and reach out. We usually have separate branches pre-develop for frameworks with stewards.
28
+
29
+
The naming convention is `fw_framework_name`, for example `fw_opsec`, `fw_community_mgmt`. Ideally, you'll fork these framework-specific branches, as they typically have more updated information than what's available in the develop branch.
30
+
31
+
After making your changes:
32
+
1. Submit a PR to the framework-specific branch and let the steward know
33
+
2. After reviews, a PR can be submitted from the framework branch to the develop branch
34
+
35
+
If there's no specific branch created, that framework is still "headless," which means you can become its steward! See more in the [Stewards](src/contribute/stewards.md) section.
26
36
27
37
### Comments
28
38
@@ -33,25 +43,35 @@ To comment on the live version of the book under development, you will need to l
33
43
1. Fork the repository. Click on the "Fork" button at the top right corner of the page.
34
44
2. Clone the forked repository to your local machine. Open your terminal or command prompt.
3. Check if there's a framework-specific branch you should be working on. If yes, use that branch instead of develop.
47
+
4. Otherwise, make sure you're in the develop branch:
37
48
`git checkout develop`
38
-
4. Inside the folder create a new branch based on `develop`.
39
-
`git checkout -b develop`
40
-
5. Make your changes.
41
-
6. Make sure your changes don't break anything by testing it in the local setup (see above).
42
-
`./serve.sh`.
43
-
7. Commit your changes.
49
+
5. Inside the folder create a new branch based on the appropriate branch:
50
+
`git checkout -b your-feature-branch`
51
+
6. Make your changes.
52
+
7. If adding new pages, consider adding appropriate tags in the frontmatter. Example:
53
+
```
54
+
---
55
+
tags:
56
+
- Engineer/Developer
57
+
- Security Specialist
58
+
- Devops
59
+
- SRE
60
+
---
61
+
```
62
+
8. If adding significant content, add attribution using the contributors system (see [using-contributors.md](src/config/using-contributors.md)).
63
+
9. Make sure your changes don't break anything by testing it in the local setup:
64
+
`./serve.sh`
65
+
10. Commit your changes:
44
66
`git add .`
45
-
8. Commit the changes with a descriptive message:
46
-
`git commit -m "Fixing typos and improving readability on XXX section"`
47
-
9. Push the changes to your forked repository.
48
-
`git push origin develop`
49
-
10. Create a pull request. Go to your forked repository on GitHub. You should see a "Compare & pull
50
-
request" button. Click on it. Provide a descriptive title and description for your pull request.
51
-
11. Click on the "Create pull request" button.
52
-
12. Wait for review. Once your pull request is approved, and no more changes are needed, we will
53
-
merge it into the main repository.
54
-
13. Congratulations! Your changes are now part of the security frameworks!
67
+
11. Commit the changes with a descriptive message:
68
+
`git commit -S -m "Fixing typos and improving readability on XXX section"`
69
+
12. Push the changes to your forked repository:
70
+
`git push origin your-feature-branch`
71
+
13. Create a pull request. Go to your forked repository on GitHub. You should see a "Compare & pull request" button. Click on it. Provide a descriptive title and description for your pull request.
72
+
14. Click on the "Create pull request" button.
73
+
15. Wait for review. Once your pull request is approved, and no more changes are needed, we will merge it into the appropriate branch.
74
+
16. Congratulations! Your changes are now part of the security frameworks!
55
75
56
76
## Editor area
57
77
@@ -62,5 +82,4 @@ Editors merge PRs and push suggestions to the main branch which will be reflecte
62
82
3.`git merge origin/develop`
63
83
4. Manually merge files, solve conflicts and add a description.
64
84
65
-
- Using the `serve.sh` script instead of mdBook `serve` command is needed to be able to see properly
66
-
the local deployment.
85
+
- Using the `serve.sh` script instead of mdBook `serve` command is needed to be able to see properly the local deployment.
Copy file name to clipboardExpand all lines: src/community-management/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ Here, we present essential best practices to safeguard your community. In the fo
20
20
21
21
### Strong Passwords and Two-Factor Authentication (2FA)
22
22
23
-
- Use unique, complex passwords for each service and store them securely in a reputable password manager. Refer to the [**Operational Security Framework**](../operational-security/README.md) and [**Key Management Framework**](../key-management/README.md) for more information on this.
23
+
- Use unique, complex passwords for each service and store them securely in a reputable password manager. Refer to the [**Operational Security Framework**](../operational-security/README.md) and [**Wallet Security Framework**](../wallet-security/README.md) for more information on this.
24
24
- Secure the email account linked to your community platforms with a unique password and 2FA.
25
25
- Always enable 2FA. Prefer hardware-based tokens (e.g., Yubikey) or mobile authenticator apps over SMS-based methods, which are vulnerable to SIM-swapping.
26
26
- If you use an authenticator app like Authy, 1Password, or Aegis to generate time-based one-time passwords (TOTP). Ensure that the secret keys are stored encrypted and protected with robust security measures.
0 commit comments