MLOps tools for threat hunters.

A typical Tuesday for a hunter at the HMM2-to-HMM3 transition looks like this. You open the SIEM and form a hypothesis, say that "adversaries are using compromised cloud credentials to disable CloudTrail logging," and then you write a query that scans for API calls modifying logging configuration and filter out the noise, so that forty-seven raw results walk down to twelve true positives. You write the finding up, share it with the team, and maybe codify the best variant as a detection rule.

Every step of that workflow has a data-science name, because the hypothesis is a hypothesis, the query is exploratory data analysis, the forty-seven-to-twelve precision number is model validation, the write-up is reproducible research, and the detection rule is a deployed model. The reason most hunters don't call it that is partly cultural ("data scientist" reads as a different role with different credentials) and partly because the tools the data-science world uses for this work haven't been packaged for SOC teams.

The Splunk PEAK framework (Prepare, Execute, Act, Knowledge) and the SANS Hunting Maturity Model both describe this same workflow shape. PEAK is the per-hunt cycle. HMM is the organizational maturity ladder: HMM0 (no hunting) through HMM4 (leading with automation). I cover the PEAK mechanics in PEAK plus lakehouse hunting, and the HMM-to-detection-engineering progression in detection maturity. This piece is about the tools that sit underneath both.

One thing I want to set up front: none of what follows requires a PhD, a neural network, or years of Python. If you can write a SQL query and read a Markdown document, you have the prerequisites. The tools amplify the hunting skills you already have. They don't replace them, and they don't turn a hunt into a research paper unless you want it to.

I came to this reframing the slow way, by being the person hunters came to. For years, threat hunters kept landing at my desk for query help. They could hunt; what they couldn't always do was the data part, the work of expressing the question against the logs they had, making it run across the depth and duration the hunt actually needed, and shaping the results into something they could reason over. The good ones had taught themselves that craft because the job demanded it, and what they were doing underneath was querying at scale, building features, and hunting for patterns across breadth and time, which is data science whether or not anyone in the room would have used the words. That is the reframing from the inside, and it cuts two ways. Hire actual data scientists into hunting, and give the hunters you already have data-science-grade instruments instead of leaving them to improvise against a SIEM search bar.

A Jupyter notebook is a document that mixes code cells (SQL, Python, shell), Markdown narrative, and visualizations in one file. You run the cells top to bottom and the document carries the working state: query, dataframe, chart, paragraph explaining what you saw. Save the file, commit it to Git, and the hunt becomes a reproducible artifact rather than a transient SIEM session.

The contrast with a SIEM console is most of the argument, and the cleanest way to feel it is to live through the failure. It's Tuesday, I open the SIEM console, paste a hunting query I spent an hour crafting yesterday, and run it against two weeks of CloudTrail logs. The query completes. Zero results. I stare at the screen. Was the query wrong, or is the environment actually clean? I cannot remember the exact parameters from yesterday: was it fourteen days or seven, and did I filter out service accounts? A week later my manager asks me to re-run that hunt to validate the results, and by then the data has changed (new logs arrived, old logs aged out), the exact query logic is gone, and my notes are scattered across three Slack messages and a Word doc. That is the reproducibility problem in threat hunting, and it is the same problem data scientists faced ten years ago, so the data-science community already built the tools to solve it. They are free, open source, and well-documented, but most threat hunters haven't picked them up yet.

A Jupyter notebook checked into Git closes that gap, because it has the query, the filter, the chart code, and the narrative pinned together, so re-running it tells you whether the result still holds. What a notebook captures that a SIEM console doesn't, line by line:

• Query logic. SQL saved as a code cell, not lost when the session expires.
• Analysis code. The pandas filter that removed the compliance-scanner false positives, with a comment explaining why.
• Visualizations. Charts rendered inline at the point in the workflow where they matter, not screenshotted into a separate slide deck.
• Narrative. Markdown cells explain why each step happened, not just what it produced, which is the difference between an artifact a teammate can use and one they have to reverse-engineer.
• Reproducibility. Six months from now, another analyst opens the notebook, runs every cell, and gets the same answer, assuming the underlying data is preserved (which is what the dataset-versioning section below is for).

This pattern is well established outside the security world and increasingly inside it: Microsoft Sentinel ships Jupyter integration, Secureworks Taegis uses notebooks for investigation, and SpecterOps publishes notebook-based hunt content. The notebook doesn't replace the detection rule that eventually runs in production; it's the document that explains how the rule was derived, so when the rule fires six months later and someone asks "why does this exist?", the notebook is where they find the answer.

Time to first productive notebook is in the 2-to-8-hour range for an analyst who already writes SQL and reads Python comfortably. That estimate is drawn from training-workshop reports rather than a controlled study, so treat it as directional. Analysts who haven't worked with the pandas DataFrame model (the table-like object that holds query results in memory) tend to land at the upper end of that range; the shift from "SIEM result grid" to "DataFrame you can slice programmatically" is the one conceptual hurdle. Jupyter is free, open source, and runs on a laptop or a shared server. JupyterHub adds multi-tenant hosting for a team. For most HMM2-to-HMM3 teams, Jupyter is the only tool on this list they should adopt in the first six months.

A notebook is only useful if it can reach the data, and the lowest-friction option for a lakehouse-backed SOC is DuckDB, which you install as a Python package, point at S3, and use to query Iceberg tables directly from a notebook cell, with no server, no driver-installation argument with the SRE team, and no JDBC connection string. I cover DuckDB for threat hunting in a separate post, including its limits.

import duckdb

con = duckdb.connect()
df = con.sql("""
    SELECT * FROM iceberg_scan('s3://security-lake/cloudtrail/')
    WHERE event_time > '2026-01-01'
""").df()

print(df.head())

For larger workloads, the notebook can connect to a shared engine instead, whether that's StarRocks or ClickHouse via SQLAlchemy, Trino via its Python client, or PySpark for very large jobs, and the notebook code stays structurally the same because only the connection target changes. That portability is one of the reasons I push analysts toward notebooks early, since the same code runs against a local DuckDB cache for development and a production engine for the real hunt. The integration surface is wide: DuckDB for local Iceberg queries, SQLAlchemy for ClickHouse or StarRocks, REST calls for catalogs, and embed cells for Grafana.

Getting started takes about fifteen minutes if you already have Python, since you install JupyterLab and DuckDB with pip, launch jupyter lab, open a new notebook, and run a SELECT, and if you know SQL and basic Python you'll be productive in a working day. Practitioner training data suggests two to four hours for the first useful hunt, with longer for analysts new to pandas, and the interface is intentionally simple, so that Shift+Enter executes a cell, Markdown cells render inline, and charts appear where the code runs. The Arrow plus ADBC path is the columnar-native version of this connection, and removes the row-to-column serialization tax on result sets.

For a first run, MLflow needs almost nothing. Install with pip, start the UI on localhost, point your notebook at it, and log a test run.

pip install mlflow
mlflow ui   # serves http://localhost:5000

# In a notebook
import mlflow
mlflow.set_tracking_uri("http://localhost:5000")
with mlflow.start_run(run_name="test_hunt"):
    mlflow.log_param("test_param", "hello")
    mlflow.log_metric("test_metric", 42)

That's enough to learn the concepts. For a team, you'll want a shared deployment so multiple analysts log runs to the same place, and the standard pattern is a PostgreSQL backend for the run metadata plus an S3 bucket for artifacts, both of which a security team usually already has provisioned. The PostgreSQL backend can co-locate with your catalog's database to reduce operational surface, and the artifact root can point at the same object storage that backs your Iceberg tables.

mlflow server \
    --backend-store-uri postgresql://mlflow:password@localhost/mlflow \
    --default-artifact-root s3://security-lake/mlflow/artifacts/

