Safeguard DAST Scope: Verified Targets, What It Finds, What It Skips

Safeguard DAST (early access) tests running web applications and APIs only after you prove you own the target, and only inside an allow-listed set of hosts and paths, using safe, non-destructive requests with mandatory rate limits. A run returns recon data (domains, pages, APIs, forms, parameters, certificates, DNS) plus vulnerabilities and findings that share one model with SAST (early access) and SCA (GA). It does not test business logic, it does not prove your authorization model, and it does not replace a manual penetration test.

Key takeaways

• DAST is early access. 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 today, and detection depth expands over time. Scope a demo on your own app before you plan around it.
• SAST is early access. Phase 1 languages are JavaScript and TypeScript, Python and Java.
• SCA, vulnerability management and reachability analysis are GA. SCA findings live in their own Vulnerabilities tab; DAST and SAST findings sit in the same findings model and can be correlated to them.
• Verified targets only. A target stays 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.
• Scope is enforced in code. Every outbound request is checked against an allow-listed host and path scope; out-of-scope requests are blocked and logged.
• Safe by default. Three safety modes for normal use (passive, safe_active, authenticated_safe_active). A heavier lab mode is off by default and needs elevated authorization plus a target flagged as owned and isolated.
• Policies, gates and guardrails (GA) can use findings as gates in CI and release.
• Autonomous remediation (GA) ships switched off, with every category set to Manual.
• The Safeguard CLI and local runner are GA. The safeguard appsec dast command itself belongs to the early access DAST engine.
• Not a pen test. PCI DSS, OWASP and NIST all treat automated scanning and human-led testing as different activities. DAST supports the second; it does not stand in for it.

The problem: dynamic testing without a scope is a liability

Dynamic application security testing sends real requests to a real, running system and judges the responses. That is what makes it valuable. It sees the deployed application, including the reverse proxy configuration, the security headers, the certificate chain and the debug route somebody forgot to disable. None of those live in the repository, so static analysis cannot see them.

It is also what makes DAST risky. A scanner pointed at the wrong host is unauthorized testing of somebody else's system. Pointed at the right host with the wrong settings, it can fill a production database with junk orders, lock out real accounts or slow a shared service to an outage. Pointed at a payment page, it might reach a processor you have no right to test.

So the hard part of DAST is rarely the detection logic. It is the boundary: which hosts, paths, accounts, hours and request rates, and who signed off.

What PCI DSS v4.0.1 requirements 6.4 and 11.4 expect

PCI DSS v4.0.1 is the current version of the standard. The PCI Security Standards Council published it as a limited revision of v4.0, with no added or deleted requirements, and retired v4.0 on 31 December 2024, according to the Council's own announcement. The future-dated requirements in v4.x took effect on 31 March 2025.

Two requirement groups bear directly on dynamic testing.

Requirement 6.4 is about protecting public-facing web applications against attacks. Under 6.4.1, an entity could either review those applications with manual or automated application vulnerability security assessment tools or methods at least once every 12 months and after significant changes, or install an automated technical solution that continually detects and prevents web-based attacks. Requirement 6.4.2, future-dated to 31 March 2025, makes the automated detect-and-prevent solution mandatory for public-facing web applications and supersedes 6.4.1. The practical reading for most teams: periodic assessment of the running app is still good practice and still evidence an assessor will ask about, but it no longer satisfies 6.4 on its own.

Requirement 11.4 is penetration testing. It asks for a defined, documented and implemented methodology (11.4.1) that covers the entire cardholder data environment perimeter and critical systems, tests from inside and outside the network, includes application-layer testing for at least the vulnerability classes listed in Requirement 6.2.4, and includes network-layer tests. Internal and external penetration tests run at least once every 12 months and after significant changes (11.4.2 and 11.4.3), performed by a qualified internal resource or a qualified external third party with organizational independence. Exploitable vulnerabilities found must be corrected and the testing repeated to verify the correction (11.4.4). Segmentation controls are tested too (11.4.5, and 11.4.6 more often for service providers).

The key point for this post: PCI DSS separates automated assessment tooling from penetration testing, and 11.4 expects a qualified, independent human. An automated DAST run can feed a tester's reconnaissance and can catch regressions between tests. It is not an 11.4 penetration test, and nobody should present it to an assessor as one.

The PCI DSS v4.0.1 text sits in the Council's document library behind a licence page; read the requirement wording there before you quote it in an audit response.

What the OWASP Web Security Testing Guide expects

The OWASP Web Security Testing Guide (WSTG) is the reference catalogue of what to test in a web application. The project page lists v4.2 as the current stable release, with version 5.0 in development. Its testing chapter is organised into twelve areas: information gathering, configuration and deployment management, identity management, authentication, authorization, session management, input validation, error handling, weak cryptography, business logic, client-side testing and API testing.

Two things in the WSTG matter for scoping.

First, information gathering comes first. You enumerate entry points, map execution paths, fingerprint the server and framework, and review metadata files such as robots.txt and sitemaps before you test anything. That is exactly the recon half of a DAST run, and it is also the half that most often wanders off the intended target, because a subdomain list or an archived URL list is not the same thing as a list of systems you are allowed to test.

Second, the guide is blunt about business logic. Its introduction to business logic testing says this class of flaw "cannot be detected by a vulnerability scanner" and that automating business logic abuse cases is not possible; it remains manual work that depends on knowing the whole business process. That sentence is the honest limit of every DAST product, including ours.

What OWASP ASVS expects

The OWASP Application Security Verification Standard (ASVS) defines what a secure application must do, rather than how to test it. The project page lists ASVS 5.0.0 as the stable release. ASVS keeps a three-level model: Level 1 as the first layer of defence, Level 2 as the comprehensive baseline most applications should aim for, and Level 3 for high-assurance applications.

The ASVS 5.0 chapter on assessment and certification has a section on the role of automated security testing tools. It says DAST and SAST, correctly placed in the build pipeline, may identify some issues that should never exist, but that without careful configuration and tuning they will not give the required coverage. It goes further: these tools cannot fully verify many of the more complicated requirements, especially those about business logic and access control. Its own summary is that "testable using automation" does not mean running an off-the-shelf tool. The same chapter recommends documentation-led or source-code-led (hybrid) penetration testing over traditional black box testing.

That framing is useful when you plan a programme. Use DAST to keep the straightforward, externally visible ASVS requirements (headers, transport security, injection classes, error handling, exposed configuration) verified continuously. Use people, code review and application-specific tests for the access control and business logic chapters.

What NIST SP 800-115 and the SSDF expect

NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment (September 2008), is old but still the clearest public text on how to plan and run technical testing. Three parts are directly relevant.

• Section 4.3, Vulnerability Scanning, warns that network-based scanning only finds vulnerabilities on active systems, generally covers surface vulnerabilities, can have a high false positive rate, can generate enough traffic to affect the hosts being scanned, and that scanners often include denial-of-service tests that should be suppressed. It also notes that application scanners suffer from high false negative rates, so undetected issues may need other kinds of testing.
• Section 6.6, Legal Considerations, recommends that legal advisors always be involved for intrusive tests such as penetration testing, and that external testers sign nondisclosure agreements.
• Appendix B, Rules of Engagement Template, lists what a written rules of engagement document should hold: purpose, scope, assumptions and limitations, risks, personnel and contacts, test schedule, test site, test equipment and authorized tools, communication and incident handling (including criteria for halting the test), the target systems with authorized and unauthorized addresses, an explicit "exclude list", allowable and unallowable activities, data handling, reporting, and a signature page.

NIST SP 800-218, the Secure Software Development Framework (SSDF), puts dynamic testing into the development lifecycle. Practice PW.8 is "Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements". Task PW.8.1 asks you to decide whether executable code testing should be performed and which types to use. Task PW.8.2 asks you to scope the testing, design the tests, perform them, and document the results, including recording and triaging every discovered issue and its recommended remediation in the development team's workflow or issue tracker. Its examples include integrating dynamic vulnerability testing into the automated test suite, adding tests for previously reported vulnerabilities so they do not return, and using penetration testing for high-risk scenarios where resources allow. The SSDF maps PW.8 to EO 14028 section 4e.

Note the first verb in PW.8.2: scope. NIST puts scoping ahead of testing for a reason.

Why the OWASP API Security Top 10 changes the scope question

The OWASP API Security Top 10 2023 lists the risks most specific to APIs. Three of them sit at the top: API1:2023 Broken Object Level Authorization, API3:2023 Broken Object Property Level Authorization and API5:2023 Broken Function Level Authorization. API9:2023 Improper Inventory Management and API10:2023 Unsafe Consumption of APIs round out the list, alongside broken authentication, unrestricted resource consumption, unrestricted access to sensitive business flows, server side request forgery and security misconfiguration.

