Open SSF Best Practices Regular

[balhar-jakub]

Prepare a space within the Community repo that will document that we are achieving the regular Best Practices badge and that can be used for auditing purposes.

[balhar-jakub]

Remaining pieces for auditing purposes:

• 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. [tests_are_added] - App Framework, ZSS @struga0258 , @JoeNemo
• The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. {N/A allowed} [warnings] - ZSS @JoeNemo
• The project MUST address warnings. {N/A allowed} [warnings_fixed] - ZSS @JoeNemo
• know_secure_design, know_common_errors - Intellij Plugin (Uladzislau is taking the course and that will resolve the auditing)
• A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over http and used without checking for a cryptographic signature. [delivery_unsigned] - Intellij Plugin, Zowe Explorer @KUGDev, @t1m0thyj
• 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. - API Mediation Layer, App Framework, ZSS @balhar-jakub , @struga0258, @JoeNemo

Security specific for Secrets SDK - CLI Squad needs to take a look @adam-wolfe

• 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). {N/A allowed} [crypto_published]
• 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. {N/A allowed} [crypto_call]
• All functionality in the software produced by the project that depends on cryptography MUST be implementable using FLOSS. {N/A allowed} [crypto_floss]
• 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). {N/A allowed} [crypto_weaknesses]
• 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. {N/A allowed} [crypto_pfs]
• If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., Argon2id, Bcrypt, Scrypt, or PBKDF2). See also OWASP Password Storage Cheat Sheet). {N/A allowed} [crypto_password_storage]
• 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. {N/A allowed} [crypto_random]

[adam-wolfe]

I've added responses after the bullet points:

Security specific for Secrets SDK - CLI Squad needs to take a look @adam-wolfe

• 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). {N/A allowed} [crypto_published]

Within the context of the Secrets for Zowe SDK (keytar replacement), we simply interact via standard APIs with the Windows credential manager, MacOS keychain, and libsecret on Linux/BSD systems. Zowe CLI and the Secrets SDK do not do anything cryptographically.

• 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. {N/A allowed} [crypto_call]

Zowe CLI and the Secrets SDK do not re-implement any cryptographic functions.

• All functionality in the software produced by the project that depends on cryptography MUST be implementable using FLOSS. {N/A allowed} [crypto_floss]

Zowe CLI does not rely on proprietary/closed source cryptographic functions.

• 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). {N/A allowed} [crypto_weaknesses]

According to https://www.npmjs.com/package/ssh2, the package we use for handling ssh comms, indicates that the default list of ciphers does not include CBC ciphers. We do not override the defaults, so I think we are fine.

• 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. {N/A allowed} [crypto_pfs]

I do not think that this applies to Zowe CLI. We do not generate keys or do anything like this.

• If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., Argon2id, Bcrypt, Scrypt, or PBKDF2). See also OWASP Password Storage Cheat Sheet). {N/A allowed} [crypto_password_storage]

I think this requirement is intended more for websites/apps that external users log in to. Since only the local user will be storing passwords using Zowe CLI and the secrets SDK, I think N/A is valid for this requirement.

• 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. {N/A allowed} [crypto_random]

Zowe CLI and the secrets SDK do not generate cryptographic keys.

[balhar-jakub]

Thanks @adam-wolfe for the thorough analysis. Added it to the table.

Current state of remaining pieces for auditing purposes:

• 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. [tests_are_added] - App Framework, ZSS @struga0258 , @JoeNemo
• The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. {N/A allowed} [warnings] - ZSS @JoeNemo
• The project MUST address warnings. {N/A allowed} [warnings_fixed] - ZSS @JoeNemo
• know_secure_design, know_common_errors - Intellij Plugin (Uladzislau is taking the course and that will resolve the auditing)
• 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. - API Mediation Layer, App Framework, ZSS @balhar-jakub , @struga0258, @JoeNemo