Production hosting cost is modest. A small PostgreSQL instance plus modest artifact storage runs in the range of fifty to two hundred dollars a month at typical SOC scale, based on AWS list pricing for a db.t3.medium RDS plus a few hundred gigabytes of S3. Managed offerings exist (Databricks MLflow, AWS SageMaker Experiments) if you'd rather not run it yourself, and they cost two to five times the self-hosted figure. I lean self-hosted for security teams because the artifacts are the detection rules themselves, and keeping them inside your existing S3 footprint avoids a separate data-residency conversation.

There is a security catch worth stating plainly, since the whole premise is that you will run this yourself. The MLflow tracking server has a documented remote-attack-surface record, and the things it holds (your detection rules, your dataset pointers, sometimes the warehouse credentials a run needs) are exactly what an attacker would want. The 2025–2026 advisories are not theoretical. CVE-2025-11201 is an unauthenticated directory traversal that reaches remote code execution through an unvalidated source path, and CVE-2026-2614 lets an unauthenticated request read arbitrary files by smuggling a file:// source past a validation bypass. CVE-2026-2635 shipped exploitable default credentials in basic_auth.ini that hand over admin to whoever finds the port before you rotate them (fixed ahead of 3.8.0rc0), while CVE-2026-2734 lets any authenticated low-privilege tenant read model metadata across tenant boundaries it should not cross. A service that stores the logic your SOC runs on should not be the easiest box on the network.

None of that is a reason to avoid MLflow; it is a reason to run it like the production service it is. The discipline that answers this has a name, SecMLOps: keep the tracking server off the public internet, bound to localhost or behind the same VPN the rest of your SOC tooling already sits behind, and rotate the default credentials on day one, ideally replacing basic auth with your existing SSO. Constrain artifact source paths to an allowlist and reject file:// and absolute filesystem paths, so a traversal has nowhere to escape to. And because a model artifact is executable code, prefer pickle-free serialization like ONNX or Safetensors over raw pickle, joblib, or torch weights, which run arbitrary code on load and turn a poisoned model file into an entry point. The principle is the one this site keeps returning to: the tooling that holds your security logic is security-relevant in its own right, and it earns the same scanning, patching, and network hygiene you would give anything else in production.

MLflow tracks the run, but it does not freeze the dataset the run ran against, so if the underlying CloudTrail data changes between Tuesday and the following Tuesday (new events arrive, old events age out of hot storage), re-executing the run will produce different numbers, and MLflow will dutifully log the new numbers without telling you the data drifted. Closing that gap is what data versioning is for. DVC is the simplest tool on this list to explain and the hardest to convince a team they need. The pitch: it is Git for data. You version multi-terabyte datasets using small metadata files in Git, with the actual data living in object storage (S3, Azure Blob, GCS). A dvc checkout against a tag pulls the exact bytes present when that tag was created, which gives you time travel without copying petabytes around.

Why a hunter cares: detection-rule validation is fragile. You tune a rule against ninety days of CloudTrail data, measure 86% precision, and ship it. Three months later, you tune it again and want to know whether the change moved precision from 86% to 92% or whether it stayed flat and the apparent gain came from log volume drift. Without a frozen baseline dataset, you can't tell. With DVC, you check out the same ninety-day window you used originally and re-run the validation against bit-identical data.

The Iceberg-specific wrinkle: Iceberg already has snapshot IDs and time-travel queries. For teams already on Iceberg, the DVC layer mostly captures the snapshot ID as metadata rather than copying the data. Iceberg vs Delta Lake covers the table-format mechanics. The honest position is that for an Iceberg-native shop, DVC may be redundant; Iceberg snapshots plus a tagging convention can do the job. DVC earns its keep when you're moving filtered subsets out of Iceberg into training datasets for ML-based detection, or when you need to track non-Iceberg artifacts (a CSV of known-malicious IPs, a parquet file of labeled training data) with the same workflow as the code.