Two lessons follow. Authorization flaws dominate the list, and a scanner struggles to prove them without knowing which user should see which object. And inventory is a risk in its own right: an API collection often calls hosts you do not own, such as a payment processor or an identity provider, so a safe tool has to make you choose which hosts are yours before it sends anything.

Requirement versus what Safeguard DAST does versus what you still own

Why Safeguard tests verified targets only

Safeguard's docs describe DAST as a defensive capability for authorized testing and say it is not a general offensive tool. The controls behind that statement are enforced in code rather than offered as interface conveniences. That matters for three reasons.

The first is legal. Testing a system you do not own or have not been authorised to test is, in most jurisdictions, a problem whatever your intent. A platform that lets any tenant point active checks at any URL is a platform that will eventually be used against somebody else. Requiring proof of control over the target before any active check removes that whole class of mistake and abuse.

The second is operational. A common DAST incident is an engineer who typed the production hostname instead of the staging one, or pasted a collection that also calls another company's API. Verification and an allow-listed scope turn those slips into blocked, logged requests.

The third is evidential. Assessors ask how you know testing stayed inside its boundary, and an audit trail of every request answers that with data.

How a target is verified

According to the Application Security Testing docs page, you choose one of four ownership verification methods when you register a target:

Until verification succeeds, the target stays unverified and only passive, non-intrusive checks are permitted, if the docs allow any at all. The docs also state flatly that "active checks cannot run against an unverified target."

A practical point the docs imply but do not spell out: verification proves control of a domain or a site, not authority over everything that domain touches. A verified marketing site can still embed a third-party chat widget or call a hosted search service. Verification gets you through Safeguard's gate. Your rules of engagement still decide what you are allowed to test.

What the safety kernel enforces after verification

Verification is the first of six controls the docs list for DAST. The other five apply to every run:

1. Strict scope. Every outbound request is checked against an allow-listed host and path scope. Requests outside it are blocked and logged.
2. Rate limits and budgets. Conservative per-target limits on requests per second, requests per node and maximum duration are mandatory and configurable. You can tune them; you cannot remove them.
3. Non-destructive by default. Detection uses benign markers and bounded, time-based or out-of-band inference. The docs say Safeguard never uses data-destroying or denial-of-service payloads.
4. Safety modes. passive, safe_active and authenticated_safe_active are the modes for normal use. A heavier lab_aggressive mode is off by default, never selected automatically, and requires elevated authorization plus a target flagged as owned and isolated.
5. Full audit trail. Every DAST request and every finding change is recorded with actor, tenant and timestamp.

The docs add that the DAST CLI command refuses to run against an unverified or out-of-scope target and that the safety kernel enforces this whatever flags you pass. In other words, there is no command line switch that overrides verification.

What a DAST run returns

DAST returns a different shape of data from SAST and SCA. Safeguard's offering files list these output tabs for a DAST project: Info, Assets, Domains and Subdomains, Pages, APIs, Ports and Services, JS Analysis, Forms, Parameters, Certificates, DNS, Sitemaps, Wayback URLs (archived URLs), Vulnerabilities, Findings, Compliance, and Reports and Documents. The platform exposes separate SAST and DAST column sets so the two are not forced into one table layout.

Because DAST is early access, treat the tab list as the shape of the output rather than a promise of depth in every tab for every target. Here is what each one is for and how to use it.

What kinds of issues DAST looks for

The docs describe DAST as testing a running application for runtime issues, giving missing security headers, injection classes and misconfigurations as examples, by sending safe, non-destructive requests and observing responses. Each finding carries severity, rule, CWE and location in the app's AppSec views.

Safeguard's DAST product page goes further and describes a scanner that starts from the SAST call graph, along with broader authentication and coverage claims. The docs, which are the stricter source, say detection depth is still expanding. Plan around the docs, and ask for a scoped demo on one of your own services before you rely on any specific check.

Reading recon output responsibly

Recon tabs can easily list hosts run by another team, a hosting provider or a vendor. The docs do not describe discovered hosts being added to scope automatically, so review what the run surfaced, confirm ownership of anything new, verify it as its own target, and only then widen the allow-list.

Step by step: add a target, verify it, set authentication, run, read

This is the flow as Safeguard's Application Security Testing and Unified Findings docs describe it. Where the docs do not show a screen or a command, the step describes the outcome rather than inventing one.

