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
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+16-3Lines changed: 16 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,15 +6,28 @@ We'd love to accept your patches and contributions to this project. There are ju
6
6
7
7
Participation in this project comes under the [Contributor Covenant Code of Conduct](./CODE_OF_CONDUCT.md)
8
8
9
+
## Local Development
10
+
11
+
While working on tests, the best way to run the plugin is via `go run . debug --service=<your-service>`. Ensure your local `config` file is set up correctly beforehand.
12
+
13
+
You may also pull the code locally and run the local Dockerfile:
14
+
15
+
1. Pull the repo
16
+
2. Modify `example-config.yml` to use your values, and rename it to `config.yml`
17
+
3. Build the Docker Image: `make docker-build`
18
+
4. Run the Docker Image: `make docker-run`
19
+
5. Review the output in the directory you've specified in your config file
20
+
21
+
## Required Token Scopes
22
+
23
+

24
+
9
25
## Code Submission
10
26
11
27
Thank you for considering submitting code to Privateer!
12
28
13
29
- We follow the [GitHub Pull Request Model](https://help.github.com/articles/about-pull-requests/) for all contributions.
14
-
- For large bodies of work, we recommend creating an issue using the "Feature Request" template to outline the feature that you wish to build, and describe how it will be implemented. This gives a chance for review to happen early, and ensures no wasted effort occurs.
15
-
- For new features, documentation must be included. Currently we do not have a formalized documentation process, so please use your best judgment until a process is in place.
16
30
- All submissions, including submissions by project members, will require review before being merged.
17
-
- Once review has occurred, please rebase your PR down to a single commit. This will ensure a nice clean Git history.
18
31
- Please write a [good Git Commit message](https://chris.beams.io/posts/git-commit/)
19
32
- Please follow the code formatting instructions below
This plugin is designed to test a GitHub repository using automated assessments compatible with the [Gemara](https://github.com/ossf/gemara)Layer 4 data types.
3
+
This application performs automated assessments against GitHub repositories using controls defined in the [Open Source Project Security Baseline v2025.02.25](https://baseline.openssf.org). The application consumes the OSPS Baseline controls using [Gemara](https://github.com/ossf/gemara)layer 2 and produces results of the automated assessments using layer 4.
4
4
5
-
Many of the assessments require a [Security Insights](https://github.com/ossf/security-insights) file to be present at the root of the repository, or `./github/security-insights.yml`.
5
+
Many of the assessments depend upon the presence of a [Security Insights](https://github.com/ossf/security-insights) file at the root of the repository, or `./github/security-insights.yml`.
6
6
7
7
## Work in Progress
8
8
9
-
Assessment development is currently addressing the [Open Source Project Security Baseline v2025.02.25](https://baseline.openssf.org).
9
+
Currently 39 control requirements across OSPS Baselines levels 1-3 are covered, with 13 not yet implemented. [Maturity Level 1](https://baseline.openssf.org/versions/2025-02-25.html#level-1) requirements are the most rigorously tested and are recommended for use. The results of these layer 1 assessments are integrated into [LFX Insights](https://insights.linuxfoundation.org/project/k8s/repository/kubernetes-kubernetes/security), powering the [Security & Best Practices results](https://insights.linuxfoundation.org/docs/metrics/security/).
10
10
11
-
As possible, the goal is to work on the OSPS Baseline maturity levels from the lowest to highest.
11
+

12
+
13
+
Level 2 and Level 3 requirements are undergoing current development and may be less rigorously tested.
We've pushed an image to docker hub for use in GitHub Actions. Many tests are currently pending implementation, and only `Maturity Level 1` is currently recommended for use.
28
+
We've pushed an image to docker hub for use in GitHub Actions.
16
29
17
30
You will also need to set up a GitHub personal access token with the repository read permissions. This token should be added to your config file, or — if using the example pipeline below — as a secret in your repository.
18
31
@@ -22,18 +35,10 @@ You will also need to set up a GitHub personal access token with the repository
While working on tests, the best way to run the plugin is via `go run . debug --service=<your-service>`. Ensure your local `config` file is set up correctly beforehand.
28
-
29
-
You may also pull the code locally and run the local Dockerfile:
38
+
## Contributing
30
39
31
-
1. Pull the repo
32
-
2. Modify `example-config.yml` to use your values, and rename it to `config.yml`
33
-
3. Build the Docker Image: `make docker-build`
34
-
4. Run the Docker Image: `make docker-run`
35
-
5. Review the output in the directory you've specified in your config file
40
+
Contributions are welcome! Please see our [Contributing Guidelines](.github/CONTRIBUTING.md) for more information.
36
41
37
-
## Required Token Scopes
42
+
## License
38
43
39
-

44
+
This project is licensed under the Apache 2.0 License - see the [LICENSE](LICENSE) file for details.
0 commit comments