Learning curve is four-to-six hours for someone who already understands Git. The harder part is operational: provisioning the remote storage, agreeing on a tagging convention, and getting the team to actually create tags before running validation experiments. That last item is the one that determines whether DVC pays off or sits unused.

I want to put the recommendation first, because the rest of this section covers tooling most of you don't need yet. SANS research puts roughly 8% of organizations at HMM4, "Leading" maturity, where systematic automation, ML pipelines, and reproducible workflows are the working pattern, and the other 92% are at HMM2 (procedural hunting on community playbooks) or HMM3 (innovative analytics on home-grown queries). At HMM2 and HMM3 the right toolchain is the one above, Jupyter for hunt prototyping and MLflow for experiment tracking, because a feature store at that stage is mostly overhead you pay for before there's enough model count to give it something to do. Most security teams I talk to are running zero supervised ML models in production, not the dozens that would make the feature-store problem bite.

A feature store is a system that computes derived attributes ("features") from raw data once, stores them, and serves them consistently to every model that needs them. Three pieces of vocabulary do most of the work. A feature is a derived numeric or categorical signal computed from raw data: failed_logins_24h is a feature, login_geo_diversity_score is a feature, rare_process_count is a feature; the raw authentication log line is not a feature, but the count of failures in a 24-hour window for a given user is. A feature store centralizes the definition, computation, and serving of those features, so there's one definition served consistently to every model. The store has two faces: the offline store holds historical features for training (typically Iceberg tables, Snowflake, BigQuery), and the online store holds the latest precomputed values for real-time inference at low latency (typically Redis or DynamoDB), because production detection cannot wait several seconds for a feature-extraction query to run against raw logs.

The third piece is point-in-time correctness, which is subtle and matters more than people realize. When I train a model to predict whether a user session was compromised at 09:00 on Tuesday, I can only use features whose values would have been computable at 09:00 on Tuesday. If I accidentally let the training set see failed_logins values aggregated as of 17:00 the same day, the model "cheats" by accessing future data that won't exist at inference time, and the production model then performs far worse than the training metrics promised. A feature store handles this correctly by joining historical entity-and-timestamp rows against the feature value as of that timestamp, and hand-rolled feature pipelines almost always get this subtly wrong on the first few iterations. The reason isn't that the SQL is impossible to write but that it's easy to write incorrectly, and the failure mode (overfit training metrics, underperforming production model) is hard to debug after the fact, which makes point-in-time correctness one of the strongest standalone arguments for using a feature store rather than rolling your own.

The clearest signal you need one is operational rather than architectural. If your detection team maintains more than ten or fifteen supervised ML models and the same derived features (failed_logins_24h, geo_diversity_score, rare_process_count, parent-process-chain-depth) are being extracted independently by each model with slightly different windowing logic, that's when the duplication and inconsistency cost starts to outweigh the platform cost. Below that threshold a shared SQL view or a dbt model probably does the job. The second signal is that an analyst investigating an alert from Model A pulls their own ad-hoc query and gets a different number from what the alert reports, because Model A counts a rolling 24-hour window and the analyst's ad-hoc query counts the calendar day, so the analyst starts to stop trusting the alerts. That's the feature-definition-drift problem, and a feature store is one solution to it, though it isn't the only one.

