security_content is Splunk's open repository of analytic stories, detection searches and response playbooks, maintained as code for defenders running authorized security monitoring operations.
| Tool | splunk/security_content — Splunk's official open-source detection content repository with analytic stories, searches and playbooks |
| Category | Detection engineering / SIEM content-as-code |
| Primary Use | Deploying, customizing and version-controlling detections/, baselines/ and stories/ mapped to MITRE ATT&CK in a Splunk deployment |
| Safe Use | Purely defensive content for authorized security teams; designed for detection engineering, lab validation via attack_range, and monitoring of owned environments |
| Telemetry Note | This is detection content itself — defenders observe its effect as scheduled Splunk searches and alert actions defined under deployments/, not as attacker telemetry |
splunk/security_content is the canonical detection content repository published by the Splunk Threat Research Team, and it occupies a distinctive niche in the open-source security ecosystem: it is not an offensive tool at all, but a fully versioned, schema-validated corpus of defensive analytics. The repository, currently around 1,700 stars and written primarily in Python, is organized around what Splunk calls Analytic Stories — security guides that document tactics, techniques and procedures (TTPs) mapped to the MITRE ATT&CK Framework, the Lockheed Martin Cyber Kill Chain, and CIS Controls. Each story bundles Splunk searches, machine learning analytics and, where available, Splunk Phantom playbooks into a coherent detect-investigate-respond package.
What makes the project interesting from an engineering standpoint is that it treats detections as first-class code artifacts rather than configuration blobs. Everything lives in YML files organized into typed directories: detections/ holds the detection searches, baselines/ contains searches that must run before a detection to collect contextual data, data_sources/ documents the required TAs and Apps plus the fields a detection expects, lookups/ implements static value lists such as common ransomware extensions, and macros/ defines reusable search shortcuts like the sysmon source type. stories/ groups everything into use cases, and deployments/ carries the schedule and alert action configuration applied across the corpus.
The build pipeline deserves particular attention. The sibling tool contentctl-ng, installable via pip install contentctl-ng, is the enforcement layer: running contentctl-ng build validates every YML file against the project's JSON schemas, checking required fields, data types and internal consistency before an app can be packaged. The schemas themselves live in the /schemas directory, covering everything from EventBasedDetection.schema.json to Story.schema.json, FileBackedMacro.schema.json, CsvLookup.schema.json, Baseline.schema.json, Playbook.schema.json and DataSource.schema.json. This is textbook detection-as-code: schema validation, CI gates (a build.yml GitHub Actions workflow runs on the develop branch), and reproducible packaging into the DA-ESS-ContentUpdate.spl artifact distributed on splunkbase and the GitHub release page.
For detection engineers who want to contribute or customize, the onboarding path is deliberately smooth. After git clone https://github.com/splunk/security_content.git, the recommended workflow is a python3.11 -m venv .venv environment with contentctl-ng and pre-commit installed — the latter enforcing formatting through git hooks. The repo ships VS Code snippets in .vscode/escu_6.code-snippets with prefixes like detection_escu6, macro_escu6, story_escu6, lookup_csv_escu6, dashboard_escu6 and baseline_escu6, which expand into pre-filled YML templates inside the appropriate content directory. This scaffolding substantially lowers the barrier to authoring content that passes schema validation on the first try.
The README's recommendations section reveals a pragmatic philosophy about fork management. Teams adopting the repository as the seed of their own detection program are advised to keep the YML structure as close to upstream as possible — this eases both ongoing management and the possibility of contributing detections back via pull request. At the same time, Splunk explicitly recommends pruning: keep only the detections relevant to your organization, along with the macros/ and lookups/ they depend on, so the resulting app is self-contained and does not break on external references. That tension — fork-and-prune versus stay-close-to-upstream — is one every detection-as-code program eventually confronts, and the guidance here is honest about it.
A crucial enabler of the project's quality is its testing ecosystem. The README highlights three sister projects: the Splunk Attack Range, which builds instrumented cloud environments on AWS and Azure as well as local Virtualbox setups, simulates attacks and forwards telemetry into a Splunk instance; the attack_data repository of recorded attack datasets used to regression-test detections; and Atomic Red Team from Red Canary, whose MITRE-mapped tests provide reproducible adversary emulation. In other words, detections in this corpus are not just written — they are validated against simulated and recorded attack data before shipping, which is far more rigor than most in-house SOC content ever receives.
Coverage transparency is another strength. The README points to the research portal at research.splunk.com as the primary discovery interface, and to mitremap.splunkresearch.com under the Detection Coverage layer for a live map of which MITRE ATT&CK techniques have content. The repo badges render live detection count and coverage statistics generated from the reporting pipeline, so the numbers you see reflect the actual state of develop rather than marketing claims. For a blue team planning gap analysis, that coverage map is a genuinely useful planning artifact — it shows where detection engineering investment is dense and where the corpus thins out.
Distribution happens through three channels. First, Splunk Enterprise Security (ES) customers receive the content natively as ESCU updates through the use-case library, meaning ES deployments already run it whether they realize it or not. Second, the standalone ESCU app can be pulled from the GitHub releases page as DA-ESS-ContentUpdate.spl. Third, the git repository itself serves teams that want full control, custom builds and their own release cadence via contentctl-ng. The three-tier distribution model is well thought out: consumers get automatic updates, engineers get source access.
From a defensive tradecraft perspective, the value of studying this repository goes beyond deploying its searches. Reading the detections/ and stories/ directories is effectively a free curriculum in how a mature threat research team structures analytics: every detection carries a narrative on the adversary behavior it targets, its ATT&CK mapping, and the data prerequisites documented in data_sources/. Analysts learning SPL will find hundreds of production-grade search patterns to study, and detection engineers will find the baselines/ pattern — running a data-collection search before the detection itself — a reusable architectural idea for stateful detections in any SIEM, not just Splunk.
Governance and support are clearly defined. The project is Apache-2.0 licensed, copyrighted 2026 Splunk Inc., with contributions welcomed through documented CONTRIBUTING.md processes and issue templates routed directly to the Threat Research Team. Splunk Enterprise customers with valid support entitlements can escalate through the support portal, while the community tracks bugs on GitHub Issues and discussion in the #security-research channel of the Splunk Community Slack and on Splunk Answers.
For authorized security teams, splunk/security_content fits naturally into a purple-team workflow: emulate with Atomic Red Team in an attack_range lab, confirm the corresponding detections fire, then ship the validated corpus into production monitoring. Nothing in the repository facilitates unauthorized access to third-party systems — it is a defensive asset through and through, and one of the few places where enterprise-grade detection logic is fully inspectable, forkable and auditable by anyone.
If there is a caveat, it is operational rather than technical: adopting upstream content wholesale means inheriting schedules and alert actions defined in deployments/, which can overwhelm a lean SOC if not pruned and tuned to local data maturity. The README's own advice — validate with contentctl-ng, follow its descriptive errors, check the JSON schemas for allowed values — is the right discipline. Run it as a curated upstream you regularly merge from, not a fire-and-forget app install, and this repository becomes one of the strongest foundations available for a serious detection engineering program.
splunk/security_content.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.