← All use cases

Dependency work is delivery work. A version bump can change security posture, licence obligations, runtime behaviour, or all three. Farna Control gives teams a governed place to route that work instead of treating it as an untracked maintenance task.

What Farna Control governs today

A pipeline can receive dependency work through a webhook, an agent signal, or another configured trigger. An agent can inspect repository files, issues, pull requests, and CI results through the connectors you configure, then produce a proposed change or review result. Typed schemas, evaluation gates, and human approval gates can decide what happens next. Each run keeps its inputs, outputs, decisions, and final artifact in the run record.

Farna Control does not ship a dependency scanner or licence database. The checks still come from the tools your team selects, such as a package manager, scanner, or CI job. Farna Control governs the handoff and records the result; the connected tool remains authoritative for its findings.

A controlled update path

A dependency workflow can read a report, classify the change, open a pull request, wait for CI, and pause for review before merge. A licence workflow can send a new dependency or licence finding to the same review path. The exact write and merge steps depend on the connector and permissions you bind.

This separation keeps the claim honest: Farna Control provides the delivery governance, while your existing security, package, and licence tools provide the domain checks.

Connector-dependent by design

GitHub and GitLab repository connectors support the code-host operations described on their use-case pages. CI-runner dispatch is in development, so a pipeline can observe configured CI results today, while starting a CI-runner job from a pipeline node remains a planned connection for those runner types.

Where to go next