From findings to tested fixes: Security Factory’s proposed workflow

In private preview, Security Factory connects vulnerability investigation with remediation. Approvals also depend on repository protections.

Evidence gathered during a security investigation should follow a fix through verification. That is the connection proposed by Security Factory, an offering that applies Factory’s coding agents to vulnerability analysis and remediation. The service is in private preview, available to a limited group of customers.

Findings come from tools the organization already uses to scan code, dependencies, secrets, or infrastructure. Connectors add context from software inventories, tickets, and team conversations. Before preparing a fix, the investigation is intended to establish which systems are exposed, how a vulnerability could be exploited, and what access it could enable. Carrying evidence through to the fix

A vulnerability reported in a component has different implications depending on its deployment and permissions. The provider’s example pairs an internet-facing service with an account that has excessive privileges. Examining them together is intended to determine whether compromising the service could expose the account’s credentials and, through them, other systems.

Workstreams divide investigations into specialized tasks and preserve findings, evidence, and unresolved questions. Hypotheses can be tested in controlled environments, on Droid Computers, in a sandbox, or on customer-controlled cloud infrastructure through OpenCompute.

Agents then reuse this information to modify code, update a dependency, or correct a configuration. The announced workflow includes testing the change against the conditions used to reproduce the vulnerability, then checking for regressions before preparing a patch or pull request. One agent per fix in the CVE workflow

The CVE remediation documentation describes a specific implementation. One agent periodically polls the scanner and creates a task for each fix. Another agent takes that task from triage through the proposed change and continuous integration checks.

A task can group several vulnerabilities resolved by the same change. The plan must specify the modification, potential breaking changes, its validation method, and the proposed rollback. After merging, the task waits for another scanner poll: the fix is confirmed when the finding no longer appears.

Documented sources include Snyk, GitHub Dependabot and code scanning alerts, and GitLab vulnerabilities. The workflow does not create a task for a dependency when the scanner lists no fixed version. Its automated scope therefore also depends on the information and available fixes supplied upstream. Approvals also rely on repository protections

The selected autonomy level changes whether a plan requires approval. Under the most autonomous option described, a patch or minor dependency upgrade without breaking changes can proceed without that approval; other plans still require user review. For merging, agents are instructed to wait for a human decision.

The task documentation notes, however, that Factory does not technically enforce plan or merge approval. Required reviews and blocking checks must be configured through the repository’s branch protections.

These rules are supplemented by agent execution controls, including command permissions, network restrictions, and isolated file access. The documentation distinguishes these controls from instructions given to the model, which complement them without constituting a technical barrier on their own.