nano SIEM
Settings

Detection-as-Code Push Targets

Connect your GitHub repository so nano's AI tuning opens pull requests for review instead of changing rules in place

Detection-as-Code Push Targets

If you manage your detections as code in a Git repository, nano can send its AI-tuning suggestions back to that repository as pull requests instead of editing the rule directly in nano's database. Your team reviews the PR like any other code change; when you merge it, your detection-as-code pipeline redeploys the rule to nano.

This is the reverse of nano's rule-repository sync (which pulls community rules into nano). A push target is write-only — nano never reads rules from it. It exists purely so AI tuning has somewhere to open a PR.

Prerequisites

  • A GitHub repository (on github.com) where your nano detections live as code.
  • A fine-grained Personal Access Token scoped to that repository with:
    • Contents — Read and write (to commit the tuned rule file to a branch)
    • Pull requests — Read and write (to open the PR)
  • The detection_code_targets:manage permission in nano (granted to the Admin role).

Step 1 — Create a fine-grained PAT

In GitHub: Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token.

  • Repository access: Only select repositories → choose your detection-as-code repo.
  • Permissions: set Contents and Pull requests to Read and write.
  • Set a sensible expiry and copy the token — you'll paste it into nano once and never see it again.

Step 2 — Add the push target in nano

Go to Repositories and open the Detection-as-Code push target panel. Add a target:

FieldMeaning
NameA label for this target.
Repository URLhttps://github.com/your-org/your-detections.
Base branchThe branch PRs open against (default main).
Path templateWhere the rule file lives in the repo. {rule_name} is substituted per rule — default detections/{rule_name}.yaml.
GitHub tokenThe fine-grained PAT from Step 1 (write-only).

Click Test connection. nano verifies the token can read the repo and has Pull requests: write. Fix the token scopes if the check reports read-only.

Step 3 — How a tuning PR flows

When AI tuning produces a query change for a rule with a push target configured, nano:

  1. Creates a branch off your base branch (e.g. nano-tuning/windows_failed_login-3f2a1b0c).
  2. Commits the tuned rule to the templated path — preserving your existing frontmatter.
  3. Opens a pull request whose body carries the tuning rationale, a confidence score, a change summary, and a diff of the old vs. proposed query.
  4. Marks the proposal PR opened in the AI Tuning queue, with a link straight to the PR.

The same thing happens when an analyst clicks Approve on a proposal in the tuning queue — nano opens the PR rather than applying the change to the database.

detection_rules ──AI tunes──► pull request (your repo) ──you review + merge──►
   your DaC pipeline redeploys ──► rule updated in nano

Step 4 — Review and merge

Review the PR like any other change. Merge it to accept the tuning; close it to reject. Your detection-as-code deployment pipeline (the same one you already use to ship rules to nano) picks up the merged change and redeploys the rule.

Notes and limits

  • github.com only in this release. GitHub Enterprise Server support is planned.
  • Query tuning only. Hint-only and silent-rule suggestions still use nano's in-app review; only query changes map to a code diff worth a PR.
  • Admin-gated. Managing push targets and their credentials requires detection_code_targets:manage.
  • One active target. If several targets are enabled, tuning uses the most recently updated one.
  • Token storage. The PAT is encrypted with AES-256-GCM and is never returned by the API — the UI only shows whether a token is configured. Paste a new token to rotate it.
On this page

On this page