-
Notifications
You must be signed in to change notification settings - Fork 156
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
Technical OpenSSF Badge #2783
Comments
Reladed OpenSSF scorecard and link to the report This is the workflow used for the badge https://github.com/kanisterio/kanister/blob/master/.github/workflows/ossf-scorecard.yml |
What are the acceptable ways of doing this? If github issues with a specific label are acceptable ways of doing that I think it's a good idea. I think the workflow that we have to figure out vuln. in our images can be improved to raise another issue with specific label etc. |
Detailed requirement looks like that: Projects hosted on GitHub SHOULD consider enabling privately reporting a security vulnerability. Projects on GitLab SHOULD consider using its ability for privately reporting a vulnerability. Projects MAY identify a mailing address on https://PROJECTSITE/security, often in the form security@example.org. This vulnerability reporting process MAY be the same as its bug reporting process. Vulnerability reports MAY always be public, but many projects have a private vulnerability reporting mechanism. |
@mlavi can we add some link to SECURITY.md on the website? |
In order to request OpenSSF badge on the repo we need to fulfill the following requirements: https://www.bestpractices.dev/en/criteria/0
Expanding here for better tracking:
Basics
there's a link to slack and github on the website
POTENTIAL ENHANCEMENT we could add a direct link to CONTRIBUTING.MD @mlavi
POTENTIAL ENHANCEMENT add a general link to docs.kanister.io in README and the website @mlavi
POTENTIAL ENHANCEMENT link to API docs in the kanister docs @mlavi
Change control
TODO: currently using git log, switching to reno notes in future releases build(release): add reno tools to build image and makefile #2604 docs: add code review guide #2772 @hairyhum
TODO: Discuss if there's anything to do about tracking and reporting CVEs. Reno provides a format with
security:
field in the release notes. @mlavi @hairyhumReporting
The project MUST provide a process for users to submit bug reports (https://github.com/kanisterio/kanister/issues)
The project SHOULD use an issue tracker for tracking individual issues
The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix
We use
triage
tag for new issues. POTENTIAL ENHANCEMENT post a comment to issues when removingtriage
tag for more clarity @mlavi @hairyhum @viveksinghggits @pavannd1The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive).
The project MUST have a publicly available archive for reports and responses for later searching.
The project MUST publish the process for reporting vulnerabilities on the project site. Projects hosted on GitHub SHOULD consider enabling privately reporting a security vulnerability.
TODO: discuss how to address that. Do we use github issues? @mlavi @hairyhum @viveksinghggits @pavannd1
If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private.
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.
Currently synced in 2-weeks periods during kanister community meeting.
Quality
POTENTIAL ENHANCEMENT move some of the privately run test suites (e.g. e2e tests for example blueprints) to github, document how to run them @hairyhum @viveksinghggits @PrasadG193 @pavannd1
TODO: check coverage reports @hairyhum
Security
TODO: review the unchecked items @psilva-veeam @mlavi
The project MUST have at least one primary developer who knows how to design secure software
At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them
The software produced by the project MUST use, by default, only cryptographic protocols and algorithms that are publicly published and reviewed by experts (if cryptographic protocols and algorithms are used)
If the software produced by the project is an application or library, and its primary purpose is not to implement cryptography, then it SHOULD only call on software specifically designed to implement cryptographic functions; it SHOULD NOT re-implement its own.
The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled
The default security mechanisms within the software produced by the project MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5, single DES, RC4, Dual_EC_DRBG), or use cipher modes that are inappropriate to the context, unless they are necessary to implement an interoperable protocol (where the protocol implemented is the most recent version of that standard broadly supported by the network ecosystem, that ecosystem requires the use of such an algorithm or mode, and that ecosystem does not offer any more secure alternative). The documentation MUST describe any relevant security risks and any known mitigations if these broken algorithms or modes are necessary for an interoperable protocol.
The default security mechanisms within the software produced by the project SHOULD NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH)
The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.
The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure
The project MUST use a delivery mechanism that counters MITM attacks. Using https or ssh+scp is acceptable
A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over http and used without checking for a cryptographic signature
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. (upstream dependencies are addressed by dependabot)
TODO: we can use github/snyk code scanner to detect vulnerabilities (does
govulncheck
address that?) @pavannd1 @psilva-veeamTODO: discuss vulnerability tracking @pavannd1 @mlavi
The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access
TODO: double check that
Analysis
TODO: does
govulncheck
address that? @psilva-veeamThe text was updated successfully, but these errors were encountered: