Add update ATT&CK coverage step in lock versions

[shashank-elastic]

Pull Request

Issue link(s): #4757

Summary - What I changed

• Add update ATT&CK coverage step in lock versions
• Update PR body to reflect this change
• What can be decided is to remove the workflow .github/workflows/attack-coverage-update.yml or use it for adhoc purposes?

How To Test

• Unit Test to pass

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?

[github-actions]

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.

[traut]

🔥

[eric-forte-elastic]

If we add the ATT&CK coverage step in lock versions, then would there be any need to keep the .github/workflows/attack-coverage-update.yml workflow? Given that we always lock versions before a release and thereby always update the attack coverage in this scenario?

[shashank-elastic]

If we add the ATT&CK coverage step in lock versions, then would there be any need to keep the .github/workflows/attack-coverage-update.yml workflow? Given that we always lock versions before a release and thereby always update the attack coverage in this scenario?

Yes @eric-forte-elastic We can always deprecate that. I had called this out in the summary as well.

[shashank-elastic]

Deprecation will happen post the next release once this is executed end to end on release day. Discussed this with @eric-forte-elastic