OpenSFF Best Practices Badge Program for Triggers

[afrittoli]

Achieve the OpenSFF Best Practices Badge.
Add the badge to the main project README.

Missing MUST checkboxes (doesn't mean we don't do these - I'm just unsure atm)

• If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL required) [vulnerability_report_private]

• The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project. [documentation_interface]
  (We have the swagger api - we should use that to generate an api reference)

• The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.) [know_secure_design]

• 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. [know_common_errors]

• 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. [crypto_keylength]

• 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. [crypto_random]

TODOs:

• Try getting added to https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/
• Audit webhook validation to see if we are using SHA1 only

[afrittoli]

FYI @tektoncd/triggers-maintainers - is anyone available to drive this to completion?

[dibyom]

Taking a stab at this

[dibyom]

At 21% but I think we just need to manually add links to our build/test docs to bump this number up!

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

[dibyom]

"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. [dynamic_analysis_enable_assertions] "

Does not have a N/A button

[dibyom]

Up to 63% - the Security tab will require some dedicated time to get through

[dibyom]

"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)."

GitHub webhook validation - I think we look at the SHA-1 header.

[afrittoli]

"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. [dynamic_analysis_enable_assertions] "

Does not have a N/A button

Because it's suggested, it's fine to say not met for now and update if/when we do add fuzzers

[dibyom]

The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project. [documentation_interface]

We need to port tektoncd/pipeline#4494

[afrittoli]

🎉 Thank you @dibyom !!!