docs: ruleset naming convention

This stricter naming convention is required to avoid corner cases in CI and the distribution system while providing a simple guideline for contributors.

Signed-off-by: Leonardo Grasso <[email protected]>

CONTRIBUTING.md

@@ -33,9 +33,9 @@ Rules files:
 
 ```
 falco_rules.yaml
-falco_rules.incubating.yaml
-falco_rules.sandbox.yaml
-falco_rules.deprecated.yaml
+falco-incubating_rules.yaml
+falco-sandbox_rules.yaml
+falco-deprecated_rules.yaml
 ```
 
 Falco offers configurability through the [falco.yaml](https://github.com/falcosecurity/falco/blob/master/falco.yaml) file, enabling support for the unique use cases of adopters. This configurability allows adopters to determine which rules should be loaded based on tags and other properties of the rules. With Falco 0.36 and beyond, it's now possible to apply multiple rules that match the same event, eliminating concerns about rule prioritization based on the "first match wins" principle.

README.md

@@ -31,6 +31,18 @@ The Falco Rules Files Registry contains metadata and information about rules fil
 
 Note: _Currently, the registry includes only rules for the syscall call data source; for other data sources see the [plugins repository](https://github.com/falcosecurity/plugins)._
 
+### Naming Convention
+
+Rule files must be located in the [/rules](rules) folder of this repository and are named according to the following convention: `<ruleset>_rules.yaml`.
+
+The `<ruleset>` portion represents the _ruleset_ name, which must be an alphanumeric string, separated by `-`, entirely in lowercase, and beginning with a letter.
+
+Rule files are subsequently released using Git tags. The tag name should follow the pattern `<ruleset>-rules-<version>`, where `<version>` adheres to [Semantic Versioning](https://semver.org/). See [RELEASE.md](RELEASE.md) for more details about our release process.
+
+For instance, the _falco_ ruleset is stored under [/rules/falco_rules.yaml](rules/falco_rules.yaml), and its version _1.0.0_ was released using the [falco-rules-1.0.0](https://github.com/falcosecurity/rules/releases/tag/falco-rules-1.0.0) tag.
+
+Note: _This convention applies to this repository only. Falco application does not impose any naming convention for naming rule files._
+
 <!-- Check out the sections below to know how to [register your rules](#registering-a-new-rule) and see rules currently contained in the registry. -->
 
 <!--

proposals/20230605-rules-adoption-management-maturity-framework.md

@@ -63,7 +63,7 @@ Levels (new Falco tags):
 >
 > for each rule. This tag reflects the robustness, relevance, applicability, and stability of each predefined rule in the [falcosecurity/rules](https://github.com/falcosecurity/rules/blob/main/rules/) repository. It serves as general guidance to determine which rules may provide the highest return on investment. As a minimum requirement, each rule must go through the `maturity_incubating` state before advancing to `maturity_stable`. Only `maturity_stable` rules will be enabled by default. We use the existing tags mechanisms to build upon a battle-proven solution and will provide transparent configurability through the `falco.yaml` file to support the unique use cases of adopters.
 >
-> Furthermore, we will start by implementing tagging for the rules and establishing new guides. Subsequently, we will gather feedback from the community. In the future, we believe it would be beneficial to divide the rules files into separate entities: `falco_rules.yaml` (keeping the old established file name for the stable rules), `falco_rules.incubating.yaml`, `falco_rules.sandbox.yaml`, and `falco_rules.deprecated.yaml`. However, since this change could potentially disrupt some adopters and result in breaking changes to the order in which rules are loaded, we believe it is necessary to prioritize other improvements first. For instance, we may need to introduce features such as allowing multiple rules to match on a single event or providing the ability to customize the loading order, to name just a few.
+> Furthermore, we will start by implementing tagging for the rules and establishing new guides. Subsequently, we will gather feedback from the community. In the future, we believe it would be beneficial to divide the rules files into separate entities: `falco_rules.yaml` (keeping the old established file name for the stable rules), `falco-incubating_rules.yaml`, `falco-sandbox_rules.yaml`, and `falco-deprecated_rules.yaml`. However, since this change could potentially disrupt some adopters and result in breaking changes to the order in which rules are loaded, we believe it is necessary to prioritize other improvements first. For instance, we may need to introduce features such as allowing multiple rules to match on a single event or providing the ability to customize the loading order, to name just a few.
 
 The maturity level of the rules, however, does not directly reflect their potential for generating noise in the adopters' environment. This is due to the unique and constantly changing nature of each environment, especially in cloud environments, making it challenging to accurately predict the impact of rules.