A software factory is a repeatable system of people, practices, reusable components, and automation that moves software from request to release and improves each cycle. Ask a platform team, a defense contractor, and an AI startup what a software factory is, and you will hear three answers. The platform team describes golden paths and self-service pipelines. The contractor describes a DevSecOps program that meets Department of Defense criteria. The startup describes agents that turn tickets into pull requests overnight. All three describe one idea at different points in its history: software delivery that runs like a production line, with inspection at every station.
What is a software factory?
A software factory is an operating model for building and shipping software consistently. VMware calls it "an organized approach to software development," in which teams build and update software along a repeatable path. A working software factory definition has four parts:
- People who own decisions: what to build, what counts as done, and what ships.
- Practices that every team follows, such as code review, testing standards, and release rules.
- Reusable components, including service templates, shared libraries, and pipeline recipes, so teams stop rebuilding the same setup.
- Automation that builds, tests, packages, and deploys each change and gives the team operational feedback.
The term can name an organizational capability, such as a platform group or a DevSecOps program, or the development environment that group provides. Neither meaning requires AI. Many software factories run on human developers, shared templates, and CI/CD, and AI agents are a newer addition to the production line.
Factory software development borrows its metaphor from manufacturing, and the metaphor has limits. A car plant stamps identical parts. A software team builds something different with each change, requirements shift mid-stream, and people still make judgment calls the line can't make for them. The factory standardizes the path so that judgment goes where it matters.
How a software factory works
A software factory connects six building blocks into one loop: shared templates and libraries, source repositories, self-service environments, automated builds and tests, delivery tooling, and operational feedback. Each change enters as a request, moves through the same stations, and leaves evidence behind at each one.
Follow one change through the factory (illustrative example)
A team needs to add cursor-based pagination to a public orders API, so partners can page through large order histories. This example is hypothetical, not a customer case.
At stage 3, the dependency scan flags a known vulnerability in the new pagination library, and the vulnerable function sits on a path the API calls. CI fails the build. The change returns to stage 2, where the developer moves to a patched version, and the tests and scans run again. A green pipeline at stage 3 then means something: the change met the criteria and carries no known reachable risk from that library.
People own the decisions the line can't make. The product manager and tech lead own acceptance criteria. A security or engineering lead owns exceptions, such as accepting a risk with a deadline to fix it. The release owner decides what ships and when.
Software factory vs. DevOps, CI/CD, and developer platforms
A software factory combines DevOps practices, CI/CD automation, a developer platform, and coding tools into one operating model. These terms describe parts of the whole, not rival choices.
Buying a pipeline tool or a developer platform does not create a software factory. The factory exists when an organization agrees on the path, the owners, and the evidence each change must carry. Plenty of teams without the label already automate builds and reuse code. The factory model makes that work consistent across teams and measures it as one system.
Where AI agents fit
AI agents join a software factory at the implementation station and spread outward from there. An assistant suggests code while a developer types. An agent with bounded autonomy takes a ticket, writes the change, generates tests, responds to failed checks, and opens a pull request inside limits the team sets. Some teams call this arrangement an agentic operating model: agents do more of the hands-on work, and people keep the gates.
One vendor demonstration, Software Factory, shows agents that plan work, create issues, set up a testing framework, and automate pull request review. Treat its dashboard figures as the vendor's own report, not proof of results for other teams.
Agent actions need different controls than agent code
Agents add a second thing to secure. Code review checks what an agent wrote. It can't check everything the agent did along the way. Two illustrative scenarios show the difference:
- A package install. The agent runs
npm installon a package name it invented, and an attacker has already registered that name. The install script runs on the build machine before any pull request exists. The final diff shows one new lockfile entry, not the script that ran. - An insecure API change. The agent adds the pagination endpoint from the example above but skips the authorization check the old endpoint had. That flaw lives in the code, so review, tests, and static analysis can catch it.
The first scenario calls for controls on actions: what an agent may run, read, install, or call, which the team enforces while the agent works and logs for later review. The second calls for controls on output: review, tests, and scanning. Endor Labs' work on coding agent governance draws the same line between consequential agent actions and vulnerabilities in generated code.
Agents don't remove the need for people. Someone still owns the architecture, writes acceptance criteria, approves exceptions, and answers for what ships.
How security fits into the factory
Security in a software factory works as a stream of evidence that travels with each change, not a scan at the exit. Each station from the walkthrough produces its own:
Two kinds of evidence answer two different questions. Reachability evidence asks whether your code can reach a vulnerable function, using call paths and data flow, so teams fix the risks that matter first. Signing evidence asks whether an artifact is the one your pipeline built and whether anyone changed it since. Endor Labs provides both: full-stack reachability analysis for prioritization and artifact signing for identity and integrity. Neither proves software has no vulnerabilities.
A software bill of materials works the same way. It records what components a release contains. It does not certify that those components are safe.
Automated checks inform decisions and drive remediation. They can't guarantee that a release is secure or compliant, which is why the factory keeps people at the exception and release gates. For the wider program around these controls, see our guide to application security across the SDLC.
Benefits, trade-offs, and signs it is working
A software factory can cut repeated setup work, make delivery more consistent across teams, and give new engineers a clear path to their first release. Those gains depend on how well the standard path fits the work. The model also brings costs:
- Platform upkeep. Templates, pipelines, and shared libraries need owners and a budget, or they drift out of date.
- Brittle automation. A pipeline that fails for reasons unrelated to the change trains people to rerun it until it passes.
- Poor fit for unusual workloads. Firmware, data science experiments, and legacy systems may not fit a standard template, and forcing them in slows those teams down.
How to tell whether the factory works
Judge the factory by delivery quality, not code volume. Pull request counts, lines of code, and the share of automated steps say little about whether software reaches users and works. Pair a speed measure with a quality measure, and track both:
The first four come from DORA's software delivery metrics. Review time matters more as agents speed up implementation, because the code review bottleneck moves to the people who approve changes.
Start with one repeatable workflow, such as new API endpoints for one service. Record its baseline on these measures, run it through the factory for a quarter, and compare it against that baseline rather than against other teams. A better number shows a change worth studying, not proof that the factory caused it.
Build the evidence into the production line
A software factory earns its name when every change leaves a trail: who approved it, what checked it, what it contains, and whether the risks it carries are reachable. AI agents can speed up the line, but the evidence and the people who act on it decide whether faster delivery is better delivery. See how Endor Labs AI Code Security helps teams add reachability and signing evidence to the factory they already run.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help:
