Achieve CII Passing status

[dfarrell07]

What would you like to be added:

Work towards and achieve the CII Passing level.

https://bestpractices.coreinfrastructure.org/en/criteria

Why is this needed:

As a part of making sure we are a healthy project and a welcoming project for contributors.

[stale]

This issue has been automatically marked as stale because it has not had activity for 60 days. It will be closed if no further activity occurs. Please make a comment if this issue/pr is still valid. Thank you for your contributions.

[dfarrell07]

Bump

[stale]

This issue has been automatically marked as stale because it has not had activity for 60 days. It will be closed if no further activity occurs. Please make a comment if this issue/pr is still valid. Thank you for your contributions.

[dfarrell07]

We still want to do this, go away Stale Bot.

[stale]

This issue has been automatically marked as stale because it has not had activity for 60 days. It will be closed if no further activity occurs. Please make a comment if this issue/pr is still valid. Thank you for your contributions.

[tpantelis]

bump

[dfarrell07]

Can I put you forward as our security champion, @skitt?

The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.)
This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder:
economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)
fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default)
complete mediation (every access that might be limited must be checked for authority and be non-bypassable)
open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords)
separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication)
least privilege (processes should operate with the least privilege necessary)
least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files)
psychological acceptability (the human interface must be designed for ease of use - designing for "least astonishment" can help)
limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)
input validation with allowlists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use allowlists (which only accept known-good values), not denylists (which attempt to list known-bad values)).
A "primary developer" in a project is anyone who is familiar with the project's code base, is comfortable making changes to it, and is acknowledged as such by most other participants in the project. A primary developer would typically make a number of contributions over the past year (via code, documentation, or answering questions). Developers would typically be considered primary developers if they initiated the project (and have not left the project more than three years ago), have the option of receiving information on a private vulnerability reporting channel (if there is one), can accept commits on behalf of the project, or perform final releases of the project software. If there is only one developer, that individual is the primary developer. Many books and courses are available to help you understand how to develop more secure software and discuss design. For example, the Secure Software Development Fundamentals course is a free set of three courses that explain how to develop more 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.
Examples (depending on the type of software) include SQL injection, OS injection, classic buffer overflow, cross-site scripting, missing authentication, and missing authorization. See the CWE/SANS top 25 or OWASP Top 10 for commonly used lists. Many books and courses are available to help you understand how to develop more secure software and discuss common implementation errors that lead to vulnerabilities. For example, the Secure Software Development Fundamentals course is a free set of three courses that explain how to develop more secure software.

[dfarrell07]

https://bestpractices.coreinfrastructure.org/en/projects?q=submariner

[dfarrell07]

We're at 93%. I thought there was a way to allow other people to edit our answers, but I don't see it now that I'm trying to add folks.

https://bestpractices.coreinfrastructure.org/en/projects/4865

[dfarrell07]

Regarding sharing editing permissions, I see:

Note - if your repository URL is on GitHub, anyone who can commit to the repository will be able to edit the badge information.

https://bestpractices.coreinfrastructure.org/en/projects/new

Digging through their GitHub, I also see:

Additionally, To minimize calls to github also check if a GitHub user owns the repo of a badge, if so allow the user to edit the badge regardless of badge project "owner."

coreinfrastructure/best-practices-badge#1419

I think that means you should be able to edit the badge information, @skitt?

[skitt]

Additionally, To minimize calls to github also check if a GitHub user owns the repo of a badge, if so allow the user to edit the badge regardless of badge project "owner."

coreinfrastructure/best-practices-badge#1419

I think that means you should be able to edit the badge information, @skitt?

I’ve logged in with my GitHub account but I can’t edit anything :-(.

[skitt]

I wonder if that’s because the repository entry on the badge points to the organisation on GH, not a specific repository.

[skitt]

I see we also meet a number of silver level criteria...

[dfarrell07]

I wonder if that’s because the repository entry on the badge points to the organisation on GH, not a specific repository.

Yep, that was it, thanks @skitt! Everyone who can edit the main repo should now be able to edit the CII badge.

[dfarrell07]

Lots of PRs to add the CII badge to READMEs (and clean up other badges):

• Add CII badge, remove PR-triggered badges #1343
• Add CII badge, remove PR-triggered badges submariner-operator#1370
• Add CII badge, remove PR-triggered badges admiral#221
• Add CII badge, remove PR-triggered badges enhancements#31
• Add CII badge, remove PR-triggered badges lighthouse#538
• Add CII badge, remove PR-triggered badges releases#140
• Refactor badges in README shipyard#559
• Add CII and merged-CI badges to README submariner-charts#142
• Add CII badge, remove PR-triggered badges cloud-prepare#44

[dfarrell07]

These are the two remaining CII questions:

crypto_random:

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.
A cryptographically secure random number generator may be a hardware random number generator, or it may be a cryptographically secure pseudo-random number generator (CSPRNG) using an algorithm such as Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow, or Fortuna. Examples of calls to secure random number generators include Java's java.security.SecureRandom and JavaScript's window.crypto.getRandomValues. Examples of calls to insecure random number generators include Java's java.util.Random and JavaScript's Math.random.

dynamic_analysis_enable_assertions:

It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds.
This criterion does not suggest enabling assertions during production; that is entirely up to the project and its users to decide. This criterion's focus is instead to improve fault detection during dynamic analysis before deployment. Enabling assertions in production use is completely different from enabling assertions during dynamic analysis (such as testing). In some cases enabling assertions in production use is extremely unwise (especially in high-integrity components). There are many arguments against enabling assertions in production, e.g., libraries should not crash callers, their presence may cause rejection by app stores, and/or activating an assertion in production may expose private data such as private keys. Beware that in many Linux distributions NDEBUG is not defined, so C/C++ assert() will by default be enabled for production in those environments. It may be important to use a different assertion mechanism or defining NDEBUG for production in those environments.

Is this covered by assertions in our E2E tests?

[dfarrell07]

This is done, thanks for all the help @skitt! 🥳 ✔️