fix: Cleaning up the hashable content for the rule

[traut]

Pull Request

Issue link(s):

Summary - What I changed

• related_integrations field will be dropped from the dict that will be hashed to calculate the SHA256 hash of the rule.

How To Test

Checklist

• [ ] Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• [ ] 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

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[shashank-elastic]

We can use python -m detection_rules dev test-version-lock main to test this logic change

[shashank-elastic]

Testing Updates During Release part

• We patched the code to 8.18 and 9.0 branches locally and tested lock versions

• We ran this command on 8.18 and 9.0 python -m detection_rules dev build-release --update-version-lock

• The resulting lock versions file was diffed with main to Identify double bumps

• We never double bumps due to integration changes at all and identified 4 double bumps during testing for rules - Windows Event Logs Cleared - User Added to Privileged Group - Active Directory Group Modification by SYSTEM - Execution of a Downloaded Windows Script

  • All the above rules have to be minstacked.

  Attaching the same diff of version lock file with main and the version lock file when tested.

git_diff_output.txt version.lock.json

[github-actions[bot]]

Enhancement - Guidelines

These guidelines serve as a reminder set of considerations when addressing adding a feature to the code.

Documentation and Context

• [ ] Describe the feature enhancement in detail (alternative solutions, description of the solution, etc.) if not already documented in an issue.
• [ ] Include additional context or screenshots.
• [ ] Ensure the enhancement includes necessary updates to the 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 enhancement.
• [ ] Existing unit tests have been updated to reflect the changes.
• [ ] Provide evidence of testing and validating the enhancement (e.g., test logs, screenshots).
• [ ] Validate that any rules affected by the enhancement 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 enhancement does not break existing functionality.
• [ ] Review the enhancement with a peer or team member for additional insights.
• [ ] Verify that the enhancement works across all relevant environments (e.g., different OS versions).
• [ ] Confirm that all dependencies are up-to-date and compatible with the changes.
• [ ] Confirm that the proper version label is applied to the PR patch, minor, major.