render: don't assume prior matches exist within thread

[mike-hunhoff]

No description provided.

[github-actions]

Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased) section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed

CHANGELOG updated or no update needed, thanks! 😄

[williballenthin]

i don't quite understand the scenario that leads to this. can you share an example?

[mike-hunhoff]

i don't quite understand the scenario that leads to this. can you share an example?

Our test sample tests/data/dynamic/cape/v2.2/0000a65749f5902c4d82ffa701198038f0b4870b00a27cfca109f8f933476d82.json.gz triggers this bug after recent capa rule updates.

This bug is triggered when the rendering logic attempts to render a result containing a namespace match for host-interaction/process/create where two rules within this namespace, create process on Windows and create process suspended, match as capabilities. The logic corrected here assumes all of the matched namespace rules are within the same thread as the result being rendered. create process on Windows is matched in the same thread as the result being rendered but create process suspended is not matched in the same thread as the result being rendered. Therefore, an exception is triggered when create process suspended is processed and matches_in_thread is empty, because there are no matches for the rule in the same thread as the result being rendered.