eric-forte-elastic commented 1 month ago

Pull Request

Issue link(s): N/A First observed here

Summary - What I changed

In this original commit, the historical rule functionality was removed, and broke the file naming schema which appends rule version to the end of the rule_id (e.g. <rule_id>_<version>.json). This PR re-adds historical rules by default and ensures only the latest historical rules and the latest version are generated for the release package, but ensures they have versions appended. The versions are necessary for kibana's historical rules feature.

How To Test

Run the build without fail.

python -m detection_rules dev build-release --update-version-lock
Loaded config file: /Users/stryker/workspace/ElasticGitHub/detection-rules/.detection-rules-cfg.json

█▀▀▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄   ▄      █▀▀▄ ▄  ▄ ▄   ▄▄▄ ▄▄▄
█  █ █▄▄  █  █▄▄ █    █   █  █ █ █▀▄ █      █▄▄▀ █  █ █   █▄▄ █▄▄
█▄▄▀ █▄▄  █  █▄▄ █▄▄  █  ▄█▄ █▄█ █ ▀▄█      █ ▀▄ █▄▄█ █▄▄ █▄▄ ▄▄█

[+] Building package 8.16
 - 5 rules excluded from package
Package saved to: /Users/stryker/workspace/ElasticGitHub/detection-rules/releases/8.16
loaded security_detection_engine manifests from the following package versions: ['8.15.3', '8.15.2', '8.15.1', '8.14.9', '8.14.8', '8.14.7', '8.14.6', '8.14.5', '8.14.4', '8.14.3', '8.14.2', '8.14.1', '8.13.15', '8.13.14', '8.13.13', '8.13.12', '8.13.11', '8.13.10', '8.13.9', '8.13.8', '8.13.7', '8.13.6', '8.13.5', '8.13.4', '8.13.3', '8.13.2', '8.13.1', '8.12.20', '8.12.19', '8.12.18', '8.12.17', '8.12.16', '8.12.15', '8.12.14', '8.12.13', '8.12.12', '8.12.11', '8.12.10', '8.12.9', '8.12.8', '8.12.7', '8.12.6', '8.12.5', '8.12.4', '8.12.3', '8.12.2', '8.12.1', '8.11.21', '8.11.20', '8.11.19', '8.11.18', '8.11.17', '8.11.16', '8.11.15', '8.11.14', '8.11.13', '8.11.12', '8.11.11', '8.11.10', '8.11.9', '8.11.8', '8.11.7', '8.11.6', '8.11.5', '8.11.4', '8.11.3', '8.11.2', '8.11.1', '8.10.18', '8.10.17', '8.10.16', '8.10.15', '8.10.14', '8.10.13', '8.10.12', '8.10.11', '8.10.10', '8.10.9', '8.10.8', '8.10.7', '8.10.6', '8.10.5', '8.10.4', '8.10.3', '8.10.2', '8.10.1', '8.9.15', '8.9.14', '8.9.13', '8.9.12', '8.9.11', '8.9.10', '8.9.9', '8.9.8', '8.9.7', '8.9.6', '8.9.5', '8.9.4', '8.9.3', '8.9.2', '8.9.1', '8.8.15', '8.8.14', '8.8.13', '8.8.12', '8.8.11', '8.8.10', '8.8.9', '8.8.8', '8.8.7', '8.8.6', '8.8.5', '8.8.4', '8.8.3', '8.8.2', '8.8.1', '8.7.13', '8.7.12', '8.7.11', '8.7.10', '8.7.9', '8.7.8', '8.7.7', '8.7.6', '8.7.5', '8.7.4', '8.7.3', '8.7.2', '8.7.1', '8.6.10', '8.6.9', '8.6.8', '8.6.7', '8.6.6', '8.6.5', '8.6.4', '8.6.3', '8.6.2', '8.6.1', '8.5.8', '8.5.7', '8.5.6', '8.5.5', '8.5.4', '8.5.3', '8.5.2', '8.5.1', '8.4.5', '8.4.4', '8.4.3', '8.4.2', '8.4.1', '8.3.4', '8.3.3', '8.3.2', '8.3.1', '8.2.1', '8.1.1', '1.0.2', '1.0.1']
[+] Adding historical rules from 8.15.3 package
- sha256: f487ba5e502a8ee82317c65bc9a419f3aa294bba82200115ce5873ee65834aca
- 1193 rules included

Check the /releases/8.16/fleet/8.16.0-beta.1/kibana/security_rule folder and ensure all haves have an <rule_id>_<version>

ls -ltr |grep -v "_"

Make sure rules have <= 2 rules only per build

Checklist

[x] Added a label for the type of pr: bug, enhancement, schema, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
[x] Added the meta:rapid-merge label if planning to merge within 24 hours
[ ] Secret and sensitive material has been managed correctly
[ ] Automated testing was updated or added to match the most common scenarios
[ ] Documentation and comments were added for features that require explanation

Additional Context

Now that the DAC Beta branch has been merged, this is the first DR release that runs on this code. Even though the original commit reflects a while ago, it was only recently merged into main. Furthermore, the issue only appeared since the rule files changed as a side effect of the inadvertent code additions. With the latest rules staged on epr, the issue appears since rule file names do not include versions.

protectionsmachine commented 1 month ago

Bug - Guidelines

These guidelines serve as a reminder set of considerations when addressing a bug in the code.

Documentation and Context

[ ] Provide detailed documentation (description, screenshots, reproducing the bug, etc.) of the bug if not already documented in an issue.
[ ] Include additional context or details about the problem.
[ ] Ensure the fix includes necessary updates to the release documentation and versioning.

Code Standards and Practices

[ ] Code follows established design patterns within the repo and avoids duplication.
[ ] Code changes do not introduce new warnings or errors.
[ ] Variables and functions are well-named and descriptive.
[ ] Any unnecessary / commented-out code is removed.
[ ] Ensure that the code is modular and reusable where applicable.
[ ] Check for proper exception handling and messaging.

Testing

[ ] New unit tests have been added to cover the bug fix or edge cases.
[ ] Existing unit tests have been updated to reflect the changes.
[ ] Provide evidence of testing and detecting the bug fix (e.g., test logs, screenshots).
[ ] Validate that any rules affected by the bug are correctly updated.
[ ] Ensure that performance is not negatively impacted by the changes.
[ ] Verify that any release artifacts are properly generated and tested.

Additional Checks

[ ] Ensure that the bug fix does not break existing functionality.
[ ] Review the bug fix with a peer or team member for additional insights.
[ ] Verify that the bug fix works across all relevant environments (e.g., different OS versions).
[ ] Confirm that all dependencies are up-to-date and compatible with the changes.