Legit Security software factory security explained: SDLC discovery, CI/CD posture, attestation and where Safeguard fits (2026)

Most application security conversations are about the code and the packages. A quieter conversation is about the machinery that turns code into software: the source control system, the pipelines, the runners, the secrets those pipelines hold, the registries they publish to and the permissions in between. Legit Security calls that machinery the software factory, and it has built a good part of its reputation on research into it. Safeguard looks at the same machinery from a different side. It cares most about what comes out of the factory, whether a build is signed and provenanced, whether a vulnerable or malicious dependency went in, and whether a fix can be produced and tested.

This guide explains what software factory security actually covers, what Legit publishes about its approach, where Safeguard overlaps and where it does not, and how to evaluate any product in this area with seeded tests instead of slideware. Every Legit fact carries a source and was read on 28 Oct 2026. Where Legit does not say something, we say so.

A disclosure first. Safeguard wrote this and sells a competing product. We have tried to describe Legit the way its own team would, and Legit's research deserves real credit. If we got something wrong, write to hi@safeguard.sh and we will fix it and date the correction. For the product-level comparison, see Legit Security vs Safeguard, and for the wider category, our ASPM buyer's guide for 2026.

Key takeaways

• Software factory security has three layers: the configuration posture of the systems that build software, the integrity of what they produce, and the vulnerabilities in what flows through them. Few products are equally strong in all three.
• Legit's published strength is the first layer: SCM, CI and CD misconfiguration discovery, backed by original research on GitHub Actions, self-hosted runners and Azure DevOps, and a free open-source tool, Legitify.
• Safeguard's published strength is the second and third layers: scanning inside the pipeline, policy gates, signed attestations, hardened Gold builds and fixes.
• The right test is a seeded one. Plant a known-bad workflow, a test secret and an unsigned artifact, and see what each product says.
• Many teams will reasonably run a posture specialist next to a fix-first platform.

What software factory security means

A software factory is every system between a developer's keyboard and a running service. Source control, branch protection, code review rules, CI runners, workflow files, build caches, artifact registries, deployment tooling, the secrets and tokens passed between them, and increasingly the AI coding agents that write the code. Attackers go after this machinery because one foothold reaches many outputs. A compromised pipeline does not steal one application's data. It can change what every customer receives.

Legit's own definition, in its CI/CD security knowledge base article (25 Nov 2024), is that the practice "aims to maintain a development pipeline's confidentiality, integrity, and availability" through controls on access to code repositories, security testing, and secrets used during build and deployment. The article lists insecure code practices, weak access controls, misconfigurations, exposed secrets, vulnerable third-party dependencies and supply chain attacks as the common risks. That is a reasonable list. It maps onto three layers, and the layers explain why products differ.

Layer 1: posture of the factory itself. Are branch protections on? Is two-factor authentication enforced? Do workflows pin third-party actions to a commit? Does a workflow trigger on pull requests from forks with write permissions and secrets? Are self-hosted runners reachable from public repositories? This is configuration review across SCM, CI and CD systems, and it needs deep, current knowledge of each platform's settings.

Layer 2: integrity of what the factory produces. Can you prove which source, build steps and materials produced an artifact? Is it signed? Is there an SBOM and a provenance statement that downstream consumers can verify? This is the territory of SLSA, in-toto attestations and frameworks such as NIST's Secure Software Development Framework.

Layer 3: what flows through. Vulnerable dependencies, malicious packages, leaked secrets and unsafe code that move through the pipeline into the product. This is where scanners, reachability and fix automation live.

A buyer who says "we need software factory security" usually means one of these layers more than the others. Ask which one before you read a single data sheet.

Why this area has its own research tradition

Three publications from Legit's research team show how real the risk is, and they are worth reading whichever vendor you choose.

Self-hosted runners (6 Jun 2023). Legit scanned 3,106,445 public GitHub repositories and found 43,803 that used self-hosted runners, about 1.4 percent. The post explains why teams use them (compliance, special hardware, cost), and the risks: an inadequately secured host becoming an entry point, privileged access, poor isolation, patching gaps and, in public repositories, attackers running malicious workflows through pull requests. Its demonstration used a fork pull request that read a file on a runner. Its mitigations include runner groups, keeping self-hosted runners off public repositories, storing no sensitive material on runners and using fresh machines per job.

GitHub environment injection (18 Jul 2023). Legit reported that a workflow writing untrusted user input to the GITHUB_ENV file could let an attacker run code in a project's pipeline by opening a pull request, before any maintainer approval. The release says Legit found the issue in open-source projects from Google, names the Orbit project, reported it through Google's vulnerability disclosure program, and says Google fixed it with Legit verifying that no one had exploited it. The release warns that many other projects likely share the pattern.

Azure DevOps zero-click (30 Jan 2024). Legit described CVE-2023-36561, in which Azure Pipelines treated a pipeline-resource-triggered run from a fork as an internal build, letting an attacker run modified pipeline code and reach build secrets without any action from a maintainer. The post says researchers found over 70,000 open-source projects running Azure Pipelines on external pull requests by default, though the number truly vulnerable was smaller. It gives a timeline from report on 23 May 2023 to a Microsoft fix on 10 Oct 2023.

The State of GitHub Actions Security (post of 5 Sep 2024). Legit analyzed 2.5 million workflow files belonging to 553,000 organizations and individuals. It reports that 98.4 percent of the references used by jobs and steps did not follow dependency pinning best practice, that only 14 percent of workflows limit token permissions, and that dangerous triggers such as pull_request_target and workflow_run appeared thousands of times. It recommends continuous scanning of workflow changes.

Read these as vendor research with a commercial purpose, and also as useful data. Pinning, token scope, fork triggers, untrusted input and runner exposure are the five things to test in any product. Our own posts on GitHub Actions pinning to SHAs, GitHub Actions artifact poisoning and the GitHub Actions supply chain hardening checklist cover the fixes, and the tj-actions changed-files compromise shows the failure in the wild.

What Legit says its platform does here

Legit's platform page says the platform "unifies vulnerability discovery, contextual risk scoring, and remediation across your software factory, from code to cloud." Under "Detect risk" it lists native scanning, secrets, SAST, SCA and IaC, CI/CD protection and continuous monitoring. Under discovery it says it maps applications, repositories, APIs and cloud assets "including ownership and how each was built."

The AWS Marketplace listing, read on 28 Oct 2026, adds specifics about the factory story. It describes protecting the development environment end to end with asset and dependency inventory, pipeline flow mapping and findings consolidation from multiple AppSec tools, and automated CI/CD pipeline security with developer guardrails, plus policy testing, enforcement tracking and program metrics. The IDC MarketScape release (15 Sep 2025) lists "advanced code change management" as a capability, described as visibility and automation for material changes across the SDLC. That release is vendor-issued, so treat the description as Legit's.

The clearest public statement of scope is Legit's own comparison between its free tool and its platform, on the Legitify page. Legitify is Apache 2.0 licensed and checks GitHub (Cloud and Enterprise Server) and GitLab (Cloud and Server) for insecure configurations across members, repositories, actions and organizations, with severity, remediation steps and an OSSF Scorecard integration. It runs from a command line or as a GitHub Action. Legit's own comparison says the free tool "detects SCM misconfigurations only," while the platform covers SCM, CI, CD, package registry and pipeline risks, secrets, IaC and more, supports all major SCMs including Azure DevOps and Bitbucket, gives real-time alerts when a misconfiguration is introduced, maps to frameworks including SSDF, SLSA, SOC 2 and ISO 27001, and adds SDLC asset management, ticketing and risk ingestion. Those are Legit's statements about its own platform.

Two points deserve a plain note. First, a free, open-source scanner from the vendor is a generous way to try the idea before any purchase, and we would run it regardless of which product you buy. Second, the public pages do not say how the platform detects pipeline attacks in progress, what its supported CI systems are beyond the integration catalog, or what its rule set contains. Ask for the rule list.

Legit also offers a Software Compliance and Attestation Trust Center, launched in April 2024. Its release describes pre-built controls for major frameworks, an initial gap analysis, evidence capture and export, custom queries, alerts on out-of-compliance areas and support for the CISA Secure Software Development Attestation Form. The release does not mention SBOMs. In January 2024 Legit's blog summarized a Gartner report on software supply chain risk, noting Gartner's views on SBOM disclosure, SSDF and SLSA, and positioning the platform as helping fold supply chain risk into vendor risk assessments.

What Safeguard covers in the factory

Safeguard is a software supply chain platform, so its coverage of the factory is organized around what passes through and what is produced. The docs describe these pieces.

A pipeline step. One step in your pipeline runs safeguard ci scan. The CI/CD integration docs list setup guides for GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines, with a route for other CI systems. There is no plugin to install. Each push becomes a project version. By default the scan runs on Safeguard and covers SAST, SBOM and dependency vulnerabilities. With --local, the scan runs on your runner and only the results leave it, which also works for self-hosted and firewalled Git servers. Flags --fail-on and --fail-on-gate fail the step on a severity threshold or a policy gate.

Policies, gates and guardrails. The guardrails docs describe rules that block, warn or auto-fix, written as policies that target assets and evaluate a combined document of SBOM, vulnerability, license, signature, provenance and reachability data. Enforcement points include the IDE, commit, CI and registry. Built-in guardrails include KEV in production, a required SBOM, SLSA level 3 provenance, a license allow-list, abandoned packages, unsigned containers, typosquat detection and AI model provenance. Blocking guardrails support time-boxed exceptions that are logged, and breakglass exceptions need two-person approval. The policies and gates docs list conditions including severity, CVSS, EPSS, license, component age, maintenance and SLSA level.

Attestation and signing. The attestation docs describe attestations in in-toto v1 format: SLSA provenance v1, CycloneDX and SPDX SBOMs, a vulnerability scan and a Safeguard Review. They are signed with Safeguard's own ECDSA P-256 key held in a cloud key management service, the public key is published, and verification uses cosign commands against it. The docs map SLSA levels to build setups, for example a tamper-resistant build service for level 2 and an isolated, parameterless build such as a GitHub reusable workflow or the Safeguard runner on a dedicated VM for level 3. See also our explainers on SLSA and software attestation in practice.

Asset discovery. Safeguard enumerates repositories on GitHub, GitLab, Bitbucket and Azure DevOps, container images across common registries, packages from build outputs and lockfiles, and AI models. It infers owners from CODEOWNERS or labels, and the docs describe cross-referencing CI/CD logs to detect shadow builds, with an UNGOVERNED status for assets outside governance that can open a ticket or block a deployment.

Secrets. Safeguard is not positioned as your secrets tool. Keep your current secrets scanner alongside whichever product you choose.

A pipeline-file ruleset. The CI/CD Security docs describe five checks for workflow files: third-party actions pinned to a tag or branch instead of a commit SHA, the pull_request_target trigger, untrusted event data inserted into shell commands, write-all token permissions, and downloads piped into a shell. They cover GitHub Actions and, for some rules, GitLab CI/CD. Today, the docs list this feature as not offered in the app at the moment, with pipeline-config reviews available through a Safeguard representative. If pipeline-file posture across many CI systems is your deciding requirement, Legit is the specialist, and you should weigh that plainly.

Gold and the Package Firewall. What a factory consumes matters as much as how it is configured. Package Firewall blocks malicious, typosquatted and dependency-confusion packages at install time, and Gold supplies hardened components, described in the section on fixing without waiting for upstream below. For how the hardened builds are produced, see how the Gold build pipeline works.

Layer by layer comparison

This table covers what each vendor says publicly as of 28 Oct 2026. "Not stated" means we found nothing in the sources we could read, not that the capability is absent.

Read the first four rows together. If your gap is knowing what is configured badly across your SCM and CI estate, the evidence in this table points to Legit. If your gap is proving what a build contains and fixing what is wrong in it, the evidence points to Safeguard. Confirm the framework list in the live product for the frameworks you need.

Three attacks, two approaches

Abstract comparisons hide the difference. Here are three scenarios, and how a posture-first and a supply-chain-first product would each approach them. These describe the design of each approach, and you should confirm the behavior in a pilot.

Scenario 1: a fork pull request runs privileged workflow code. A workflow uses pull_request_target and checks out the pull request head, so fork code runs with a write token and secrets. A posture product reads the workflow file or the settings and flags the trigger and the token scope before anyone exploits it, and Legit says its platform alerts in real time when a misconfiguration is introduced. A supply-chain-first product that scans the pipeline will see what the build produced, and the documented pipeline-file ruleset has a rule for this trigger. The decisive question is detection time: does the product flag the workflow at the pull request that introduced it, or later?

Scenario 2: a third-party action is compromised. A widely used action is changed upstream, and thousands of workflows pulling by tag run attacker code. A posture product flags every workflow that uses an unpinned reference, which is the 98.4 percent figure from the research above. A supply-chain product asks different questions: which of our builds ran the bad version, what did those builds produce and sign, and which artifacts do we need to rebuild. The two are complementary. Pinning reduces exposure. Provenance and build records shrink the response time.

Scenario 3: a vulnerable dependency has no fixed release. The factory is configured perfectly and the pipeline is signed. A library it ships still has a known vulnerability and the maintainer has not released a patch. Posture review has little to say. A fix-first platform proposes an upgrade when one exists and, when none does, offers hardened builds and forks as described later.

The pattern is simple. Posture prevents the factory from being abused. Supply chain controls limit what an abuse could change and fix what ships. Mature programs fund both.

The attestation and compliance angle

Buyers in regulated sectors often arrive at software factory security through a compliance requirement: a customer questionnaire, the CISA secure software development attestation form, EO 14028, SSDF or SLSA. Both vendors speak to this.

Legit's Trust Center focuses on control mapping and evidence workflows, including support for the CISA form. Safeguard's guardrails docs include EO 14028 SBOM-required and SLSA level 3 provenance guardrails, the policies and gates docs list SLSA level as a gate condition, and its TPRM module can require signed vendor SBOMs before contract signature and NIST SSDF attestation from suppliers. Safeguard's own Trust Center publishes framework statuses, with the docs stating that a framework needing an independent auditor cannot be declared compliant on a self-assessment. We hold no FedRAMP status today.

A practical test: ask each vendor to produce, for one of your real repositories, the evidence an auditor would accept for a secure build claim. A control mapping alone is not evidence of a build. A signed provenance statement for an artifact is evidence about a build. You may need both.

When to choose Legit Security

Choose Legit when most of these are true:

• Your biggest uncertainty is configuration across GitHub, GitLab, Azure DevOps, Bitbucket and CI systems, and you want continuous posture monitoring with alerts when a setting drifts.
• You have self-hosted runners, many workflows or many organizations, and need discovery of shadow pipelines and ownership.
• You want a vendor with a published research record on pipeline attacks and a free tool to start with.
• You are building a software compliance program and want control mapping, gap analysis and evidence workflows in one place.
• You already have scanners you want to keep and need a layer that correlates them.

When to choose Safeguard

Choose Safeguard when most of these are true:

• Your main exposure is in what flows through the pipeline: vulnerable and malicious dependencies and unsigned artifacts.
• You need signed attestations, SBOMs and provenance for what you ship, and policy gates that evaluate them.
• You want fixes as policy-gated pull requests that your own CI tests before anyone merges, and an answer when no upstream fix exists.
• You need to run inside your perimeter, with the local runner, private VPC or on-prem options, a custom air-gapped engagement, and Zero AI mode.
• You want published plans you can try before a sales conversation.

Using both

A sensible split is posture and drift detection from a specialist, and artifact integrity and remediation from a supply chain platform. Agree which system owns each class of finding so a single misconfigured workflow does not open two tickets, and test whether either can ingest the other's output. Neither vendor describes a built-in integration with the other in the sources we read.

An evaluation checklist for software factory security

Run this over two weeks on a test organization or a set of sandbox repositories. Seed the problems yourself so you know the right answers.

Seed the factory

1. Create a workflow that uses a third-party action pinned to a tag, not a commit SHA.
2. Create a workflow with the pull_request_target trigger that checks out the pull request head.
3. Create a workflow that places a pull request title directly into a shell command.
4. Create a workflow with write-all token permissions.
5. Register a self-hosted runner on a public test repository, and separately on a private one.
6. Commit a test secret that is fake but pattern-valid, and print one into a build log. Keep your current secrets tool in place whichever product you choose.
7. Publish one artifact unsigned and one with provenance.

Run each product

8. Record which seeded items each product reports, how long after the change, where the finding appears and whether it names an owner and a fix.
9. Check the platforms each rule covers. Ask for the full rule list for GitHub Actions, GitLab CI, Azure DevOps, Jenkins and Bitbucket Pipelines.
10. Ask whether the product alerts at the pull request that introduces the issue or only on a later scan.
11. Check for false positives on a clean, well-configured repository.
12. Ask each vendor to produce an attestation or provenance statement for the signed artifact, and verify it yourself with the tool the vendor names.

Governance and cost

13. Ask what permissions each product needs in your SCM and CI, whether it can run read-only, and where its data is stored.
14. Ask what the product does when it finds a problem: report only, open a ticket, block or fix.
15. Get written quotes with units, modules, support terms and renewal terms. For Safeguard, start from safeguard.sh/pricing.

Score each product from 1 to 5 on posture coverage, detection timing, artifact integrity, fix capability, integration effort and cost, and weight the scores by what your last incident review said. See also how to set up a CI/CD pipeline security gate and securing CI/CD pipelines from supply chain attacks.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Frequently asked questions

What is software factory security?

It is the security of the systems that build and deliver software: source control, workflows, runners, secrets, registries and the tokens and permissions between them. It has three layers: the configuration posture of those systems, the integrity of what they produce (provenance, signing, SBOMs), and the vulnerabilities in what flows through them.

What does Legit Security mean by the software factory?

Legit's platform page says it unifies vulnerability discovery, contextual risk scoring and remediation "across your software factory, from code to cloud." In practice its published material covers SDLC discovery, CI/CD protection and continuous monitoring, native scanning and, in its research, GitHub Actions, self-hosted runners and Azure DevOps.

Is there a free tool from Legit Security?

Yes. Legitify is an Apache 2.0 licensed open-source tool that scans GitHub and GitLab for insecure configurations. Legit's own comparison says it detects SCM misconfigurations only, while the paid platform covers CI, CD, package registries, pipelines, secrets and more.

Does Safeguard scan CI/CD pipeline configuration?

Safeguard's docs describe a five-rule pipeline-file ruleset for GitHub Actions and, for some rules, GitLab CI/CD, covering unpinned actions, the pull_request_target trigger, untrusted input in shell commands, write-all permissions and downloads piped into a shell. The docs say it is not offered in the app at the moment, with reviews available through a Safeguard representative. What Safeguard does run in the pipeline today is a scan step, policy gates and secrets scanning, described above.

Does Safeguard produce signed attestations?

Per the attestation docs, Safeguard produces in-toto attestations including SLSA provenance v1, CycloneDX and SPDX SBOMs, a vulnerability scan and a review, signed with Safeguard's own key, with the public key published and verification through cosign. Check the docs for current CLI support for your workflow.

Which is better for SLSA and SSDF compliance?

They help in different ways. Legit's Trust Center maps controls and captures evidence, and its platform lists SSDF and SLSA among mapped frameworks. Safeguard evaluates SLSA level and provenance as policy gates and produces the signed attestations themselves. Ask each to show the evidence an auditor would accept for one real build.

Can Legit Security and Safeguard be used together?

Yes. A posture and drift specialist next to a supply chain platform for artifact integrity and fixes is a reasonable design. Decide which system owns each class of finding, and check whether either can ingest the other's output.

How much does Legit Security cost?

Legit does not publish a price list on its own site. An AWS Marketplace listing shows a 100-user license block, as covered in our companion comparison. Ask for a written quote. For Safeguard, see safeguard.sh/pricing for current plans.

Can Safeguard run without sending code to an AI model?

Yes. Zero AI mode runs the platform deterministically with no language model in the loop, and tenants can bring their own model or use local models, set per tenant. The local runner scans on your machine and sends back only results.

Sources and access dates

All pages were read on 28 Oct 2026 unless noted, and full URLs are in this post's front matter. Legit's pages, press releases and research posts are vendor statements. Research posts are dated 6 Jun 2023, 30 Jan 2024, 5 Sep 2024 and 25 Nov 2024, with press releases of 18 Jul 2023, 30 Apr 2024 and 15 Sep 2025, so check them against the current product. The AWS Marketplace listing is a seller-provided third-party page. Safeguard facts come from docs.safeguard.sh and safeguard.sh/pricing.