DAST for APIs From an OpenAPI Spec in Safeguard

Yes. Safeguard DAST (GA) can test a running API from its OpenAPI or Swagger file, and from a live URL, a pasted curl command or a Postman collection. Every input goes through the same gate: you prove you own the target, you allow-list the hosts and paths in scope, and only then do safe, rate-limited requests run against it.

An API scan driven by a spec is only as good as the spec, the scope and the credentials you hand it. This post covers what an OpenAPI document gives a scanner, the Safeguard flow step by step as the docs describe it, where the docs are thin for the OpenAPI path, and what this testing cannot tell you.

Key takeaways

• DAST is generally available. Safeguard's docs say SAST and DAST are rolling out: the platform wiring, the unified findings model and the DAST safety controls are in place, and detection depth expands over time. Plan a scoped trial on one of your own APIs before you plan around it.
• API testing has four documented inputs. The Safeguard API Security integration tests an API from a live URL, an OpenAPI or Swagger file, a pasted curl command or a Postman collection. The Postman path is documented in detail; the OpenAPI path is documented in one line, so confirm the OpenAPI specifics during onboarding.
• Verified targets only. A target is unverified until you prove ownership by DNS TXT record, an uploaded token file, a meta tag or a verified email domain. Active checks cannot run against an unverified target, whatever the spec says.
• The spec is a map, not a permission slip. An OpenAPI file can list servers you do not own. Scope is an allow-list of hosts and paths, enforced on every outbound request, and anything outside it is blocked and logged.
• SAST is generally available (phase 1: JavaScript and TypeScript, Python, Java) and shares one findings model with DAST.
• SCA, vulnerability management and reachability analysis are GA.
• The Safeguard CLI and local runner are GA. The safeguard appsec dast command belongs to the DAST engine (GA). Private API hosts cannot be reached from Safeguard's scanner and need a runner inside your network.
• Policies and gates are GA and can act on findings in CI and at release. Autonomous remediation is GA and ships switched off, with every category set to Manual.
• Not an authorization test. A spec-driven scan with one set of credentials cannot prove that user A is blocked from user B's objects. That still needs designed tests and human testers.

The problem: APIs have no links to follow

A web scanner starts at a home page and follows links. An API gives it nothing to follow: no navigation, no forms, often no HTML. A JSON endpoint nothing links to is invisible to a crawl, and APIs are full of them: mobile backends, partner integrations, accidentally exposed internal calls and old versions nobody switched off.

So dynamic testing of an API needs a description of it. Version 3.1.0 of the OpenAPI Specification, published on 15 February 2021, describes itself as a standard, language-agnostic interface description for HTTP APIs that lets humans and computers understand a service without the source code, extra documentation or network traffic inspection. For a scanner, the spec supplies what a crawl cannot: paths, methods, parameters, body shapes and how authentication works.

The risk runs both ways. Without a spec, a dynamic test covers a fraction of the API and its clean result means little. With a spec, the scanner can reach everything listed, including operations that delete data and servers you do not control. So spec-driven API testing needs tighter scope controls than page-driven web testing.

What the OWASP API Security Top 10 says about this gap

Three entries in the OWASP API Security Top 10 2023 bear directly on spec-driven testing.

API9:2023 Improper Inventory Management. OWASP's entry describes APIs exposing more endpoints than traditional web applications, which makes accurate, current documentation important, and warns that outdated documentation makes it harder to find and fix vulnerabilities. A scan run from a spec checks that documentation: paths that answer but are not listed, or listed operations that no longer answer, mean your inventory is wrong.

API1:2023 Broken Object Level Authorization. OWASP describes object level authorization as an access control mechanism, usually implemented in code, that checks a user can only reach the objects they are permitted to reach. It is also the category automated scanning handles worst, because finding it means knowing which objects belong to whom.

API8:2023 Security Misconfiguration. Missing security headers, permissive cross-origin settings, verbose errors and weak transport settings are the kind of runtime issue Safeguard's docs give as DAST examples. These are the categories where a spec-driven dynamic test earns its keep quickly.

The other seven entries range from partly testable by automation to almost entirely a matter of design review and manual testing. A table later in this post goes through all ten.

What NIST SP 800-228 asks for

NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (June 2025), puts the specification at the centre.

• REC-API-1 says every API must have a specification describing the endpoints it exposes. It accepts that this can start as a document or a set of wiki pages, but says it should eventually move to a proper interface definition language.
• REC-API-2 says specifications should use a well-defined interface definition language, and names OpenAPI for HTTP and REST APIs.
• REC-API-3 says the request and response schema for each endpoint should be defined in the specification, including validation rules for each field.
• REC-API-4.2 asks for an organisational inventory of all internal and external APIs, explicitly including shadow and zombie APIs, with each API's specification, its ownership and runtime information.
• REC-API-4.3 recommends tools that improve visibility, such as API discovery tools and scheduled automated scans that detect all running APIs.

Together they describe a loop: write the spec, keep it in an inventory, and scan on a schedule to check that what runs matches what is written. Spec-driven DAST tests the inventory against reality; it does not create it.

What the SSDF expects from testing

NIST SP 800-218, the Secure Software Development Framework (version 1.1, February 2022), covers executable code testing under practice PW.8. Task PW.8.1 asks teams to decide whether executable code testing should be done to find vulnerabilities that earlier reviews and analysis missed, and if so which types. Task PW.8.2 asks teams to scope the testing, design the tests, perform them and document the results, including recording and triaging every discovered issue in the development team's workflow or issue tracker. One of its examples is integrating dynamic vulnerability testing into the project's automated test suite.

Two words in PW.8.2 matter most here: "scope" and "design". A spec-driven scan with neither is not what the SSDF describes, however many requests it sends.

Where the OWASP testing guides fit

The OWASP Web Security Testing Guide (4.2 is the current stable release) and the OWASP ASVS, which describes itself as a basis for testing web application technical security controls, are the checklists your human testers and design reviews should use after the automated scan has done the repetitive part.

What an OpenAPI document gives a dynamic scanner

Before you upload anything, know which parts of the spec drive a dynamic test and which quietly reduce coverage when missing or wrong. Field names come from OpenAPI 3.1.0; how a given scanner uses them varies.

The servers field deserves special attention

The specification says that if the servers property is missing or empty, the default is a single server with a URL of /. In other words, a spec with no servers, or only relative ones, does not say where the API lives. Safeguard's docs draw a contrast here: they say a Postman collection needs no base URL because it already says where each request goes. Expect the other inputs, including an OpenAPI file, to need a base URL that you supply or confirm, and make sure that base URL is a verified host.

The opposite problem is as common. Developer portal specs often list production, a sandbox, regional endpoints and sometimes a partner's gateway. A spec is documentation for callers, not a statement of what you may test, which is why Safeguard's scope allow-list exists.

Security schemes and what they mean for credentials

OpenAPI 3.1.0 defines five security scheme types: apiKey (in a header, query string or cookie), http (such as basic or bearer), mutualTLS, oauth2 and openIdConnect. The spec tells a scanner how authentication works. It never supplies the credential itself, and it should not.

Safeguard's docs list which authentication methods are supported for Postman collections: bearer token, API key in a header or query, basic auth and an OAuth 2.0 access token already saved in the collection, with auth inherited from folders and the collection as Postman does it. The docs do not set out an equivalent list for the OpenAPI input. If your API uses mutual TLS, an OpenID Connect flow, or a custom signing scheme, ask during onboarding how the OpenAPI path handles it before you assume coverage of authenticated operations.

How Safeguard handles API testing today

The engine. DAST (GA) tests a running application by sending safe, non-destructive requests and observing responses. The docs give missing security headers, injection classes and misconfigurations as examples, and say detection uses benign markers and bounded time-based or out-of-band inference, never data-destroying or denial-of-service payloads.

The API inputs. The Safeguard API Security integration takes a live URL, an OpenAPI or Swagger file, a pasted curl command or a Postman collection. All four run under the same safety controls.

The controls. Six controls are enforced in code: verified targets only, a strict host and path scope, mandatory rate limits and budgets, non-destructive detection, safety modes, and a full audit trail of every DAST request and finding change with actor, tenant and timestamp.

The output. The offering files list these DAST output tabs: Info, Assets, Domains and Subdomains, Pages, APIs, Ports and Services, JS Analysis, Forms, Parameters, Certificates, DNS, Sitemaps, Wayback URLs, Vulnerabilities, Findings, Compliance, and Reports and Documents. For an API scan, APIs, Parameters and Findings do most of the work. Findings carry severity, rule, CWE and location, and share one model with SAST and SCA findings, so a DAST-confirmed issue can be linked to the SAST source code sink that produced it.

Safeguard's DAST product page goes further than the docs, describing endpoint discovery that reads OpenAPI descriptions among other sources. Treat the docs as the stricter source: they say detection depth is still expanding, and that is the position to plan around.

For the general picture of DAST scope, verification and safety modes, and the Postman path, see Safeguard DAST scope: verified targets, what it discovers and what it will not test. This post stays on the OpenAPI route.

Step by step: test an API from its OpenAPI spec

This is the flow as Safeguard's Application Security Testing, Unified Findings, Local Runner and CLI docs describe it. Where the docs do not show a screen or a field for the OpenAPI path specifically, the step says so and describes the outcome you need rather than inventing a button.

Step 1. Confirm the DAST engine is on for your tenant

Each first-party engine is controlled by a server-enforced feature flag, according to the Unified Findings docs. The DAST flag is scanner:dast. With it off, the DAST sub-tab does not appear in the Application Security panel of a project's Findings tab and the engine does not run. This is the first thing to check. If you do not see DAST in your tenant, ask your Safeguard contact.

Step 2. Pick the environment, then make a scan copy of the spec

Decide which deployment you are testing before you touch the spec. For anything beyond a passive look, that should be a staging or test environment with production-like configuration and disposable data.

Then make a copy of the OpenAPI document for scanning. The copy is not a different API; it is the same API with the scan decisions written into it:

1. Fix the servers. Leave only the server URL for the environment you are testing. If the spec uses only relative paths, note the base URL you will supply.
2. Mark what is out. Decide which operations must not run, typically bulk deletes, account closure, payment capture, operations that send email or SMS to real people, and anything that calls a third party on your behalf. Either remove them from the scan copy or plan to keep their paths out of the scope allow-list in step 5. Doing both is safer.
3. Fill the examples. Where an operation takes an ID, set its example to a test record. Generated or placeholder IDs make coverage of authenticated operations patchy.
4. Check the schemas. Free-form objects and missing required flags reduce what any scanner can usefully send. Spend ten minutes on the busiest endpoints first.
5. Validate the document. Run your usual OpenAPI linter or validator on the copy. A spec that does not parse cleanly will not drive a clean scan.

Keep the scan copy next to the real spec so the next scan starts from a reviewed file.

Step 3. Verify ownership of every API host you will test

Verification comes before any active check. Safeguard's docs list four methods: a DNS TXT record on the target's domain, a token file hosted at a well-known path, a meta tag added to the site, or a verified email domain. Until one succeeds, the target stays unverified and only passive, non-intrusive checks are permitted, if any.

For APIs, the methods are not equally convenient:

• DNS TXT is usually the cleanest fit for an API host such as api.staging.example.com, because it does not depend on the API serving HTML or files.
• File upload works if your gateway can serve a static token file at the given path. Many pure JSON services cannot without a change.
• Meta tag needs an HTML page, which a JSON-only API rarely has.
• Email domain suits teams where the right person has a mailbox on the target's domain.

Verify each API host separately. A spec that lists a payments host and a core API host is two verification decisions, not one.

Step 4. Add the integration and provide the OpenAPI file

Open the Integrations page. The docs describe adding an AppSec integration the same way you add a repository or registry: register a target, verify ownership, set in-scope hosts and paths, and choose the safety mode. The API Security integration is where the API input is provided.

Provide the scan copy of your OpenAPI file from step 2. If the spec does not carry an absolute server URL for the environment you verified, supply or confirm the base URL. The docs document the upload sheet in detail only for Postman collections, so expect the OpenAPI sheet to differ and check the details with your Safeguard contact while DAST is generally available.

Step 5. Set the scope allow-list

Scope in Safeguard is an allow-list of hosts and paths, checked on every outbound request. Anything not on it is blocked and logged. That has two consequences for an API scan:

• A server in the spec is not in scope until you put it there. If you missed a partner URL in step 2, the allow-list is the backstop.
• You scope by inclusion. List the path prefixes you mean to test (for example orders, catalogue and profile) rather than everything that must not be touched.

A first scan of one service on one host is more useful than a sprawling one you cannot interpret.

Step 6. Choose a safety mode and budgets

Safeguard's docs list three modes for normal use: passive, safe_active and authenticated_safe_active. For APIs, use passive for a first look at a production host's transport and headers, safe_active for the few unauthenticated operations on a verified staging host, and authenticated_safe_active for the operations behind authentication, which for most APIs is most of them. A heavier lab_aggressive mode is off by default, never auto-selected, and needs elevated authorization plus a target flagged as owned and isolated.

Rate limits and budgets are mandatory: requests per second, requests per node and maximum duration. You can tune them; you cannot remove them. Set requests per second so a burst against the most expensive operation in scope, such as a search or export, does not page your on-call engineer.

Step 7. Provide test credentials

Most API coverage depends on this step. Three rules apply whatever the input:

1. Use a dedicated test identity. A low-privilege account in a test tenant, never an administrator and never a real customer.
2. Prefer short-lived tokens. If your identity provider can issue a token that expires after the test window, use it.
3. Know where the credential goes. For Postman collections, the docs say credentials are used to sign the scan's requests to the hosts you tick, are stored with the uploaded file, and are removed from findings, the endpoint inventory and reports. The docs do not state the equivalent for the OpenAPI path, so ask, and treat any credential you provide as something to rotate after the test.

The docs do not describe token refresh for the OpenAPI input, so confirm how a scan keeps a valid token for its full duration.

Step 8. Run the scan

The docs say scans trigger through the standard integration, pipeline and CLI flow, and can run in your pipeline or on a local or on-prem runner.

To run from a terminal or a CI job, install the Safeguard CLI (GA) as the docs show for macOS and Linux:

curl -fsSL https://cli.safeguard.sh/install | bash

Then run the DAST command exactly as the Application Security Testing page shows it:

# Dynamic analysis of a verified, in-scope target
safeguard appsec dast \
  --target-id <target> \
  --base-url https://app.example.com \
  --scope-host app.example.com \
  --tenant-id <tenant>

For an API, the base URL is the verified staging API host and the scope host matches it. The docs say the command refuses to run against an unverified or out-of-scope target and that the safety kernel enforces this whatever flags you pass. These snippets are reproduced from the docs; they were not run for this post.

Private APIs. The docs say localhost, private IP ranges and .local or .internal names cannot be reached from Safeguard's scanner. For those, use the local runner (GA), which ships with the CLI and runs inside your network. The runner docs describe it as a fit for restricted networks where only outbound HTTPS is allowed. The guide repo connection, CLI or local runner explains the trade-offs.

Step 9. Read coverage before you read findings

Open the project and start at Info, where the Scanner Coverage cards show a live finding count per scanner. Then check coverage before you trust any result:

