Adopt Core Infrastructure Initiative Best Practices

[smoya]

Reason/Context

All projects from the AsyncAPI Initiative are licensed as Open Source Software, in particular Apache 2.0 license is used by default for new projects.

In an effort to offer high-quality software, not just in terms of code but also in terms of security, transparency, and accessibility, in alignment with our Vision The AsyncAPI community grows 400% stated here we (may) want to adopt the Linux Foundation Core Infrastructure Initiative Best Practices. It also sounds ideal after our announcement made here about AsyncAPI joining a foundation.

Some context:

The Linux Foundation (LF) Core Infrastructure Initiative (CII) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices.
...
The Best Practices Program is an open source secure development maturity model. Projects having a CII badge will showcase the project’s commitment to security.
...
Examples of initial criteria include basic open source development practices (website, open source license, and user engagement), use of change control tools, attention to quality (automated test suite), and focus on security (secure project delivery method, use of dynamic and static analysis tools, as appropriate for the project).

There are different badges for the different criteria levels a project can achieve. Ordered from the most permissive to the most restrictive:

• Passing: focuses on best practices that well-run FLOSS projects typically already follow.
• Silver: is a more stringent set of criteria than passing but is expected to be achievable by small and single-organization projects.
• Gold: is even more stringent than silver and includes criteria that are not achievable by small or single-organization projects.

Description

Even though we may want to achieve the Gold level, Passing and Silver criteria levels should be previously achieved.
That's perfect for splitting this task into smaller actionables so we can adopt each level iteratively.

At least one GH issue should be created per level so we can properly track progress isolated. We can list them right here:

• Passing level issue: TBD
• Silver level issue: TBD
• Gold level issue: TBD

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[jonaslagoni]

This just to raise awareness on some of the security issues.

After looking more into the security requirements they have, it is gonna be seriously hard to pull off. I used these guidelines to suggest the process here: asyncapi/community#32 (comment)

Just for the Passing level, we need to fulfill the following:

There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. [vulnerabilities_fixed_60_days]
Projects SHOULD fix all critical vulnerabilities rapidly after they are reported. [vulnerabilities_critical_fixed]

As it varies a lot how active maintainers are this will be almost impossible. For the other two levels, there are also points that are gonna be difficult to pull off as we cant 100% control the process.

[jonaslagoni]

I think I am gonna try take a swing at this issue, if it is decided we want to invest time in this.

@derberg how do I propose this for TSC?

[derberg]

I believe it must be done the same way as with code coverage. First, do it for one repo and check out how it went, what was missing, etc. Then we introduce to TSC so all codeowners follow it in their repos, voting style

[jonaslagoni]

Started going through it for Modelina, to achieve Passing level - https://bestpractices.coreinfrastructure.org/en/projects/5279

The following steps are still missing:

• The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) [contribution_requirements]
• 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.
• 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. [test_policy]
• 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]
• It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. [tests_documented_added]
• There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. [vulnerabilities_fixed_60_days]
• Projects SHOULD fix all critical vulnerabilities rapidly after they are reported. [vulnerabilities_critical_fixed]
• 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]
• All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. [dynamic_analysis_fixed]