1. Confirm the DAST engine is enabled for your tenant. Each first-party engine is controlled by a server-enforced feature flag. 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 or return data. If you do not see DAST in your tenant, ask your Safeguard contact; it is early access.

2. Add a Safeguard DAST integration. Open the Integrations page and add an AppSec integration of type Safeguard DAST, the same way you add a repository or a registry. The docs describe this step as registering the target, verifying ownership, and setting the in-scope hosts and paths plus the safety mode.

3. Verify ownership. Pick one of the four methods (DNS TXT, file upload, meta tag, email domain) and complete it. Until it succeeds, the target is unverified and active checks are refused.

4. Set the scope. List the hosts and paths that are in scope. This is an allow-list: anything not on it is blocked and logged. Keep it as narrow as the test needs. If the rules of engagement say staging only, the allow-list should contain only the staging host.

5. Choose a safety mode and limits. Use passive for a first look, especially at anything production-facing. Use safe_active for unauthenticated active checks on a verified, in-scope target. Use authenticated_safe_active when you need coverage behind a login. Review the rate limits (requests per second, requests per node, maximum duration) against what the target can absorb. Leave lab_aggressive alone unless you have an owned, isolated lab target and the elevated authorization the docs require.

6. Set up authentication. The docs name the authenticated_safe_active mode but do not document a login recorder or a step-by-step screen for web form authentication, so confirm the current options for your app during onboarding. For APIs tested from a Postman collection, the docs are specific (see the next section): bearer tokens, API keys in a header or query, basic auth and an already-saved OAuth 2.0 access token are supported, and auth is inherited from folders and the collection as Postman does it. Use a dedicated test account in every case.

7. Run the scan. 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, install the Safeguard CLI (GA) as the CLI 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>
   

   The command refuses to run against an unverified or out-of-scope target whatever flags you pass.

8. Read the output tabs. Open the project. Start at Info and its Scanner Coverage cards, then work through the recon tabs (Domains and Subdomains, Pages, APIs, Forms, Parameters) to judge coverage before you judge results. A clean Findings tab on a run that only reached the login page means very little.

9. Triage findings. Open the Findings tab and choose DAST in the Scanner dropdown. The table, summary stats 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 the Safeguard MCP server, GA).

10. Gate and route. Use Safeguard policies and gates (GA) to block, warn, notify or require approval at CI or release checkpoints based on findings, and route fixes into your normal workflow. That closes the SSDF PW.8.2 loop of recording and triaging every discovered issue in the team's workflow.

Testing APIs from a Postman collection

The same docs page describes an API Security integration that tests an API from a live URL, an OpenAPI or Swagger file, a pasted curl command, or a Postman collection. It is part of the same early access dynamic testing work. The Postman path is documented in the most detail, and it shows how seriously the scope question is handled.

• What to upload. The collection exported as Collection v2.1 (v2.0 also works) as a .json file, plus its environment file if the collection's URLs use variables defined there. Environment values take priority over the collection's own values, the way an active Postman environment does.
• How requests are read. Variables come from the collection and the environment, references between variables are followed, and Postman's built-in dynamic values such as a GUID or timestamp are filled in. Headers, bodies (raw JSON, URL-encoded and text form fields, GraphQL) and auth are sent as the collection defines them.
• Scripts are not run. If a pre-request or test script normally logs in and stores a token, that token will not exist during the scan. The sheet warns you; put the value in the environment instead, ideally a token for a test account.
• Missing values. A request whose host comes from an undefined variable is skipped and listed in the results. An undefined path or query value is filled with a placeholder and the request is still tested.
• Host selection. Before the scan starts, the sheet lists every host the collection calls. Your own hosts are ticked by default. Well-known third-party services, such as payment, identity, email and messaging providers, are not ticked by default, and the docs say to tick one only if you are authorised to test it. Local and private addresses (localhost, private IP ranges, .local and .internal names) cannot be reached from Safeguard's scanner and are not tested; scan those with a runner inside your network.
• Limits. One scan tests at most 10 hosts, two at a time, in order of how many requests each has, and the hosts share the scan's time.
• Reading results. A Hosts tested panel shows each host as tested in full, partly tested, did not answer, or not tested and why, plus requests that could not be sent. The docs make a point worth repeating: a host that was not tested has no findings because it was not looked at, not because it is clean.
• Credentials. Tokens, API keys and passwords in the collection or environment sign the scan's requests to the hosts you tick and are stored with the uploaded file. They are removed from findings, the endpoint inventory and reports.

How to scope out destructive or production-sensitive paths

Safeguard's scope model is an allow-list of hosts and paths, not a deny-list. That changes how you exclude dangerous areas: you do not write "everything except /admin/delete", you write the paths that are in, and anything else is blocked. Combine that with the other controls:

• Prefer a test environment. The single best exclusion is not pointing active checks at production. Stand up staging with production-like configuration, verify it as its own target, and run safe_active or authenticated_safe_active there.
• Use passive on production. If you need a view of the real deployed configuration (headers, certificates, DNS), start with passive against production and keep active checks for staging.
• Allow-list narrowly. List the application paths you mean to test. Leave out bulk-delete endpoints, account closure, payment capture, outbound email and SMS triggers, admin consoles and anything that calls a third party on your behalf.
• Trim the collection. For API tests, remove destructive requests from the Postman collection or environment you upload, rather than relying on a later filter. Untick any third-party host you are not authorised to test.
• Use test accounts and test data. Authenticated testing should run as a dedicated low-privilege test user in a test tenant, never as an administrator or a real customer. Seed test data you can throw away.
• Tune the budgets. Lower requests per second and maximum duration for fragile services, and schedule runs outside peak hours, as NIST SP 800-115's rules of engagement template suggests.
• Keep lab mode in the lab. lab_aggressive exists for owned, isolated targets. If a target is shared, reachable by customers, or holds real data, it is not a lab.

How DAST, SAST and SCA findings land in one findings model

Safeguard's security engines do not each keep their own inbox. According to the Unified Findings docs, every engine reports into one findings model, discriminated by a finding_type field. DAST findings carry dast, SAST findings carry sast. SCA findings are deliberately left out of the Findings scanner dropdown because SCA already has its own dedicated Vulnerabilities tab, and showing them twice would duplicate the view.

That shared model is what makes correlation possible. Findings share correlation keys, so when a DAST-confirmed runtime issue maps to the SAST source-code sink that produced it, the docs say the two are linked and prioritised together, and a confirmed, reachable, exploitable finding rises to the top. Reachability analysis (GA) supplies the reachability signal; Safeguard's docs say it cuts noise by roughly 60 to 80%, which is Safeguard's stated figure rather than a guaranteed result for your codebase.

In the app, that looks like this:

Every finding is scoped to tenant and organisation end to end. Finding statuses in the Findings view follow Open, Resolved and Mitigated, and the finding card shows which gate caught it. From there, policies and gates (GA) can act on DAST findings the same way they act on SCA results, so a confirmed injection finding on a release candidate can block or require approval like a critical dependency vulnerability would.

Rules of engagement to have in writing before any DAST run

Safeguard's controls are a technical backstop. They do not replace a written authorisation. Before the first active run, get a short rules of engagement document signed by the system owner and the person running the tests. NIST SP 800-115 Appendix B is a good skeleton. At a minimum it should answer:

1. Purpose and owner. Which application, which organisation owns it, who is testing, and why.
2. Scope. The exact hosts, paths and API hosts in scope, and an explicit exclude list. Match this to the Safeguard allow-list line for line.
3. Environments. Staging, production or both, and which safety mode applies to each.
4. Accounts. Which test accounts and roles the scan may use, who created them, and when they will be disabled.
5. Schedule and rate. Permitted test windows, maximum request rates and maximum duration, aligned with the configured budgets.
6. Third parties. Which external services the app calls, and written confirmation that they are excluded unless their owners have authorised testing. Hosting providers may have their own testing policies; check them.
7. Communication and halt criteria. Who to call if the application degrades, the incident response contact chain, the conditions that stop testing, and how testing resumes.
8. Data handling. Results identify weaknesses an adversary could use, so NIST SP 800-115 says to treat them as sensitive. State who can see findings and how long reports are kept.
9. Legal review. NIST recommends legal advisors for intrusive tests. For external testers, add nondisclosure and liability terms.
10. Signatures. Named, accountable people on both sides.

Keep the signed document next to the Safeguard audit trail. Together they show an assessor both the authorisation and the evidence that testing stayed inside it.

What DAST will not do

Some things are outside what an automated dynamic scanner can do, whoever builds it.

Business logic flaws. Applying a discount twice, skipping a payment step, approving your own expense, ordering a negative quantity: these are valid requests that the application should refuse for business reasons. The WSTG says this class of flaw cannot be detected by a vulnerability scanner. Only someone who knows the process can design those abuse cases.