• APIs tab. Compare the endpoints listed with the operations in your scan copy of the spec. Operations that are missing were not reached. Endpoints that appear but are not in your spec are an inventory question for API9:2023.
• Parameters tab. Check that the parameters you expected to be exercised appear. An operation whose parameters never show up probably failed authentication or validation before testing began.
• Certificates and DNS tabs. For API hosts these often surface the quick wins: expiring certificates, hostname mismatches and stray DNS records.

For Postman collections the docs describe a Hosts tested panel that marks each host as tested in full, partly tested, did not answer or not tested, and they make a point that applies to every input: a host that was not tested has no findings because it was not looked at, not because it is clean. Apply the same reading to the APIs tab for an OpenAPI scan.

Step 10. Triage findings, then gate and route

Open the Findings tab and choose DAST in the Scanner dropdown. The table, summary statistics and queries narrow to the dast finding type. Each finding shows severity, rule, CWE and location. The docs say there is no CLI command for listing findings yet, so triage happens in the app, or through an assistant connected to Safeguard.

Then close the loop that SSDF PW.8.2 describes:

• Record and assign. Every confirmed finding goes to the owning team's normal workflow.
• Gate. Safeguard policies and gates (GA) can act on findings at CI and release checkpoints with Block, Warn or Notify, and approvals go through exceptions. A confirmed high severity API finding on a release candidate can be handled like a critical dependency vulnerability. The post on plain English security policies to release gates shows how policies are written.
• Correlate. If SAST (GA) runs on the same service, check whether the DAST finding is linked to a source code sink. A linked pair tells the developer both what happened at runtime and where in the code to fix it.
• Re-run. After the fix, scan again with the same scope and spec copy.

A worked reading: what a first API scan usually tells you

Safeguard does not publish a sample report for the OpenAPI path, and we will not invent one. What follows is a template for reading your first run, built from the output tabs the offering files list and the questions OWASP API9 and NIST REC-API-4.2 raise. Fill it in from your own project.

When a scan turns up endpoints the spec does not list, ask who owns them and why they are undocumented before you test them. Recon tabs can list hosts run by another team or a vendor, so confirm ownership before widening the allow-list.

What spec-driven dynamic testing can and cannot cover

This table maps each OWASP API Security Top 10 2023 category to what automated, safe, spec-driven dynamic testing in general is suited to. It is not a statement of Safeguard's detection coverage per category, which the docs do not publish and which is still expanding.

Spec-driven DAST is strong on "what does this endpoint do with an unexpected request" and weak on "should this user be allowed to do this". Plan for both.

Which input to use: OpenAPI, Postman, curl or live URL

All four inputs the docs list lead to the same engine and the same controls. They differ in what they tell the scanner and how much work you do up front.

With both a spec and a collection, run the spec first to measure coverage against the contract, then the collection for authenticated journeys. Where they disagree, you have found an inventory gap.

Keeping an API scan safe: API-specific scoping

The general scoping rules for DAST are in the companion scope post. These are the decisions that are specific to APIs.

Separate reads from writes. GET operations that read test data are the low-risk core of an API scan. POST, PUT, PATCH and DELETE operations change state. Decide for each write operation whether it runs against disposable data, is left out of the scan copy, or is kept outside the allow-list.

Watch idempotency. A benign request to a "create" endpoint still creates an order or sends a notification. Point these at a resettable test tenant, or leave them out.

Find the side doors. Webhook registration, callback URL parameters and import-from-URL features make your API call somewhere else. Do not scope operations whose side effects reach systems you do not own.

Version the scope with the spec. When the API adds a version (for example a v2 path prefix), the allow-list does not update itself. Treat the scope as configuration that is reviewed when the spec changes, which also supports NIST's REC-API-4.4 on versioning and deprecation.

How API findings connect to the rest of Safeguard

A DAST finding is a symptom at runtime; the fix lives in code, configuration or a dependency.

