How to Run AppSec With One Security Engineer per 100 Developers

You run application security with one engineer for a hundred or more developers by turning the program into defaults rather than reviews. Inventory and dependency scanning run on every push without anyone asking, a small number of gates block only what is exploited and reachable, fixes arrive as pull requests the owning team merges, and the security engineer spends their week on the handful of decisions no tool can make: exceptions, design reviews for risky changes, and incidents.

The method below works with whatever tools you already run. Near the end we show how Safeguard does the same job, with the maturity label of every capability we mention.

A note on the ratio. We use one engineer per hundred developers as a planning case, not a benchmark. We found no primary, non vendor survey of security to developer ratios we could cite, so this post makes no claim about how common it is. At one to fifty or one to three hundred the model still holds; only the queue size changes.

Key takeaways

• At this ratio you cannot review code or triage findings by hand. Your job is to design the defaults and own the exceptions.
• Build four controls first, in order: inventory, dependency scanning on every push, a release gate with a short block list, and fixes as pull requests.
• Rank findings by exploitation and reachability, not by severity alone. CISA's Known Exploited Vulnerabilities catalog and FIRST's EPSS are free inputs anyone can use.
• Block on a very short list (for example, a known exploited vulnerability that is reachable in a production service). Warn or notify on everything else. Every block needs an exception path with an expiry date.
• Some SSDF and SAMM practices can wait at this size. Vulnerability response, toolchain configuration and third party component checks cannot.
• Hire the second engineer when exceptions and design reviews, not scanning, start eating the week.
• Safeguard capabilities covered, with labels: SBOM generation and analysis (GA); SCA and vulnerability management with EPSS and KEV (GA); reachability analysis and prioritisation (GA); policies, gates and guardrails (GA); autonomous remediation and Griffin fix pull requests (GA, ships switched off with every category set to Manual); CLI, IDE extensions and MCP server (GA); mobile app; Gold Open Source (GA); fork and patch (GA); SAST (GA, not part of this plan's backbone).

The problem: what goes wrong at one engineer per hundred developers

Picture one AppSec engineer at a fast growing SaaS or fintech company. A hundred developers merge code every day, each service pulls in hundreds of open source packages, and every scanner produces a long list. Requests arrive from sales (a questionnaire), managers (can we ship?), compliance (audit evidence) and developers (is this finding real?). Three things then go wrong, in order.

The queue becomes the job. The engineer triages findings one by one. Across a hundred repositories that is thousands of findings, and one person reading the advisory, finding the owner and opening a ticket might manage twenty a day. The queue grows faster than that.

Tickets go stale. Triaged findings become tickets in another team's backlog, next to features customers are paying for, and they lose. Months later the security engineer is chasing the same tickets in standups.

Every exception is a meeting. The release gate is too broad ("no high or critical vulnerabilities"), so it blocks often, and every block becomes a conversation. Developers learn to route around it.

This is a design problem, not a people problem. A program built on human review scales with headcount. A program built on defaults scales with the number of repositories, which is what is actually growing.

What the standards expect, and why that helps

The frameworks agree on the shape of the answer, which helps when you defend the design to leadership or an auditor.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, published in February 2022, groups its practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). PO.3.1 asks you to specify which tools or tool types each toolchain must include, and PO.3.3 to configure tools to generate artifacts that support security practices. PO.4.1 asks you to define criteria for software security checks, and PO.4.2 to implement the mechanisms that gather the information those criteria need. The framework expects automation with written criteria, not heroics.

On vulnerabilities, RV.1.1 asks producers to gather vulnerability information from acquirers, users and public sources, RV.2.1 to analyse each vulnerability enough to plan remediation, and RV.2.2 to plan and implement risk responses. PW.4.4 asks you to verify that acquired commercial, open source and other third party components meet your requirements over their life cycle. Those tasks are the backbone of a small program.

OWASP SAMM version 2 defines five business functions (Governance, Design, Implementation, Verification and Operations) and fifteen security practices, each with activities at three maturity levels. SAMM's own description says it does not insist on the highest level in every practice; each organisation picks a target that fits its risk. That is your permission to leave some practices at level one for a year.

CISA's Secure by Design guidance says every technology provider "must take ownership at the executive level" for product security. For a one person team, that matters: the defaults you set are the product's security posture, and leadership owns the decision to staff them.

The OpenSSF Concise Guide for Developing More Secure Software (14 June 2023) gives a practical checklist: multi factor authentication for privileged developers, a combination of tools in CI, monitoring known vulnerabilities in direct and indirect dependencies, updating quickly, keeping secrets out of repositories, review before changes are accepted, and a published way to report vulnerabilities. It also notes that tools should not be the only mechanism, but they scale. That is the argument of this post.

What can one security engineer realistically own?

Start from hours. A working week has about forty of them. Meetings, interruptions and administrative work take at least ten. That leaves roughly thirty hours of focused time. Everything in the program has to fit in thirty hours a week or run without the engineer.

Split the work into three buckets.

Things the engineer owns personally. Decisions that need judgment and context:

1. The policy: what blocks a release, what warns, what only notifies, and the written criteria behind each (SSDF PO.4.1).
2. Exceptions: who may accept risk, for how long, and on what evidence.
3. Design review for a short list of high risk changes (new authentication flows, payment paths, new data stores holding regulated data, new third party integrations with broad access).
4. Incident response for security events touching the product, including vulnerability disclosures from outside.
5. The weekly report to engineering leadership: what changed, what is blocked, what is overdue.

Things that run as defaults. Set up once, tuned occasionally:

1. Inventory: an SBOM generated for every repository and every built image, refreshed on every push.
2. Dependency scanning and vulnerability matching against public advisory data, with exploitation signals (KEV, EPSS) attached.
3. Ranking: a priority order that puts reachable, exploited findings in production services at the top.
4. Gates: the policy evaluated automatically in CI and on release.
5. Fix proposals: upgrade pull requests generated for the findings that have a fixed version.
6. Notifications to the owning team's channel, not to the security engineer.

Things developers own. Only they change the code, so they own the fix and the merge:

1. Merging fix pull requests for their services within the agreed time.
2. Requesting an exception, with a business reason and an expiry date, when they cannot fix in time.
3. Checking dependencies in the IDE or terminal before adding them.
4. Asking questions through a self service channel (documentation, a chat channel, or an AI assistant connected to the findings) before they ask the security engineer.

The test for any new task: does it need my judgment, or does it need to happen reliably? Reliable things become defaults. For judgment calls, ask whether a written rule could replace the judgment next time. Usually it can.

Which controls give the most coverage per hour?

Prefer controls that cover every repository at once, run without a human, and produce output a developer can act on. Here is the order we would build them in.

Inventory goes first because every incident starts with "where do we run this component?", and an SBOM per service answers that in minutes. Dependency work comes before code scanning because most of what a SaaS service runs is open source, and dependency findings usually come with a fixed version, while first party code findings need expert confirmation, the resource you are shortest of. Fixes as pull requests rank high because a pull request sits in the developer's normal review queue with a diff and a test run, where a ticket asks them to context switch into a backlog.

How do you cut a backlog to the few findings worth a human's time?

A backlog of thousands is mostly duplicates, unreachable code, development only dependencies and vulnerabilities nobody has exploited. This method works with any scanner that exports CVE IDs and package versions.

Step 1: Deduplicate by component, not by finding

The same vulnerable library version in forty services is one decision and forty pull requests, not forty triage tasks. Group by package and version first; a few packages usually account for a large share of findings.

Step 2: Separate production from everything else

A vulnerability in a test harness or a build tool that never ships is not the same as one in a production API. Tag each repository or image with environment and exposure; development only findings drop to a monthly sweep.

Step 3: Put known exploitation on top

CISA maintains the Known Exploited Vulnerabilities (KEV) catalog. A vulnerability is added only when there is reliable evidence of exploitation in the wild, it has a CVE ID, and there is clear remediation guidance. CISA created the catalog in 2021 under Binding Operational Directive 22-01. On 10 June 2026 CISA issued BOD 26-04, "Prioritizing Security Updates Based on Risk", which revokes and supersedes 22-01. BOD 26-04 binds federal civilian agencies, not private companies, but the variables it uses to set remediation urgency make a good model for anyone: whether the asset is publicly exposed, whether the CVE is on KEV, whether exploitation can be automated, and whether exploitation gives partial or total control. CISA says it publishes the last three for every CVE ID through services such as its Vulnrichment program. Set your own fix windows by those same variables, shortest for a KEV listed, automatable vulnerability on an internet facing service. Our post on BOD 26-04's four factors walks through the model.

CISA is also clear that KEV should be an input to prioritisation, not the only criterion. Its KEV page recommends a framework such as Stakeholder-Specific Vulnerability Categorization (SSVC), which sorts vulnerabilities into Track, Track*, Attend and Act using exploitation status, technical impact, whether exploitation is automatable, mission prevalence and public well-being impact.

Step 4: Add exploit probability for the rest

FIRST publishes the Exploit Prediction Scoring System (EPSS), a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It publishes a score from 0 to 1 for every CVE every day, free, as CSV and through an API. For findings not on KEV, EPSS gives you a second sort key that beats CVSS severity alone, because severity describes how bad exploitation would be, not how likely it is.

Step 5: Check reachability

Reachability analysis asks whether your code actually calls the vulnerable function. Static reachability builds a call graph from your source and dependencies; it is weakest where code runs through reflection, dynamic dispatch or eval. Treat "unknown" as reachable, and never suppress a known exploited vulnerability only because a tool called it unreachable.

Step 6: Route by owner and fixed version

Findings with a fixed version become upgrade pull requests to the owning team. Findings without one become a security engineer decision: a compensating control, a patched fork, removing the dependency, or an exception with an expiry date.

A worked example, with illustrative numbers rather than a measurement: 4,000 raw findings across 100 repositories collapse to perhaps 600 package and version pairs; production filters leave a few hundred; KEV and high EPSS leave a few dozen; reachability leaves a list one person can review in an afternoon.

What should block a release, and what should only notify?

A gate that blocks too often teaches bypass; one that never blocks teaches developers to ignore it. Keep a very short block list, a slightly longer warn list, and notify on everything else.

Three rules make the gate livable. Every block has an exit: an exception request with a reason, an approver and an expiry date, or the security engineer becomes the exit. Warn before you block: run each new rule in warn mode for two to four weeks and count how often it would have blocked. Notify the owner, not security: alerts go to the owning team; you read a weekly digest. SSDF PO.4.1 asks for defined criteria for security checks, and the gate is those criteria in executable form, so write them on a short page and link it from the failure message.

What does a weekly hour by hour routine look like?

Here is a week that fits in about thirty focused hours. Adjust the days to your team's rhythm; keep the shape.

Monday and Friday are fixed; Tuesday to Thursday flex. When a real incident lands, the whole week becomes incident response and the defaults keep running without you. That is the test of whether you built defaults or a personal queue.

Which SSDF and SAMM practices can wait, and which cannot?

Neither framework expects a small team to do everything at once: SAMM lets organisations choose target maturity per practice, and SSDF describes high level practices to integrate into an existing life cycle. Here is how we would sequence them with one engineer.

Almost everything on the "now" list is configuration, not ongoing labour. The practices you defer are the ones that need human hours per unit of output.

How Safeguard does this job

Everything above works with your existing tools. Here is how Safeguard runs the same model, using only flows its documentation describes. SBOM generation and analysis (GA) and SCA with vulnerability management, including EPSS and KEV enrichment (GA), build the inventory and the findings. Reachability analysis and prioritisation (GA) ranks them. Policies, gates and guardrails (GA) decide what blocks. Autonomous remediation and Griffin fix pull requests (GA, ships switched off with every category set to Manual) turn findings into pull requests. The CLI, IDE extensions and MCP server (all GA) let developers and their AI assistants answer their own questions.

Step 1: Set up the organisation so ownership is clear

Safeguard organises data as Tenant › Organization › Project › Version, and Products group projects to show combined risk across a release train. Roles are Tenant Admin, Manager, User and Viewer, with SSO group mapping. A workable pattern: the security engineer as Tenant Admin, engineering managers as Managers, developers as Users, leadership as Viewers. The team that owns the service owns its findings.

Step 2: Put a scan in every repository's CI template

The docs show a GitHub Actions workflow. Create a secret key in Safeguard under Settings › Developer with the scopes scans:trigger and scans:read, add it to GitHub as a repository or organisation secret named SAFEGUARD_API_KEY, and save this as .github/workflows/safeguard.yml:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs say no checkout step is needed because Safeguard clones the repository. Drop --fail-on critical for report only mode, or add --fail-on-gate all to fail on a policy gate instead of a raw severity. Start report only, then move to the gate once your block list is written. The docs also cover GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines, and warn that fork pull requests get no secrets in GitHub Actions.

Step 3: Read the ranked queue, not the raw list

Safeguard's reachability documentation describes four signals combined into one ranking: reachability, exploitability (EPSS and KEV, plus a public proof of concept signal), runtime context (environment, exposure, data class, criticality) and business context declared through policy. Each finding gets a Priority Score from 0 to 100. With default weights, the docs map reachable plus KEV listed plus production to P0 (90 to 100), reachable plus EPSS above 0.5 plus production to P1 (75 to 89), and unreachable findings of any severity to a 0 to 30 backlog band. Weights are configurable per tenant under Settings › Prioritization.

Reachability classes are Reachable, Conditionally reachable, Unreachable and Unknown; the docs say Unknown is treated as potentially reachable and not suppressed. The ESSCM Vulnerabilities table sorts by Priority by default, and the docs list filters that map onto Monday's first hour:

reachable:true
kev:true
epss:>0.3
env:production reachable:true kev:true

The last one is the P0 backlog. Safeguard's docs say reachability filtering removes 60 to 80% of findings from the urgent queue, based on aggregate data across customer tenants. Treat that as Safeguard's stated figure, not a promise for your codebase; your result depends on language mix and how your services use their dependencies.

The docs list static reachability as GA for JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, and .NET, with Ruby, PHP, Swift and Objective-C in Preview. For Ruby or PHP services, lean harder on KEV and EPSS. There is no CLI command for querying findings by priority yet, so do this step in the app.

Step 4: Write the block list as policies, then link them to a gate

In Safeguard, policies evaluate your SBOMs and generate findings, and gates are the checkpoints that enforce policies. The docs walk through the policy builder:

1. Go to Settings › Policies.
2. Click Create Policy.
3. Define conditions with the visual builder or YAML.
4. Set severity and the action.
5. Save and enable.

Conditions include vulnerability severity, CVSS, EPSS, licence, component age, maintenance status and SLSA level. Templates include No Critical Vulnerabilities, License Compliance and No Abandoned Packages.

Each policy has one Action: Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and the workspace's channels are notified). Per the docs, Notify fires when a policy starts failing and again when it finds new matches, not on every evaluation, which keeps the notify tier quiet. If any Block policy fails, the gate fails; an Error never counts as a pass.

Policy outcomes are turned on per workspace by Safeguard and are off by default; if there is no Outcome column on the Gates and Policies tables, ask your Safeguard contact. To fail CI on a gate, the docs give safeguard ci scan --wait --fail-on-gate with a gate name, ID or all; it exits 0 on Passed or Warning and non zero otherwise. For "warn before you block", create each new policy as Warn, watch the Outcome column for two to four weeks, then switch it to Block.

Step 5: Give every block an exit with an expiry

The docs describe an exception flow that matches the program's rule that every block needs an exit:

1. The developer clicks Request Exception.
2. They select the policy and finding.
3. They give a business justification.
4. They set an expiration date.
5. They submit for approval; approvers are notified, decide, and an audit trail is recorded.

Approval runs through this exception workflow; the gate actions themselves are Block, Warn and Notify. Compliance reporting shows status by policy, exception history and violation trends, and the docs' prioritisation dashboard shows urgent queue trend, time to remediate by priority band and backlog aging. Together they cover Friday's report.

Step 6: Turn on fix pull requests deliberately

Safeguard's AI Remediate, driven by Griffin, follows five stages in the docs: analysis, solution generation, impact assessment, pull request creation and validation. It can upgrade vulnerable packages, handle transitive conflicts and update lock files. The docs list full support for npm, yarn and pnpm; pip, poetry and pipenv; Maven and Gradle; Go modules; Cargo; Bundler; NuGet; and Composer.

There are three ways to run it:

1. Single vulnerability: open the vulnerability, click AI Remediate, review the proposed changes, click Create Pull Request.
2. Bulk: select vulnerabilities, click AI Remediate Selected; Griffin batches compatible fixes and creates one pull request per repository after you review.
3. Page level: from the Vulnerabilities page, click AI Remediate at the top, review the plan, approve and create pull requests.

Each pull request carries the CVE reference, a summary of changes, breaking change warnings and advisory links. Griffin classes breaking change risk as Safe, Minor, Major or Critical.

Autonomous remediation ships switched off, with every category set to Manual, and nothing is applied until the master toggle is enabled. Settings › AI Remediate holds Auto-Create PRs, Require Approval, Test Integration, Breaking Change Policy and Branch Naming. A sensible rollout: run bulk remediation on the P0 queue yourself; enable Test Integration; then auto create pull requests only for fixes classed Safe, with Require Approval on. The docs' own advice is not to auto merge breaking changes. The pull request lands in the owning team's normal review queue.

Step 7: Let developers and assistants self serve

Most "is this real?" messages disappear when developers see the same ranked data where they work.

IDE extensions (GA). The docs list an extension for VS Code and Cursor and a plugin for JetBrains IDEs that scan dependency manifests as you work, show vulnerabilities inline and offer AI assisted fixes. Sign in is an OAuth device flow (Safeguard: Login). For VS Code:

code --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension

CLI (GA). Developers run safeguard, type /login, then /scan .; while signed in, the runner uploads the SBOM and findings, never the source. safeguard scan --dir . writes JSON results under ./output and, per the docs, does not fail on findings; gating is done by policy gates. The assistant asks before any command that changes something and pushes nothing unless you approve it.

MCP server (GA). Safeguard is listed in Claude's connector directory as a community connector; connecting is an OAuth sign in and an Authorize access click. The docs say a new workspace starts with a small read only set of tools and an administrator enables the rest per tool. Keep developer access read only: a developer can ask "Find critical vulnerabilities" or "Which packages violate my license policy?" against the same data the gate uses. Read only tools for gate and policy outcomes, available when policy outcomes are on, let them answer "why did my build fail?" without you.

Requirement versus what Safeguard does versus what you still own

When is it time to hire the second AppSec engineer?

Finding counts are not the trigger; a tuned program absorbs a lot of repository growth. The signals are the ones defaults cannot absorb:

1. Judgment work takes more than half the week. Exception reviews and design reviews regularly spill past Tuesday. Judgment does not automate.
2. The buffer disappears. Friday's buffer has gone to incidents or urgent requests four weeks running.
3. Tuning stops. Wednesday's "improve one default" has not happened for a month, so gates drift and noise climbs.
4. Customers need a person. Penetration test coordination, deep questionnaires, contract security clauses and customer audits do not compress.
5. New surface areas arrive. A mobile app, an on premises product, a regulated data line or AI features each add judgment work the defaults do not cover.

What the second engineer takes over

Split by kind of work, not by repository:

• The first engineer keeps the policy, the gates, the exception approvals and the weekly report, because those need one consistent voice.
• The second engineer takes design review and threat modelling, customer facing security work (questionnaires, audits, penetration test coordination), and the first party code scanning rollout once the dependency pipeline is quiet.
• Both share incident response on a rotation, so neither is on call every week.

Before opening the role, write one page on what the program runs on its own today. If you cannot, the second hire inherits a personal queue, not a system.

For more on the first hire and early structure, see what to automate first at fifty engineers, when to hire your first AppSec engineer, how to structure a small security team and a scanning plan for 100 plus engineers.

What Safeguard does not do

This is the part of the program you still own, whatever tools you buy.

1. It does not replace threat modelling, design review or incident response. Those are judgment work and the core of the security engineer's job. Safeguard ranks and fixes dependency risk; it does not review your authentication design or run your incident call.
2. SAST is GA but should not be the backbone of this plan. Keep your existing practice for first party code review and analysis. SAST findings are not part of the --fail-on CI threshold today, so gating in this plan relies on dependency findings and policies.
3. Automation still needs an owner for exceptions. Policies, gates and fix pull requests run without you, but every exception request needs a human approver. Safeguard records the audit trail; it does not decide whether a risk is acceptable.
4. Autonomous remediation does nothing until you turn it on. It ships switched off with every category set to Manual. Someone has to choose which categories go to Auto, and someone has to review and merge the pull requests. Safeguard does not merge changes into your main branch on its own.
5. The MCP directory connector is read only for the tools it exposes by default. A new workspace starts with a small read only set, and an administrator enables more per tool. Do not plan on developers changing policies or approving exceptions through an assistant.
6. Policy outcomes are off by default per workspace. Gate outcomes, the Outcome column and the read only MCP tools for outcomes appear only after Safeguard turns policy outcomes on for your workspace.
7. Reachability is not proof of safety. The docs say reachability is weakest with reflection, eval and dynamic dispatch, with data driven vulnerabilities, and with configuration dependent paths. Static reachability for Ruby, PHP and Swift is in Preview. Keep KEV and EPSS in the ranking.
8. It does not set your risk appetite. Weights, block criteria and expiry windows are business decisions. Safeguard applies them; you and leadership set them.

Common mistakes

