chronicle detection-rules is a starter set of YARA-L rules for Google SecOps

What the repository is, and what it is not

The repository contains example YARA-L rules and dashboards for use within Google Security Operations. The distinction the README draws first is the important one. These rules are distinct from Google SecOps Curated Detections, which are developed by Google Cloud Threat Intelligence and designed to generate detections and alerts that are highly actionable. Curated Detections are available to Google SecOps customers with an Enterprise license or higher. So what this repository offers is the opposite trade: rules and dashboards you can read, copy and adapt, at no licence tier requirement, but with no claim to the tuning and actionability of the vendor's own set. The deployment advice follows directly. Before deploying any rules, using the SecOps test rule functionality is considered a best practice, and it gives you the opportunity to tune rules to your environment before creating alerts for them. A YARA-L rule that matches on an environment-specific artefact will generate noise, and a noisy rule trains your analysts to ignore the alert channel.

The two directories: rules and the content manager

The repository layout is a table with two rows, and it maps onto the two things you do with detection content. The first is the rules directory, specifically rules/community/, which holds YARA-L rules created by members of the Google SecOps team and the user community. The second is the tools directory, specifically tools/content_manager/, which is a CLI tool used to manage rules and other content via the SecOps REST API. The Getting Started section then describes the two workflows in order. The manual path is to create rules within your SecOps instance using the Rules Editor, where you simply download the rule from the repository and copy the content of the rule to the rules editor when creating a new rule, with detailed instructions available in your SecOps instance under documentation. The automated path is to use the rule manager tool, with its documentation and tutorials, to implement a Detection-as-Code pipeline for managing rules over the REST API. The releases listed for the repository are all content-manager releases, v1.0.7 on 2025-11-12, which added support to manage saved searches via the content manager, v1.0.6 on 2025-06-10, which initialised default directories and files, and v1.0.5 on 2025-06-09, which moved the creation of initial files and directories from __main__ to __init__. Those release titles say something useful about where the work has been going.

Importing the dashboards

Dashboard YAML files can be imported into Google SecOps dashboards using the Add and then Import Dashboard capability found next to the Personal Dashboards or Shared Dashboards section of the interface. The README states the intent plainly: to provide sample dashboards that can serve as templates, inspiration or starting points for your own dashboards, and that they can be modified as you see fit. That last clause is the one to hold on to. A dashboard dropped in unchanged is a dashboard with someone else's query windows, someone else's default time ranges and someone else's idea of what a detection analyst should be looking at. The value is in the structure and the saved search logic rather than in the chart. The fact that the content manager gained the ability to manage saved searches via the content manager in v1.0.7 fits with this, because a dashboard is a saved search and a chart, and a Detection-as-Code pipeline that cannot move saved searches is a pipeline that leaves your dashboards to be edited by hand in the UI.

How to contribute, and the style guide that governs a rule

Contributions are welcome, and the README says example contributions include new rules and updates to existing rules, pointing to the contribution guide in CONTRIBUTING.md. There is a second document that matters more for anyone writing a rule rather than submitting one. The style guide for authoring YARA-L detection rules lives in STYLE_GUIDE.md at the repository root. A style guide for detection rules is a different thing from a style guide for code, because a detection rule is read by other people who will extend it, and the decisions about what to match on and how to name it determine whether the next person can tell what it does. The top-level entries are the.github directory, CONTRIBUTING.md, LICENSE, README.md, STYLE_GUIDE.md, the rules directory and the tools directory. The primary language of the repository is Python, which reflects the content manager rather than the rules themselves.

The YARA-L and UDM resources the project points at

The Useful Resources section is a curated reading list and it is the most useful thing in the README for someone learning to write rules for this platform. For the language there are links to the overview of the YARA-L language, the YARA-L 2.0 syntax documentation, and a page on monitoring events using rules. For data there is the Unified Data Model usage guide and the Unified Data Model field list, and the UDM is the schema that your rules query against, so the field list is what you check when a rule does not match. The UDM entries are what make or break a rule, and they are also where a version mismatch bites, because a field that exists in your data source does not necessarily exist in the UDM version your tenant exposes. There is also a link to example code for interacting with the Google SecOps API, pointing at the chronicle/api-samples-python repository and its detect/v1alpha directory, which is where to look if you are writing detection-as-code tooling rather than a single rule.

Where these rules are the wrong choice

Three limits. The first is that the rules are examples. The repository says so in its opening description and again in the curated-detections comparison, and the practical consequence is that a community rule written for one environment may key on artefacts that do not exist in yours, so it never fires, or on artefacts common enough that it fires constantly. The README's own advice to test and tune each rule before creating alerts is the mitigation, and it is manual work per rule. The second is the dependency on the platform being Google Security Operations. YARA-L is not a portable rule format, the rules query the Unified Data Model rather than raw logs, and the management tooling talks to a specific REST API. If your detection stack is not SecOps, these rules do not transfer, and you would need to rewrite the matching logic against whatever schema you have. The third is the scope of what is here. There is no mention of tuning, suppression, severity, alert routing or coverage measurement, and there is no CI for the rules themselves in the repository layout, so a rule that stops matching after a schema change is caught by a human, not by a test. The value is as a source of patterns and starting points, and as a demonstration of how the content manager can drive a detection-as-code pipeline for a specific cloud product.

Editorial conclusion

Adopt this repository if you run Google Security Operations and want working YARA-L examples and dashboards to adapt rather than write from scratch. Skip it if you need production-grade detections, because the README is explicit that these are examples and distinct from Google's Curated Detections. Before you alert on any of them, run each rule through the SecOps test rule function and tune it, since the README calls that a best practice.

Frequently asked questions

Official sources

1. chronicle/detection-rules on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases