Auto Generated Indexes v2

[mbellifa]

This is a non fork version of #1465, description copied below:

Background

Previously we generated the data for the Detection Coverage page manually. These changes aim to automate this generation as well as the markdown indexes in the /indexes/ folder.

Changes

• Adds steps to the release workflow which generates a detection-coverage.json and markdown indexes when a release is cut, which is then written back to the repo.
• Indexes now link to the YAML file rather than the associated Python code as they previously did

Testing

• It was difficult to fully test this since my fork doesn't have access to the same secrets. I made a branch with a modified workflow that commented out the portions requiring secrets. For example, this run does not use the Panther Bot secret.
  • Branch
  • Successful run
  • Commit from run
• I'm not sure if this method of writing back to the repo will work with code signing, let me know if you'd like me to try a different method
• Note that the workflow changes happen before the actual release is cut, so it may block the release process if it errors

[le4ker]

@c0nfleis @canagno123 is this the right email to use for the bot?

[canagno123]

Let's use the panther-bot-automation, like so:

git config --global user.email "[email protected]"
git config --global user.name "panther-bot-automation"

[arielkr256]

@mbellifa this is awesome! Would it make sense to also include the rule descriptions in the indexes?

[mbellifa]

@arielkr256 Good point, I updated the PR to add descriptions. You can see what it looks like in my little test fork: https://github.com/mbellifa/panther-analysis-test/blob/auto-indexes-run-fix/indexes/alpha-index.md

[arielkr256]

@mbellifa after discussing with the team I think it would be better to run this in a separate GHA that runs on PRs to develop vs adding it to the release workflow. This will ensure develop stays in sync with main and let us test it more thoroughly prior to each release.

[mbellifa]

@arielkr256 Would a workflow that triggered on a push to develop work? I'm thinking of using a filter that only runs when .yml files are changed so it doesn't loop. My concern with PRs is I'm reading that they can have different behavior/permission issues when a PR is opened from a fork, and I can envision increased merge conflicts if the indexes are built within the PRs themselves.

[arielkr256]

Yes I think that sounds great!