[Refactor proposal] streamline filtering of detection types across all code and Jinja templates
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by comparing contentctl/output/templates/savedsearches_detections.j2 and savedsearches_baselines.j2, then audit the repeated filtering and Pydantic validation logic mentioned in the discussion. The issue needs a project-wide design for handling Detection and Baseline types; done should mean the filtering is consistent and new detection types cannot be silently omitted.
Written by the indexing model from the issue text.
Description
Casey:
In the jinja2 template we determine detections to include as:
{% if (detection.type == 'TTP' or detection.type == 'Anomaly' or detection.type == 'Hunting' or detection.type == 'Correlation') %}This works in practice, but I'm concerned with the burden of having to track this filtering logic in multiple places in potentially inconsistent ways. If we added a new detection type, and neglected to change it here, we might silently be excluding new detections from our build
Eric:
We do this type of thing A LOT, including in all the Pydantic Validations.
The initial idea here is to treat Detections differently than Baselines, as you can see in the Jinja2 templates:
https://github.com/splunk/contentctl/blob/390c3727bf83b5af3e50e4ed4434b542a7d8629f/contentctl/output/templates/savedsearches_detections.j2contentctl/contentctl/output/templates/savedsearches_baselines.j2
Line 6 in 390c372
{% if (detection.type == 'Baseline') %}This comes from a time when a Baseline and a Detection were defined as the same object, I believe.
Let's talk more about how to actually fix this at scale. I also don't like how Baselines and Detections have SO MANY fields in common, but they are totally different objects (that only inherity from SecurityContentObject).
- Dominant language
- Python
- Stars
- 139
- Forks
- 51
- Avg merge
- 1h 16m
- Merged PRs (30d)
- 3
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from splunk/contentctl
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 45/100
splunk/contentctl#468 · 1 comment ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 38/100
splunk/contentctl#461 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 48/100
splunk/contentctl#452 ·
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 35/100
splunk/contentctl#464 · 3 comments ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
splunk/contentctl#451 ·
All issues in splunk/contentctl
Similar issues
-
adr
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
kristofdegrave/homeassistant-smart-charging#1607 ·
Maintainers usually reply within 1 day
-
namespace operations
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
EclipseFdn/open-vsx.org#13665 ·
Maintainers usually reply within 1 day
-
doc good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
collective/icalendar#1865 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
canonical/opentelemetry-collector-operator#409 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
mozilla/addons-release-tests#1243 ·
Maintainers usually reply within 1 day