-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complete OpenSFF Best Practices Badge #79
Comments
OpenSSF issue: The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) |
OpenSSF issue: The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software. Response:
PR: None Done: Select |
OpenSSF issue: The project website MUST succinctly describe what the software does (what problem does it solve?). Response: PR: None Done: Select |
OpenSSF issue: The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project. Response: https://oscal-compass.github.io/compliance-trestle/cli/ PR: None Done: Select |
OpenSSF issue: To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. PR: None Done: Select Met choice |
OpenSSF issue: The project SHOULD provide documentation in English and be able to accept bug reports and comments about code in English. Response: documentation - https://oscal-compass.github.io/compliance-trestle/ PR: None Done: Select Met choice |
OpenSSF issue: The project results MUST have a unique version identifier for each release intended to be used by users. Response: Releases are published to pypi https://pypi.org/project/compliance-trestle/#history with unique version numbers. PR: None Done: Select Met choice |
OpenSSF issue: To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. Response: PR: None Done: Select Met choice |
OpenSSF issue: It is SUGGESTED that the Semantic Versioning (SemVer) or Calendar Versioning (CalVer) version numbering format be used for releases. It is SUGGESTED that those who use CalVer include a micro level value Response: None (no space provided) PR: None Done: Select Met choice |
OpenSSF issue: It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. Response: trestle employs semantic versioning to create tagged releases. PR: None Done: Select Met choice |
OpenSSF issue: The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A. Response: PR: None Done: Select N/A |
OpenSSF issue: The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL required) Response: Bugs are reported under GIT by creating report using PR: None Done: Select Met choice |
OpenSSF issue: The project SHOULD use an issue tracker for tracking individual issues. Response: Reports are tracked under GIT issues. New issues are reviewed at least bi-weekly by the maintainers. PR: None Done: Select Met choice |
OpenSSF issue: The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix. Response: PR: None Done: Select Met choice |
OpenSSF issue: The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive). Response: https://github.com/oscal-compass/compliance-trestle/issues PR: None Done: Select Met choice |
OpenSSF issue: The project MUST have a publicly available archive for reports and responses for later searching. Response:
PR: None Done: Select Met choice |
OpenSSF issue: The project MUST publish the process for reporting vulnerabilities on the project site. Response: PR: None Done: Select Met choice |
1 similar comment
OpenSSF issue: The project MUST publish the process for reporting vulnerabilities on the project site. Response: PR: None Done: Select Met choice |
OpenSSF issue: The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. Response: PR: None Done: Select N/A |
OpenSSF issue: The project SHOULD be buildable using only FLOSS tools. Response: PR: None Done: Select Met |
OpenSSF issue: The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md). Response:
PR: None Done: Select Met |
OpenSSF issue: A test suite SHOULD be invocable in a standard way for that language. Response: PR: None Done: Select Met |
OpenSSF issue: It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. Response: PR: None Done: Select Met |
OpenSSF issue: Use basic good cryptographic practices Response: PR: None Done: Select Met |
OpenSSF issue: The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. Response:
PR: None Done: Select Met |
OpenSSF issue: It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). Response: PR: None Done: Select Met |
OpenSSF issue: The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. Response: PR: None Done: Select Met |
As part of the CNCF on-boarding process, the oscal-compass project needed to begin the OpenSSF Best Practices Badge. The initial badge assessment is 21% completed for basics.
This epic issue is in place to track the progress towards 100% completion.
The text was updated successfully, but these errors were encountered: