Security Remediation Workflows

Security findings do not become safer because they arrive in a different queue. The useful control is a repeatable path from finding to fix, with the right checks and a clear decision before the change reaches a protected branch.

Bring the finding into a governed run

A webhook or configured connector can start a Farna Control pipeline with a security finding. The pipeline can validate the input, ask an agent to assess the affected code, and use the tools you bind to read issues, files, pull requests, and CI results. A schema can require the finding, repository, severity, and remediation context before the run continues.

Farna Control does not replace a vulnerability scanner, secret scanner, or security case-management system. Those systems remain the source of the finding. Farna Control governs the work that follows and keeps the run-level record.

Put review before delivery

A remediation pipeline can open a pull request, run the checks available through your connectors, and pause at a human-in-the-loop gate before merge or release. The reviewer sees the artifact and upstream context. The decision, the checks, and the final result stay with the run's versioned snapshot and append-only audit record.

The workflow can also reject a proposed fix and return the finding to triage. What happens after rejection is a pipeline decision, not an automatic security promise.

Scope depends on your connectors

The repository, issue tracker, CI, notification, and deployment actions available to a remediation workflow depend on the connector instances and permissions in your Farna Control deployment. A connector does not grant access by itself. It uses the credentials and scope you configure.

Where to go next

• What Farna Control Does With GitHub: pull requests, issues, and repository access
• Govern Coding Agents Across Teams: roles, scopes, and approval boundaries
• Human-in-the-Loop: approval and rejection gates