• SAST (GA). With SAST running on the service's repository, a DAST-confirmed finding can be linked to the source code sink that produced it, according to the docs. Phase 1 languages are JavaScript and TypeScript, Python and Java.
• SCA and vulnerability management (GA). Many API runtime issues trace back to a framework, parser or serialisation library. SCA lists those components with known vulnerabilities, enriched with EPSS and CISA KEV data.
• Reachability analysis (GA). Reachability ranks vulnerable code paths your application actually calls, so a dependency finding linked to a confirmed API issue can be prioritised alongside it. The post on prioritising with reachability, EPSS and KEV explains the signals.
• Autonomous remediation (GA, ships off). Where the fix is a dependency upgrade, Griffin can open a tested, policy-gated pull request. It ships switched off with every category set to Manual; see autonomous remediation in Safeguard.
• Policies and gates (GA). Findings can drive Block, Warn or Notify outcomes in CI and at release, with exceptions for approved risk.

What Safeguard does not do

Honest limits, specific to API testing from a spec:

1. It does not test hosts you have not verified. A partner's sandbox or a payment provider's API in your spec gets no active checks. Testing third-party APIs needs their permission.
2. It does not prove your authorization model. A scan with one test identity cannot show that user A is blocked from user B's records (API1) or that a regular user cannot call an admin function (API5). Those need designed tests with multiple identities and human judgement.
3. It does not stress test. Rate limits and budgets are mandatory and payloads are never denial-of-service. If you need to know how the API behaves under load or abuse of expensive operations (API4), use load testing in an isolated environment.
4. It does not test business logic. Whether a discount can be applied twice, or a refund issued for an undelivered order, depends on rules the spec does not encode (API6).
5. It does not reach private addresses from Safeguard's scanner. Internal APIs on private IP ranges or internal names need the local runner inside your network.
6. It does not fix a bad spec. Missing schemas, wrong servers or stale paths limit any scan. Keeping the spec right is your team's job.
7. It does not document every OpenAPI detail yet. The docs describe the Postman path in depth and the OpenAPI path in a single line. Supported spec versions, multi-server handling, authentication handling and credential storage for the OpenAPI input should be confirmed with Safeguard during onboarding, not assumed.
8. It does not replace a penetration test. Automated scanning and human-led testing are different activities, and the OWASP testing guide is written for the second. DAST supports the human test by clearing the repetitive checks; it does not stand in for it.
9. There is no CLI command to list findings yet. Triage happens in the app or through a connected assistant.

Common mistakes

Uploading the public developer portal spec unchanged. Portal specs list production and sandbox servers and every operation, including destructive ones. Make a scan copy with the servers and operations you actually intend to test.

Treating the spec's servers as the scope. The spec says where the API lives, not what you may test. The allow-list is the scope. Write it deliberately.

Choosing meta tag verification for a JSON API. Most API hosts do not serve HTML. DNS TXT is usually the right method for an API host.

Running authenticated tests as an administrator. Admin credentials hide authorization problems and widen the blast radius of every write.

Forgetting that tokens expire. A scan that loses its token halfway reports nothing for every operation it could not reach. Check coverage first.

Ignoring endpoints that are not in the spec. Undocumented endpoints are the API9 finding; find their owner.

FAQ

Can Safeguard run DAST from an OpenAPI file?

Yes. Safeguard's docs say the API Security integration tests an API from a live URL, an OpenAPI or Swagger file, a pasted curl command or a Postman collection. The same verification, scope, rate limit and safety controls apply to every input.

Which OpenAPI versions does Safeguard DAST support?

The docs say "an OpenAPI or Swagger file" and do not list versions or file formats. Confirm the versions your spec uses with Safeguard during onboarding while DAST is generally available.

Does Safeguard test every server listed in my OpenAPI spec?

No. Active checks run only against verified targets, and every request is checked against the host and path allow-list you set. Servers in the spec that you have not verified and allow-listed are not tested. Out-of-scope requests are blocked and logged.