Feast began at Google and Gojek, was open-sourced in 2019, and now lives under Linux Foundation AI & Data governance with an Apache 2.0 license. It supports more than fifteen offline stores (BigQuery, Snowflake, Redshift, Iceberg, DuckDB, and others) and around ten online stores (Redis, DynamoDB, Cassandra, PostgreSQL). The maturity story on the platform itself is solid; the maturity story on security-specific deployments is the gap I keep coming back to. Feast has four moving parts: a feature registry in S3 or Postgres holds the definitions (the YAML and Python that say what features exist and how they're computed), the offline store (Iceberg in the lakehouse architectures I work with) holds historical feature values for training, the online store (Redis is the typical choice) holds the latest values for low-latency inference, and an optional feature server is a REST API for non-Python clients to read features.

A minimum-viable feature definition in Feast looks like this:

from feast import Entity, FeatureView, Field
from feast.types import Float32, Int64
from datetime import timedelta

user = Entity(name="user", join_keys=["user_id"])

user_behavior_fv = FeatureView(
    name="user_behavior_features",
    entities=[user],
    ttl=timedelta(days=7),
    schema=[
        Field(name="failed_logins_24h", dtype=Int64),
        Field(name="successful_logins_7d", dtype=Int64),
        Field(name="login_geo_diversity_score", dtype=Float32),
        Field(name="privileged_action_count", dtype=Int64),
    ],
    online=True,
    source=iceberg_source,
)

Two things to notice. The schema definition is the single source of truth, so every model that reads user_behavior_features:failed_logins_24h reads the same value computed by the same definition. And online=True tells Feast to materialize the values into the online store, which is what makes the feature available for sub-50ms inference rather than only for batch training. The training-side API is where point-in-time correctness shows up: you pass an entity dataframe of (user_id, event_timestamp) rows and the feature names you want, and Feast joins back against historical feature values as of each timestamp:

from feast import FeatureStore

store = FeatureStore(repo_path=".")

training_df = store.get_historical_features(
    entity_df=entity_df,
    features=[
        "user_behavior_features:failed_logins_24h",
        "user_behavior_features:login_geo_diversity_score",
        "user_behavior_features:privileged_action_count",
    ],
).to_df()

The corresponding online call returns the latest precomputed values for a given entity in a few milliseconds from Redis, which gives you the basic shape: you define a feature once, train against the historical features and infer against the online ones, and you stop copy-pasting the same SQL into eighty different model repos.

Kedro is the pipeline framework that tends to travel with Feast. It's an open-source framework for organizing data-science and ML pipeline code into modular nodes and pipelines, developed at QuantumBlack (McKinsey's analytics arm) and open-sourced under Apache 2.0, and the honest one-liner is that it structures workflows to enforce modularity, configuration management, and reproducibility on code that would otherwise be a pile of notebooks. A node is a Python function with declared inputs and outputs, a pipeline is a directed acyclic graph of nodes wired together by name, and a data catalog defines where each named input or output lives (an Iceberg table, a parquet file, a feature view, a Redis key). Running kedro run materializes the pipeline; kedro viz opens an interactive DAG view in the browser. A condensed detection pipeline looks like:

from kedro.pipeline import Pipeline, node
from .nodes import (
    ingest_cloudtrail, normalize_ocsf, extract_features,
    load_feature_store, run_detection_models,
    filter_high_confidence, send_alerts,
)

def create_detection_pipeline() -> Pipeline:
    return Pipeline([
        node(ingest_cloudtrail, "params:cloudtrail_path", "raw_cloudtrail"),
        node(normalize_ocsf,    "raw_cloudtrail",         "ocsf_events"),
        node(extract_features,  "ocsf_events",            "user_features"),
        node(load_feature_store,"user_features",          None),
        node(run_detection_models, "ocsf_events",         "raw_alerts"),
        node(filter_high_confidence, "raw_alerts",        "validated_alerts"),
        node(send_alerts,       "validated_alerts",       None),
    ])