Full authorization testing. Broken object level, property level and function level authorization lead the OWASP API Security Top 10 2023. Proving them requires knowing that user A must not read user B's invoice, and testing with both users. A single scan identity cannot establish that. ASVS 5.0 says automated tools cannot fully verify access control requirements, and the same is true here. Write application-specific tests for your authorization rules and include them in manual testing.

A penetration test. PCI DSS 11.4 expects a qualified, independent tester with a documented methodology. ASVS recommends hybrid, source-led penetration testing. NIST SP 800-115 treats penetration testing as its own discipline with its own planning. DAST shortens the reconnaissance and catches regressions between tests. It does not chain findings, improvise, or make judgement calls about impact the way a person does.

What Safeguard does not do

Being specific about limits is part of using any tool safely. These are the ones that matter for DAST today.

1. DAST and SAST are early access, and depth varies. The docs say the wiring, the unified findings model and the safety controls are in place, and that detection depth expands over time. Do not plan a compliance commitment around a specific DAST check until you have seen it work on your application in a scoped demo. SAST phase 1 covers JavaScript and TypeScript, Python and Java only.
2. It will not test a target you have not verified. There is no override flag. If you cannot complete DNS, file, meta tag or email verification for a host, Safeguard will not run active checks against it, even if you have a contract that authorises you. That is deliberate.
3. It will not reach private addresses from Safeguard's scanner. Localhost, private IP ranges and .local or .internal names are not tested from the hosted scanner. Use a runner inside your network for internal targets.
4. It does not replace a penetration test, a business logic review or authorization testing. Budget for people.
5. It does not run your Postman scripts. Tokens set by pre-request or test scripts will not exist during a scan; put them in the environment. A collection scan also covers at most 10 hosts.
6. Authenticated scans need maintenance. When your login flow changes, when MFA is added to the test account, or when tokens expire, authenticated coverage can quietly drop. Check the Pages and APIs tabs after each change to confirm the run still reaches the pages behind the login.
7. There is no CLI command for listing findings yet, and the /v1 REST endpoints on several findings docs pages return 404 today. Triage in the app, or through an assistant connected to the MCP server.
8. It is not a web application firewall. If PCI DSS 6.4.2 applies to you, you still need the automated detect-and-prevent control it describes.
9. It does not write or sign your rules of engagement, and it cannot know which third-party services your contracts allow you to test. That judgement stays with you.

Common mistakes

• Verifying the apex domain and assuming every subdomain is fair game. Subdomains are often run by other teams or vendors. Verify each target you intend to test and keep the allow-list explicit.
• Running active checks against production first. Start with passive on production and safe_active on staging. Move up only with a reason and a signature.
• Uploading a collection that still includes the payment provider. Safeguard leaves well-known third-party hosts unticked by default. Do not tick them without the provider's authorisation.
• Scanning as an administrator. Admin sessions hide authorization bugs and maximise the damage if a check has side effects. Use a low-privilege test user, and a second one if you want to compare.
• Forgetting the token lives in a script. If your Postman login stores a token through a script, the scan will run unauthenticated. Put a test token in the environment.
• Calling a DAST report a penetration test. Assessors know the difference, and PCI DSS 11.4 spells it out. Present DAST as continuous testing between penetration tests.
• Turning on autonomous remediation and expecting DAST fixes to appear. Autonomous remediation ships switched off with every category on Manual, and its categories are about dependencies, licenses, posture, findings and similar. A runtime misconfiguration found by DAST usually needs a person to change server or application configuration.

FAQ

Does Safeguard DAST scan sites I do not own?

No. The docs say a target is unverified until you prove ownership by DNS TXT record, an uploaded token file, a meta tag or a verified email domain, and active checks cannot run against an unverified target. The CLI refuses to run against an unverified or out-of-scope target regardless of flags.

Is Safeguard DAST generally available?

No. DAST is early access, as is SAST. The docs say the platform wiring, the unified findings model and the DAST safety controls are in place today and that detection depth expands over time. Ask for a scoped demo on one of your services.

Can Safeguard DAST replace our annual penetration test for PCI DSS?

No. PCI DSS v4.0.1 Requirement 11.4 expects penetration testing by a qualified internal resource or qualified external third party with organizational independence, against a documented methodology. Automated DAST can support that work and catch regressions between tests, but it is not the test itself.

