WorkspaceTalon Studio v1.0.2-beta

Git & YAML

Every workspace is a real Git repository: detections as YAML, history you can diff, and an optional mirror to GitHub, GitLab, Gitea or Azure DevOps.

Git is canonical

A workspace is not a database row with a Git export bolted on: it is a Git repository, one per workspace under /data/repos. Committed files are the source of truth for content; when a commit lands (a merge, a pull from a mirror), Talon hydrates the database from it. That inversion is what makes detection-as-code real: content is versioned, diffable and reproducible.

Content is text. Detections, sourcetype metadata, deployment targets and automations are plain files, reviewable in a diff and portable to any Git host.

Every content change is a commit. Commits and merges are attributed to the person who made them, so the history is the audit trail for content.

Secrets never land in YAML. Connection and target credentials are encrypted in the database, never committed.

Not everything is in Git. Users, credentials, change-request approvals and discussion, and validation and run history live only in Postgres, so back up the whole /data volume, not just the repositories.

The exact path is <GIT_STORAGE_PATH>/<orgId>/projects/<workspaceId>, namespaced by organisation. The image sets GIT_STORAGE_PATH=/data/repos; outside the container it defaults to ./storage/repos. Writes to one workspace repository are serialised through a repository lock, so two concurrent saves cannot race the same Git index.

Repository layout

Each workspace repository follows a predictable structure, so the same layout works whether Talon reads it or you clone a mirror:

workspace repository layout

# one Git repo per workspace, under /data/repos

Talon/workspace.yaml     # manifest: name, SIEM types, require-CRs flag, SOC, Claw autonomy

Talon/detections/        # <technique>_<name>.yaml, one per detection

Talon/streams/           # sourcetype metadata from your SIEM

Talon/targets/           # deployment targets (no credentials)

Talon/skills/            # workspace house skills for Talon Claw

Talon/deployments/       # generated, versioned SIEM release artifacts, one folder per SIEM

agents/skills/           # Talon Flow automations

agents/skill-templates/  # saved Talon Flow templates

New workspaces use this nested layout; workspaces created before it keep their detections in detections/ at the repository root. A detection YAML carries its metadata (severity, MITRE mapping, data sources, false-positive notes, tests) and a queries block with sigma, splunk, sentinel, elastic and yara_l entries: the same file the release pipeline converts on deploy.

Branches & history

main

What ships. Engineers can commit to it directly unless the workspace's Require change requests setting is on; then only workspace owners (and org admins) can, and everyone else works on a branch.

branches

Each branch is backed by a change request. New branch… creates a draft change request on changes/<id>-<name>; agent work gets agent/<name>-<id>. A merged branch is deleted.

commits

Written when you commit from the workbench and when a change request merges: one merge commit per change request, attributed to the person who merged it, with a Co-authored-by trailer when an agent wrote the change. Merging re-validates the merged detections.

Tip

Because the repository is canonical, you can read its history with plain Git: git log on a detection file shows every change, author and merge. Mirror the repository to your own Git host (below) to browse it there, or run CI against it.

Branch-scoped visibility

A detection committed only on another open change request's branch is hidden from the list while you view a different branch. Talon works this out by diffing tracked detection YAML per Git ref, not from a database flag.

Mirroring to a Git host

Talon Connect → Source Control mirrors a workspace to a repository on GitHub, GitLab, Gitea or Azure DevOps over HTTPS. Setting it up needs the workspace owner role; pushing and pulling need engineer. The full walkthrough is in Source Control.

Repository URL, branch

The HTTPS URL of the remote and the branch to mirror (main by default).

Access token

A personal access token for the host, encrypted at rest (AES-256-GCM) and never returned by the API.

Auto-push on merge

Pushes main to the remote whenever a change request merges or you commit to main.

Enable pull

Allows pulling remote changes back. A pull fast-forwards only: conflicts are reported, never auto-merged, and the workspace must have no uncommitted changes.

Webhook (optional)

A payload URL and secret to configure on the host, so a push there triggers a pull. Signatures are verified for GitHub, GitLab and Gitea; Azure DevOps webhook signatures are not supported.

TALON_ALLOW_PRIVATE_GIT_HOSTS

Set to true to allow a Git host on a private or internal address, which is refused by default.