What Kedro buys you, specifically: the OCSF normalization step can be changed without re-testing the feature-extraction step, the data catalog tracks lineage automatically so when an alert fires you can walk backwards through the pipeline and see exactly which input dataset, feature materialization, and model version produced it, and each node is unit-testable in isolation. That last point is the one that matters most for security, because detection-engineering code that's been through a Kedro refactor tends to have meaningfully higher test coverage than the equivalent notebook-and-cron sprawl, and the production deployment story improves with it. The natural question is "why not use Airflow," and the answer is that Airflow is the dominant orchestrator for batch ETL and deserves to be, but the place it doesn't fit cleanly is the ML-development inner loop where a data scientist is changing feature logic, retraining, evaluating, and redeploying multiple times a day. Kedro is built around that inner loop, so the typical mature pattern is to develop the pipeline in Kedro and deploy it to Airflow (or AWS Step Functions, or Kubeflow) for scheduled production execution, the two complementing each other rather than competing.

Kedro adoption in security specifically is rare but not nonexistent. Two security data-engineering teams I've talked to (financial services and technology, both anonymized) migrated detection-pipeline code from manual Python scripts to Kedro and reported faster deployment, higher test coverage, and better lineage for incident-response forensics. Both also flagged the same thing: the learning curve is real and the data-catalog concept is the part that bounces people, so a team that commits without engineering buy-in tends to abandon the Kedro work partway through.

One argument for feature stores in security that I do find genuinely persuasive is the interaction with OCSF (Open Cybersecurity Schema Framework). If your authentication, network, and process telemetry are normalized to OCSF at ingestion, your feature definitions stop being vendor-specific. A failed_logins_24h feature is "count where class_uid = 3002 (Authentication) and status_id = 2 (Failure) in the trailing 24-hour window," which is one definition that works across CloudTrail, Azure AD, Okta, Windows Event Logs, and any other authentication source you normalize.

Without OCSF, the same feature needs ten different per-source implementations because each vendor names the outcome field differently and encodes "failure" with a different enum value. The practitioners I've talked to who are running OCSF-normalized ML pipelines report something like 50–70% reduction in feature-engineering effort once the OCSF mapping is paid down. I want to flag the sample size on that number: two organizations, both with mature OCSF adoption and a self-selection bias toward teams who would talk to me about it. The directional claim, that OCSF collapses per-source feature work, is sound. The exact percentage is more uncertain than the number suggests. (I cover the upstream mapping work in LLM-assisted OCSF mapping.)

The complementary observation is that without OCSF, a feature store is partially fighting the wrong fight. If your feature definitions are still vendor-specific underneath the store, you've centralized the symptom (duplicate code in eighty model repos) without centralizing the cause (vendor-specific schemas at ingestion). The combination that pays off is OCSF normalization in the route layer together with feature-store centralization in the ML layer, because either one on its own only gets you partway.

Because the evidence gap means a buyer has to do more of the validation work than usual, here is the short list of questions I'd put to anyone selling or recommending the feature-store pattern in security:

• Show me one named production deployment of a feature store in a SOC or detection-engineering team. If the answer is fraud detection, that's adjacent but not the deployment. If the answer is a vendor case study without a customer name, that's marketing.
• Show me the point-in-time correctness implementation. This is the place hand-rolled feature pipelines most often go subtly wrong. A vendor or team that can't walk you through how they handle it is selling you a feature store that hasn't earned the name.
• Where's the OCSF normalization layer? If features are still vendor-specific underneath, the feature store is centralizing the symptom and not the cause. The combination is what pays off.
• What's the operational cost of materialization? Modeled cost from list pricing is a starting point. Measured cost from a real deployment at your scale is the answer that matters.
• What's the failure mode when the online store goes down? Redis is reliable but not infallible. The detection pipeline's behavior when feature reads fail (fail-open, fail-closed, fail-stale) needs to be a deliberate design decision, not something that comes up during an incident.

A vendor who answers all five well has earned a closer look, and one who can't isn't disqualified so much as asking you to do the validation work yourself, because Feast and Kedro do production work in adjacent domains and the security application is a sound architectural hypothesis that stays a hypothesis until more SOC teams put it into production and publish what they learn.