Is it safe to run Safeguard DAST against production?

It is designed to be conservative: non-destructive detection, no denial-of-service payloads, mandatory rate limits and an allow-listed scope. Even so, start with passive mode on production, run active checks against a staging environment, and only scan production actively under signed rules of engagement with agreed windows and limits.

How do I scan an internal application that is not on the internet?

Safeguard's hosted scanner cannot reach localhost, private IP ranges, or .local and .internal names. The docs say to scan those with a runner inside your network. The local runner (GA) lets scans run on infrastructure you control.

How does Safeguard DAST handle logins and authenticated pages?

The docs list an authenticated_safe_active safety mode for authenticated testing. For API collections, bearer tokens, API keys, basic auth and a saved OAuth 2.0 access token are supported, and scripts are not run, so put tokens in the environment. Use a dedicated test account, and recheck coverage when your login or MFA setup changes.

Can Safeguard DAST find business logic vulnerabilities?

Not reliably, and no automated scanner can. The OWASP Web Security Testing Guide says business logic flaws cannot be detected by a vulnerability scanner. Plan manual testing for checkout, approval and entitlement flows.

Where do DAST findings show up, and can they block a release?

In the project's Findings tab with the scanner filter set to DAST, and in the DAST sub-tab of the Application Security panel when the scanner:dast flag is on. Each finding has severity, rule, CWE and location. Safeguard policies and gates (GA) can use findings to block, warn, notify or require approval in CI and at release.

How is DAST connected to SAST and SCA results in Safeguard?

All three share one findings model with correlation keys. When a DAST-confirmed runtime issue maps to the SAST sink that produced it, the two are linked and prioritised together. SCA findings stay in the dedicated Vulnerabilities tab.

From a DAST finding to a fix

Many DAST findings are configuration fixes: a missing header, a verbose error page, an exposed debug route. Those need a change to your server or application configuration and a rerun to confirm. Some, though, trace back to an outdated framework or library in the build, which is where correlation with SCA findings helps, and where Safeguard's remediation tools apply.

DAST tells you something is wrong in the running app; when the root cause is a vulnerable open source dependency or container image you ship, the fastest route is to move to a fixed version. The block below describes how Safeguard handles that part, and it applies to the dependencies behind a DAST finding rather than to the configuration issues DAST also reports.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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; DAST is early access and is best seen in a scoped demo on your own service. They show the surfaces you would use around it: the CLI, a runner inside your own network, and an assistant connected to Safeguard.

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal, and asks it to fix a lodash CVE in a repository; the CLI reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The same CLI is where the safeguard appsec dast command runs, and the same ask-before-acting habit fits dependency fixes behind a DAST finding.

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

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. That matters for DAST because Safeguard's hosted scanner cannot reach private addresses; the docs say internal targets should be scanned with a runner inside your network.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Since there is no CLI command for listing findings yet, an assistant connected this way is one route to querying and triaging findings, and choosing tools per assistant is the same scoping discipline this post argues for. Safeguard is listed in the Claude connector directory as a community connector.

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 more on dynamic testing, see our posts on authenticated DAST scans that start from the code, authenticated DAST without wrecking the app, API endpoints hidden in JavaScript, crawl or OpenAPI import, what crawlers miss in API-first architectures and how attack surface management and penetration testing differ.

Quick check

Sources

• Safeguard Docs: Application Security Testing (SAST and DAST)
• Safeguard Docs: Unified Findings and Feature Flags
• Safeguard Docs: ESSCM Findings
• Safeguard Docs: Safeguard CLI
• Safeguard Docs home
• Safeguard: DAST product page
• Safeguard Concepts: DAST
• Safeguard: ESSCM product page
• Safeguard: Download
• PCI Security Standards Council: PCI DSS
• PCI Security Standards Council blog: Just Published, PCI DSS v4.0.1
• OWASP Web Security Testing Guide project
• OWASP WSTG v4.2: Introduction to Business Logic Testing
• OWASP WSTG v4.2 testing chapters (GitHub)
• OWASP Application Security Verification Standard project
• OWASP ASVS 5.0: What is the ASVS
• OWASP ASVS 5.0: Assessment and Certification
• OWASP ASVS 5.0: Preface
• OWASP API Security Top 10 2023
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (CSRC)
• NIST SP 800-115 full text (PDF)
• NIST SP 800-218, Secure Software Development Framework (CSRC)
• NIST SP 800-218 full text (PDF)

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