How do I give Safeguard credentials for an authenticated API?

For Postman collections, the docs list bearer tokens, API keys in a header or query, basic auth and saved OAuth 2.0 access tokens. The docs do not set out the equivalent for OpenAPI files, so confirm the options for your authentication scheme during onboarding. In every case, use a dedicated low-privilege test account and rotate the credential afterwards.

Can Safeguard DAST scan an internal API that is not on the internet?

Not from Safeguard's scanner. The docs say localhost, private IP ranges and .local or .internal names cannot be reached and are not tested. Run the scan through the local runner (GA) inside your network.

Is it safe to point Safeguard DAST at a production API?

Use passive mode on production and keep active and authenticated checks for staging with disposable data. Detection is non-destructive and rate limits are mandatory, but a benign request to a "create" endpoint still creates something.

Will Safeguard find broken object level authorization in my API?

Do not rely on it. Finding object level authorization flaws needs knowledge of which objects belong to which user and usually two or more test identities. That is a designed test and a manual testing task, not something a single-identity automated scan can prove.

Where do API DAST findings appear and can they block a release?

In the project's Findings tab with the Scanner dropdown set to DAST, with severity, rule, CWE and location. Policies and gates (GA) can act on findings at CI and release checkpoints with Block, Warn or Notify outcomes, and approvals go through exceptions.

Is Safeguard DAST generally available?

Yes, it is generally available. The docs say SAST and DAST are rolling out, with detection depth expanding over time.

Does a spec-driven DAST scan help with API inventory requirements?

It helps check one. NIST SP 800-228 asks for an inventory of all APIs, including shadow and zombie APIs, and recommends scheduled automated scans. Comparing what a scan finds with what your spec lists shows where the inventory is wrong; maintaining it is still yours.

From an API finding to a fix

When an API finding traces back to a vulnerable framework or library rather than your own code, the fix is a dependency change, and the faster path is a pull request rather than a ticket. The options below cover that dependency side; the runtime and authorization issues discussed above still need fixes in your own code and configuration.

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

None of these demos shows a DAST run, because DAST is generally available. They show the pieces around an API test.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For API testing, the runner is the documented route to APIs on private addresses that Safeguard's scanner cannot reach.

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

The second demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal and is asked to fix the lodash CVE in a repository. It reads the finding and the advisory, edits package.json to lodash 4.17.21, and asks before any command that changes something, so npm install and npm test run with approval. It prints a summary and pushes nothing, then shows /permissions, /model and /scan. When an API finding traces back to a vulnerable dependency, this is how the fix gets made.

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

The third demo connects Claude to Safeguard. Add Safeguard from Claude's connector directory, sign in with OAuth and choose which tools Claude can use. Because there is no CLI command for listing DAST findings yet, an assistant connected this way is a practical second route to reading findings alongside the app.

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

To try the surfaces yourself, get the apps and CLI at safeguard.sh/download and read the full documentation at docs.safeguard.sh/docs. For the full list of what Safeguard ships today and at what maturity, see what Safeguard does today, every capability labelled.

Quick check

Sources

• Safeguard Docs: Application Security Testing (SAST and DAST)
• Safeguard Docs: Unified Findings and Feature Flags
• Safeguard Docs: Local Runner
• Safeguard Docs: Safeguard CLI
• Safeguard: DAST product page
• Safeguard Concepts: DAST
• OpenAPI Specification v3.1.0
• OWASP API Security Top 10 2023
• OWASP API1:2023 Broken Object Level Authorization
• OWASP API9:2023 Improper Inventory Management
• NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (CSRC)
• NIST SP 800-228 full text (PDF)
• NIST SP 800-218, Secure Software Development Framework (CSRC)
• NIST SP 800-218 full text (PDF)
• OWASP Web Security Testing Guide project
• OWASP Application Security Verification Standard project
• CISA: Secure by Design

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