The MLOps tools assume a data platform underneath them. For a security team running an Iceberg lakehouse with a query engine (StarRocks, ClickHouse, Trino, or DuckDB) and a catalog (Polaris, Unity, Glue), the integration points are straightforward:

• Jupyter to Iceberg. DuckDB's iceberg_scan() reads Iceberg tables directly from notebooks. PySpark or Trino's Python client work for larger windows. SQLAlchemy connectors give SQL access to ClickHouse and StarRocks for engines that don't speak Iceberg natively. The Arrow plus ADBC path is the columnar-native version of this, and removes the row-to-column serialization tax on result sets.
• MLflow artifact storage. Point MLflow at the same object storage that backs your Iceberg tables. The PostgreSQL backend for the tracking database can co-locate with your catalog's database to reduce operational surface.
• DVC remote storage. Same object storage, different prefix. When you need to version an Iceberg-derived training dataset, the DVC metadata file captures the Iceberg snapshot ID alongside the file hash so the lineage is recoverable.
• Great Expectations against OCSF tables. The framework's SQL connector runs assertions against any engine that speaks SQL. The most valuable assertions are at the OCSF-normalized layer: required fields present, expected categories present, time windows current. Schema-drift detection at this layer catches a useful share of the silent-detection-failure problem.
• Feast against Iceberg. Feast can use Parquet on object storage as the offline store and a separate online store (Redis, DynamoDB) for serving. The feature definitions point at OCSF-normalized tables, which means the feature layer composes with the schema standard rather than fighting it.

The composability that matters: Iceberg as the table format, OCSF as the schema, Arrow as the in-memory format, and a query engine of your choice, none of which require you to commit to a particular MLOps tool. You can swap MLflow for ClearML without re-architecting the data layer. That's the same argument I make for Iceberg over Delta in the table-format piece, applied one layer up.

Four moves I'd actually recommend, ordered by how cheap they are to execute:

• Adopt Jupyter for one hunt this week. Pick a hunt campaign you already know the answer to. Document it in a notebook end-to-end: query, filter, chart, narrative. Commit it to a Git repo. Have a teammate review it. That single exercise produces the template for every subsequent hunt and exposes the rough edges (data access, library installs, kernel choice) on a low-stakes problem rather than a live investigation. Do that three or four times before reaching for MLflow, because you won't feel the need to compare variants until you've already started generating them.
• Treat Great Expectations as the second adoption, not the fifth. Pick the three log sources your detection rules depend on most. Write a minimal expectation suite for each: required fields present, freshness within the expected window, distinct values inside the expected set. Route failures to the channel your team actually monitors. The cost of building this is hours; the cost of a silent detection failure can run into weeks of adversary dwell time.
• Defer experiment tracking, data versioning, and feature stores until they earn their keep. The trap with MLOps tooling is adopting it all at once because the ecosystem is well marketed. The marketing is mostly for ML platform teams shipping models, not for hunters documenting hypothesis-driven work. Adopt MLflow when you have ten variants to compare and a spreadsheet that has fallen out of date. Adopt DVC when you need to revalidate against bit-identical data. Adopt Feast and Kedro when you have more than ten supervised ML models reading the same features. Not before.
• Measure precision and recall on the hunts you ship. This is independent of any tool on this list, because a hunt that ships a detection rule without a precision number tends to produce alert noise, while a hunt that ships with measured precision and recall against a labeled or red-team-validated dataset has the property that makes it promotable to automation later. The MLOps tooling exists to make this discipline easier, so it is worth adopting, but it does not substitute for measuring in the first place.

The reframing I started with is the one I want to land on, which is that a mature threat hunter is doing data-science work whether they call it that or not, so the MLOps tools are for the role you already play, with better instruments, rather than for some different role you'd have to become. Start with the instrument that costs the least and pays back the fastest (Jupyter for hunt documentation) and let the rest of the toolchain earn its place as the discipline matures, with the feature store at the far end of that ladder where only a small fraction of security teams have any business standing today.