[eric-forte-elastic]

Summary

Adds a new workflow called dac-vcs-rule-sync, Detection-as-Code sync to version control. With this enabled, rules tagged with vcs in a configurable space, defaulting to dev are exported through a detection-rules fork and opened as pull requests against main, with unit tests reported on the PR.

This would be used in a Kibana as authoritative or a dual sync governance model.

Given the added complexity and requirements of having a fork of detection rules with a custom rules config setup, a direct setup guide is added in the file examples/security/detection/dac-vcs-rule-sync/DEPLOY_AND_TEST.md

See example PRs generated from this workflow:

• [VCS Sync] 1 rule change(s) from space dev (vcs-sync-20260714-010450) eric-forte-elastic/detection-rules-dac-demo#14
• [VCS Sync] 1 rule change(s) from space dev (vcs-sync-20260714-011335) eric-forte-elastic/detection-rules-dac-demo#15

Note

DaC workflows in general are somewhat restricted in that they cannot interact with Github Action workflows directly as these are not present in the current version of the Github Connector. If support for these are added, the workflow can be notably simpler with a similar result.

[semd]

Thanks for this — the workflow itself is well put together, and DEPLOY_AND_TEST.md is genuinely useful for something with this much setup. A few things before it can land.
Needs a rebase. The branch conflicts with main: examples/security/detection/README.md has moved since you opened this.
The companion GitHub Actions file will break example validation. examples/security/detection/dac-vcs-rule-sync/github/dac-vcs-rule-sync.yml is a GitHub Actions workflow, not an Elastic workflow, but it lives under examples/. We're about to land workflow validation in CI (#47), and its file discovery walks examples/ recursively picking up every .yml/.yaml, with no exclusion mechanism — so this file would be validated against the Elastic workflow schema and fail the build. Options, in rough order of preference:

• Inline it as a fenced block in the README (it's documentation for the user's own fork, not something we execute).
• Rename it to a non-YAML extension, e.g. dac-vcs-rule-sync.yml.example.
• Move it outside examples/.
  Happy for you to pick — the only hard constraint is that it must not be discoverable as a workflow YAML. I'll raise the general gap on [chore] Add workflow validation step in CI #47 as well, since this is the first non-workflow YAML under examples/ and won't be the last.
  github.callTool usage is fine. I checked the connector spec: the GitHub connector's actions are all read-oriented (searchPullRequests, pullRequestRead, getFileContents, listCommits, …) with callTool as the only write escape hatch, so there's no dedicated step you should be using instead. Your note about GitHub Actions not being reachable is accurate. It's worth filing a connector feature request for the write actions this needs (create branch, commit file, open PR) so the workflow can be simplified later.
  Directory layout, minor. examples/security/detection/ is otherwise flat, and this introduces a nested directory plus a github/ subdirectory. I think it's justified given the two companion docs, and there's precedent for flat companion markdown (siem-rule-tuning-agent.md), but flagging it so we make that call deliberately rather than by accident.

[talboren]

@eric-forte-elastic this looks quite old and I'm not sure if it's still relevant? if it is - do you mind resolving the conflicts and re-opening?