Detection as code (DaC) is a powerful way for security teams to streamline rules development, automate threat detection, and respond to attacks with greater speed and precision. The DaC approach applies formal software development practices to write, manage, and deploy rules for detecting security threats.
With traditional approaches, a security analyst must manually configure rules in tools such as a SIEM platform. With DaC, the detection logic is written, stored, and versioned like any other software code. DaC is also CI/CD-driven, meaning it uses pipelines for testing, validating, and deploying consistently across multiple platforms and environments.
Chad Cragle, CISO at Deepwatch, said DaC integrates development practices, version control, peer review, and automated testing into threat detection. The main advantage, he said, is that DaC ensures that detection logic evolves with changes in infrastructure and attacker behavior. Detection logic can be quickly updated and redeployed through automated pipelines, in a context-aware and risk-aligned manner, he said. "It allows detection logic to be managed like code, ensuring scalability, consistency, and rapid adaptability."
"This bridges the gap between security and development by allowing both teams to operate at a similar pace and integrate detections into the software delivery lifecycle," said Tim Peck, senior threat researcher at Securonix.
Here are five ways security teams can harness DaC to enhance the speed, accuracy, and scalability of real-time threat detection.
[ Get White Paper: Modernize Your Malware Analysis: Why Binary Analysis is Key ]
First, choose the right tools and languages
When implementing a DaC capability, it's helpful to use tools and languages that are compatible with your security stack, that allow for hassle-free rules development and testing, and that enable automation and collaboration across cross-functional teams.
Jasmine Noel, senior product marketing manager at ReversingLabs (RL), said DaC is about using classic DevOps and agile software development practices and tools to create and manage threat detection rules.
"Just like software, those rules have to be developed, reviewed, tested, deployed, monitored, and improved over time."
—Jasmine Noel
Also, threats change all the time, so developing new rules and improving existing rules is a continuous process, with different people developing or updating different rules, Noel said. When developing detection rules for DaC purposes, organizations typically use languages that are structured, machine-readable, and easy to integrate with automation tools. Popular choices include YAML, Python, and JSON because of their compatibility with automation pipelines, ease of collaboration, and scalability.
Malware analysts at RL use YARA to create detection rules, Noel said. Unlike the general-purpose programming languages such as Python and Java that developers tend to prefer, YARA is a domain-specific language tailored for security researchers to define signatures that detect malicious files or behaviors.
Cragle said integration and automation are key DaC elements.
"Detection rules should be easy to test, deploy, and enrich, ideally with threat intel and telemetry, without manual intervention. CI/CD compatibility and Git-based workflows are must-haves."
—Chad Cragle
Why having the right tools matters
It's best to choose tools that integrate directly with your existing detection stack and detection posture management platforms. Ensure that your team can set up and deploy detection rules in a platform-agnostic manner so they work across SIEMs and other threat detection mechanisms. The best tools support open formats, API-driven integrations, and automation, Cragle said.
Michael Mumcuoglu, CEO and co-founder of CardinalOps, said to look for tools that enable detection rule mapping. Also, make sure they support automation and capabilities to detect broken rules and can integrate with threat intelligence feeds and platforms.
"Integrating with threat intelligence helps to keep your detection pipeline up to date on the latest and most relevant threats to your organization. Visibility into your existing detection coverage can be a critical component for prioritizing the development of new detections, especially when mapped to a framework such as MITRE ATT&CK."
—Michael Mumcuoglu
Securonix's Peck said to pick tools that are compatible with your detection platform and development teams.
"Sigma would be a great start, as it is a vendor-agnostic rule writing format. Then use tools like sigmac, GitHub Actions, and Terraform for deployment."
—Tim Peck
Automate with CI/CD pipelines
Deploy a CI/CD pipeline to automate testing, validation, and deployment of detection rules. A number of tools enable rules testing against sample logs before deployment, reducing false positives.
Peck said that Securonix uses Git CI pipelines to validate its YAML-based detection rules and to push them into other integrated systems that multiple teams can then use to provide feedback to help in tuning out false positives or with other issues that may arise during the validation process.
RL's Noel said to treat detection rules exactly as you would any software code and get the same types of benefits — such as collaboration, version control, and activity tracking — by using software engineering practices and tools.
"For example, RL manages our repository of free YARA rules using GitHub. Anyone with some DevOps training who looks at our repository will see all the familiar concepts — branches, commits, merges, pull requests. The main difference is the code is written in YARA instead of Python, Java, or C."
—Jasmine Noel
Moving detection logic into version-controlled Git repositories such as GitHub or Bitbucket is often a good place to start implementing DaC, Peck said. "Next, define a simple directory structure for organizing rules and use a common detection logic [such as] Sigma's YAML format or similar formats to 'codify' detections."
From there, introduce code reviews, basic testing such as rule linting, and a small CI pipeline to validate detections before they are deployed to your SIEM or detection platform. "Some validations can include YAML format checks, spell checks, and detection logic checks," Peck said.
Familiarize your security team with DevOps practices
Security teams often lack a deep understanding of modern software development practices because of the silos that have separated them for years. This gap can slow down the integration of practices such as DaC, especially in fast-paced environments, Peck said.
"I think the biggest hurdle would be the lack of development experience in security teams. Most security professionals don't have solid developer experience, so shifting into a DaC mindset could take time and training."
—Tim Peck
To overcome this, consider providing training on Git and basic DevOps concepts for security teams, Peck said. Start with low-risk rules to demonstrate value, and then work closely with DevOps to integrate detection logic into existing pipelines without overwhelming the team. "Skills commonly found in CI/CD pipelines are crucial. Some of these include coding in Python, Git concepts, and Docker," Peck said.
The shift to DaC is as much cultural as it is technical, said Deepwatch's Cragle. Traditional security operations centers focus on alert triage, not engineering. Embracing DaC requires adopting software development practices such as version control, testing, and peer review, he said.
Start small
Starting small when implementing DaC is wise because it allows security teams to test and refine their processes on a manageable scale and reduces the risk of errors, the experts said.
"Start small with impactful rules, implement lightweight governance, and demonstrate early wins through reduced noise or quicker coverage for new threats."
—Chad Cragle
Noel recommends getting started on the path to DaC by using tactics that worked for DevOps adoption because you'll face the same types of challenges and resistance to change: Start with small projects or a few individuals who want to learn and change. Borrow or steal an experienced agile or DevOps practitioner to coach your security team on the concepts and skills involved and use their help to create a successful workflow that can be automated with tech, then use that success to encourage broader adoption, Noel urged.
She suggests focusing on a few high-priority or high-visibility use cases, such as code for detecting failed logins, so that your security team can build confidence and ensure that rules work effectively. Scale up gradually from there.
CardninalOps' Mumcuoglu said it's also a better approach to refactor existing detection rules than to start from scratch, which can be overwhelming and carries the risk that security teams might miss valuable legacy logic.
"Existing rules are often valuable but undocumented or poorly tuned. Refactoring them into structured formats improves quality and builds confidence without starting over."
—Michael Mumcuoglu
Also consider implementing a cross-functional capability, Cragle said, with, for example, detection engineers managing rule logic, threat intel teams offering behavioral context, and DevOps or SecOps engineers developing automation. Such collaboration is vital for scale and speed, he said.
Start by building the foundation: Treat detections as code, store them in Git, standardize formats, and integrate CI/CD for validation and deployment. Map detections to ATT&CK for visibility, and ensure that each rule is versioned, testable, and documented. "Begin with a small set of high-impact detections, especially those generating noise, and refactor them into modular logic," Mumcuoglu said.