Blocking on severity alone. "No high or critical vulnerabilities" blocks constantly and teaches bypass. Block on exploitation and reachability in production, warn on severity.

Starting with code scanning. Its findings need expert confirmation, your scarcest resource. Start with inventory and dependencies.

Routing notifications to security. If every failed policy pings the security engineer, the engineer becomes the queue. Route to the owning team.

Exceptions without expiry. An exception with no end date becomes a permanent hole. Every exception gets a date.

Suppressing "unknown" reachability. Unknown means the analyzer could not decide. Treat it as reachable.

Turning on auto fix everywhere at once. Start manual, then auto create only for fixes classed as safe, with tests and approval on. Never auto merge breaking changes.

Skipping the cheap controls. Branch protection, required review and multi factor authentication cost an afternoon. Do them in week one.

Measuring findings closed. That rewards closing easy ones. Measure the P0 queue, median time to merge a fix pull request, and exceptions past expiry.

FAQ

How many developers can one application security engineer support?

We found no primary, non vendor survey of security to developer ratios to cite. The limit depends on how much of the program runs as defaults: with automated inventory, ranked findings, a short block list and fix pull requests, one engineer covers far more developers than with manual triage.

What should a one person AppSec team automate first?

Inventory (an SBOM per repository and image) and dependency scanning with CISA KEV and FIRST EPSS data. Both are cheap in a shared CI template and every later control depends on them.

How do I prioritise thousands of vulnerability findings with a small team?

Group by package and version, filter to production and internet facing services, put known exploited vulnerabilities on top, sort the rest by EPSS, then check reachability. Route anything with a fixed version to an upgrade pull request and keep only the no fix cases for yourself.

Should security findings block a release?

A few should. Block on a known exploited vulnerability that is reachable in a production service with a fix available, and on disallowed licences in distributed software. Warn or notify on everything else, and give every block an exception path with an expiry date.

Is EPSS better than CVSS for prioritisation?

They answer different questions. CVSS describes how severe exploitation would be; EPSS estimates the probability of exploitation in the next 30 days. Sort by KEV, then EPSS, and use CVSS as a tie breaker.

Which NIST SSDF practices matter most for a small security team?

Start with the toolchain and criteria tasks (PO.3.1, PO.3.3, PO.4.1, PO.4.2), third party component verification (PW.4.4) and vulnerability response (RV.1.1, RV.2.1, RV.2.2). Code review and dynamic testing (PW.7 and PW.8) can follow once those run without manual effort.

When should a startup hire a second application security engineer?

When judgment work (exceptions, design reviews, customer security requests, incidents) consistently takes more than half the week, the weekly buffer has vanished for a month, or a new surface area such as a mobile app or regulated data line arrives.

Does reachability analysis mean I can ignore unreachable vulnerabilities?

No. Unreachable findings move down the queue, not off it. Reachability analysis is weakest with reflection and dynamic dispatch, and a known exploited vulnerability deserves a human look even when a tool marks it unreachable.

When the finding needs a fix, not a scan

At one engineer per hundred developers, the findings that eat your week are the ones that need a fix and a decision, not another scan. The block below covers how Safeguard turns those into pull requests or ready made safe components, and what happens when upstream has no fix at all.

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, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. 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. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs 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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. 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, compatibility tested 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.

See how Safeguard would help

The first demo shows the self service piece of this model. It walks through connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use, which is the same control you would use to keep developer access read only while letting them ask "is this finding real?" without messaging you.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. After installing, safeguard opens the interactive terminal and the user asks it to fix the lodash CVE in the repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan .. For a small team, this is how a developer clears a P0 dependency finding in their own repository without a ticket.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session with the mobile app. It sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. For a security engineer covering a hundred developers, that is a way to approve a fix run on your own machine while you are away from the desk, without giving up the approval step.

Click through it at your own pace, or open it full screen.

To try the CLI, IDE extensions or the apps, start at safeguard.sh/download, and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• NIST SP 800-218 full text (PDF)
• OWASP SAMM: The Model
• OWASP SAMM: About
• CISA: Secure by Design
• OpenSSF: Concise Guide for Developing More Secure Software
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 22-01 (Revoked)
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• FIRST: Exploit Prediction Scoring System (EPSS)
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: AI Remediate
• Safeguard docs: GitHub Actions
• Safeguard docs: CLI Usage
• Safeguard docs: IDE Support
• Safeguard docs: Claude MCP integration

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.