Application security testing: what you should know

Application security testing (AST) finds and fixes vulnerabilities in software. It has four core approaches: SAST reads source code, DAST tests the running application, IAST instruments it at runtime, and SCA audits dependencies. Coverage now also turns on two newer questions: do you know which apps and API routes you own, and do your tests reach the AI endpoints inside them?

The two pillars, Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), were built for an earlier web. Modern web frameworks and APIs hide routes from the crawlers DAST relies on, and SAST has always struggled with false positives and with flaws that only become obvious once the browser is involved.

The testing category has renamed itself repeatedly over the years. The label matters far less than a concrete question you can put to any tool: given an application you did not document, can it find the endpoints, reach the fully authenticated states, and hand back evidence a developer can act on? That is the bar this guide uses throughout.

A second shift is now compounding the first. AI-assisted development means software no longer ships only from engineering. Developers build faster with coding agents such as Claude Code, Codex and Cursor, while finance, HR, and operations teams stand up dashboards, portals, low-code workflows, and AI-generated internal services of their own. Every one of those applications and APIs adds to a growing application attack surface, and it grows faster than any security team can inventory or test by hand.

This guide covers the fundamentals of application security testing, how the approaches differ and where each one is blind, and what testing has to look like when agents write, and fix, a growing share of the code. Pairing source intelligence, which reads your code to map the API routes your frameworks declare, with dynamic testing of the running application is one answer to that: used together, each covers the other’s blind spots.

What is application security testing (AST)?

No single approach sees everything. SAST reads code but cannot watch behavior; DAST watches behavior but cannot read code; SCA only knows about components someone has already catalogued. The most effective programs combine them.

Types of application security testing

The four core AST approaches differ in what they analyze, when they run, and what they miss. They are complementary, not competing, which is why mature programs run more than one.

NightVision concentrates on discovery and DAST. Its source intelligence reads supported REST frameworks to map the API routes that maintained documentation or observed traffic may miss, and hands that map to the API scan. See how the platform fits together.

SAST vs DAST: how do they differ?

SAST and DAST are the two pillars of application security testing, and the simplest way to tell them apart is when they run and what they can see. SAST reads your source code without executing it; DAST exercises the running application from the outside, the way an attacker would.

How to choose an application security testing approach

There is no single “best” tool, only the right mix for your stack, your release cadence, and the kinds of flaws you most need to catch. As the Defense in Depth principle holds, SAST, DAST, IAST, and SCA each answer a different question, and the strongest programs run more than one. The framework below is meant to help you reason about where each approach earns its place, and where discovery-driven testing of the real, running attack surface (NightVision’s focus) tends to matter most for modern, API-heavy applications.

A practical decision framework

• Lean on SAST when you want to catch code-level flaws early. SAST reads source without running it, so it surfaces issues like SQL injection, cross-site scripting, and hardcoded secrets at the commit stage. Its trade-off is noise: pattern matching produces false positives, and it struggles with runtime, auth, and business-logic issues that only appear once the app is live.
• Lean on DAST when you need to see what an attacker sees. Dynamic testing exercises the running application, so it finds runtime, configuration, authentication, and business-logic flaws that SAST cannot observe. The catch is coverage: a DAST tool can only test the endpoints it can discover, which is why discovery has to come first for API-first apps.
• Consider IAST when you can instrument the application. Interactive testing places an agent inside the running app, combining runtime context with code visibility. It is language and runtime specific, so it fits best in test and QA environments. (NightVision does not sell an IAST product.)
• Use SCA to govern your dependencies. Software composition analysis audits open-source and third-party components for known CVEs and license risk; it covers your dependencies, not your custom code. (NightVision does not sell an SCA product either.)
• Why combined coverage wins across the SDLC. No single approach sees everything: SAST reads code but cannot watch behavior, DAST watches behavior but cannot read code, and SCA only knows catalogued components. NightVision set out to close that gap by pairing discovery-driven DAST with source intelligence, so testing starts from the real attack surface and, on API scans backed by source intelligence, findings point to the file and line that defines the affected endpoint. Source intelligence is not a SAST engine: it maps routes and, for supported frameworks, how each route is protected, and the scan then tests them live.

An evaluation checklist for buyers

When you compare tools, these are the axes that separate a scanner built for an earlier web from one built for distributed, API-first applications. Score each vendor honestly against your own apps.

• App discovery, starting from your domain. Can the tool find the apps nobody onboarded, or does it test only the targets someone registered?
• API discovery coverage, including shadow and undocumented endpoints. Does the tool enumerate the real attack surface, or does it test only what an OpenAPI file documents? Discovery that reads source code can surface shadow, zombie, and versioned endpoints that spec-only and crawl-only scanners never see.
• Auth and stateful-scan handling. Look for scripted login journeys that handle MFA, credentials held in a secrets vault, sessions that persist for the length of the scan, and a login check that fails the pipeline instead of silently scanning logged out, because a scan that never logged in can still report a clean result. (How NightVision handles this: authenticated scanning.)
• Evidence quality and false-positive rate. Prefer findings backed by request and response artifacts and reproduction steps over pattern-only alerts. Code-traced linkage, where available, cuts triage time and routes fixes to the right owner.
• Triage that persists. Do false positives you dismiss stay closed on the next scan, or come back as new findings each run?
• CI/CD integration. The tool should fit the pipeline with tunable modes (a fast PR check, a deeper scheduled scan) and respect rate limits and change windows.
• Language coverage. Source-aware discovery is only useful if it speaks your stack. NightVision’s source intelligence reads Java, Python, JavaScript and TypeScript, C#, Ruby on Rails, PHP (Laravel) and Go, with depth that varies by framework; confirm any vendor covers the languages your services are actually written in.
• Compliance reporting. Check whether the tool maps cleanly to the OWASP API Security Top 10 (2023) and produces exportable, evidence-backed artifacts you can attach to SOC 2, PCI DSS, or federal control narratives.
• Agent readiness. Ask the question that separates a chat integration from a working loop: can your coding agent launch a scan, read the evidence, propose a fix, and verify it, with a human approving the change? Look for an MCP server or agent skills that expose scanning, findings, and per-finding evidence as tools. (How NightVision handles this: NightVision for coding agents.)
• AI endpoint tests. Does the tool test model-backed endpoints, such as a support chat or a summarizer that can fetch URLs, and does it require proof before it reports a finding?

Discovery first: apps, then API routes

API security testing and next-generation DAST have had to evolve fast, because the web itself changed underneath them. No longer are we all just browsing a set of HTML files that security tools can easily crawl to find things to test. Instead, APIs have eaten the web, and security has struggled to keep up.

A scanner can only test what it knows exists, so inventory comes before testing, at two levels: the applications the organization actually runs, including ones nobody registered with the security team (see application discovery below), and the API routes each application’s code declares, including ones no spec documents.

API discovery and inventory management

An API inventory is not just a list of function calls or the output from a Swagger scan. The sensitivity of each function maps to the risk the organization assumes by exposing it, and an API need not be vulnerable to be sensitive. Any endpoint that communicates information in a way that is not monitored, traceable and auditable is a threat even when it performs exactly as designed. It’s like having a headquarters building with doors you don’t know are there, so you never think about locking them.

The OWASP API Security Top 10 (2023) names the failure directly: Improper Inventory Management (API9:2023), where outdated API versions and undocumented hosts stay exposed because nobody is tracking them.

Shadow, zombie, ghost, or orphan APIs

Shadow, zombie, ghost, and orphan APIs are undocumented or deprecated endpoints that remain live and reachable but are missing from an application’s official API inventory. Automated documentation such as Swagger can miss many of them, for understandable reasons:

• Developers may intentionally build secret APIs into a system for testing or development purposes, then leave them in the source code (shadow APIs).
• Organizations may replace APIs with new versions without removing the older ones, sometimes intentionally, to keep older clients in the field working (zombie APIs).

Both of these categories are often also referred to as rogue APIs. A DAST tool whose map of all endpoints in an application comes from Swagger documentation, or from the pages a crawler can click through, will naturally fail to uncover rogue APIs, which are often the endpoints an attacker wants most. For how the two differ and how to find each, see shadow and zombie APIs, explained; for how teams operationalize this, see shadow API detection and API inventory integrity.

The same inventory gap shows up in newer places: the shadow MCP servers developers stand up as glue, the AI infrastructure services nobody put in scope, and the surge of apps built by non-developers. For a framework-level walkthrough on .NET, see ASP.NET Core API Security Testing: Start From the Source, Not the Swagger File.

Application Security Posture Management (ASPM) and API inventory

Application Security Posture Management (ASPM) consolidates findings, asset inventories and ownership from many testing tools into one risk view. API discovery feeds it: a current, source-derived route inventory is what lets a posture view say which endpoints were tested and which were not.

Dynamic Application Security Testing (DAST), built for API-first apps

Modern apps are API-heavy, stateful, and dynamic. Legacy DASTs that “crawl and guess” miss large parts of the attack surface, struggle with auth and state, and bury teams in noise. This section covers what modern DAST must do and how to operationalize it next to API discovery and code-aware testing. For how NightVision itself implements these requirements, see DAST built for modern apps.

Why legacy DAST misses modern apps

• SPA & dynamic routing: Client-rendered routes hide content from naive crawlers; form flows and JS events gate critical paths.
• Auth & state drift: Sessions expire; CSRF/anti-automation defenses and MFA flows break scans; test data isn’t persisted between steps.
• API blind spots: Endpoints outside an OpenAPI file (shadow/legacy/versioned) go untested.
• Throughput vs. safety: Aggressive fuzzing trips WAF/rate limits and pollutes logs; timid scans under-cover.
• Alert fatigue: Pattern-only findings without exploit proof (and no code or request/response evidence) waste triage cycles.

What “next-gen DAST” looks like

1. API-aware discovery first. Pull endpoints from every source available (OpenAPI and Swagger specs, Postman collections, recorded traffic, and analysis of the source code itself), then feed that inventory into DAST so you test what actually exists, not just what’s documented.
2. Authenticated, stateful crawling that actually works. Scripted logins that survive MFA, sessions that persist across the scan, and multi-step forms that really submit; LLM-assisted form handling improves path coverage on validation-gated forms. A scanner that quietly falls back to unauthenticated crawling after a failed login is worse than one that fails loudly.
3. Test generation grounded in real check classes. An automated scanner earns its keep on the flaw classes that are reliably testable from the outside: injection (SQL, command, template), cross-site scripting, server-side request forgery (including blind SSRF, which a scanner proves only when the target calls back, sometimes after the scan has closed), path traversal, CORS and security-header misconfiguration, JWT validation flaws, and known-CVE template checks. Context from discovery makes those checks targeted rather than blind fuzzing. Know the boundary, too: the OWASP API Security Top 10 (2023) is led by authorization flaws such as Broken Object Level Authorization (BOLA, API1:2023), and proving them requires multiple user identities plus knowledge of who should own which object, which remains largely a human penetration-testing discipline.
4. Evidence on every finding. Demand the full request and response that produced each finding, with reproduction steps, so triage starts from artifacts instead of pattern-only alerts. Source linkage, where a finding can be traced toward the code that owns the route, cuts triage time further.
5. Coverage visibility. The scanner should show which discovered endpoints a scan actually exercised, so untested surface is a visible list rather than a silent gap that compounds across builds.
6. Pipeline-native controls. Scans should start from the pipeline and gate it on conditions the team chooses. Production safety comes from scanning staging and pre-production builds, not from hoping an aggressive scan behaves.
7. Agent-ready interfaces. The newest requirement: expose scans, findings, and evidence to MCP-capable coding agents (Claude Code, Codex, Cursor and others), so an agent can launch a scan, read the evidence, propose a fix, and verify it with a rescan, while a human approves the merge.

The check classes above each have a failure pattern worth understanding before you evaluate a tool: the CORS header worth reading twice, JWT validation that decodes a token without verifying it, authentication that is not authorization, and mass assignment through a signup form. Fixes regress too, whether it is an authentication bypass patched twice or a fix undone by the next AI-written commit, and a control can be configured without being live, which is the case for MFA enforcement testing.

NightVision’s approach to DAST (how it fits your stack)

• Discovery → Test: Source intelligence maps real API routes, including shadow and versioned ones, and hands that map to the API scan.
• Crawl that keeps up: Session-aware scanning with LLM-assisted form handling reduces stalls on login and multi-step flows, improving route coverage on SPAs and authenticated areas.
• Impact-first findings: Evidence-backed results (request/response artifacts and reproduction steps) cut triage time; on API scans backed by source intelligence, findings point to the file and line that defines the affected endpoint, so fixes reach the right owners quickly.
• Built for CI/CD: Scans run from GitHub Actions, GitLab CI, Jenkins, Azure DevOps, and Bitbucket, with results landing as SARIF in GitHub Security Alerts and a login-check gate that fails the pipeline instead of scanning logged out.

Advanced API security testing

Testing modern applications aggressively does not have to mean exploiting them in production. Point NightVision’s DAST at a build running in your own staging environment (including on private networks, via Smart Proxy) and it exercises the API in a live setting without endangering production.

Teams also run manual tests with intercepting proxies such as Burp Suite and Zed Attack Proxy (ZAP), and with fuzzers such as Ffuf and Wfuzz that brute-force hidden paths or substitute payloads into requests. NightVision pairs DAST with source intelligence, so the scan starts from the routes your code declares and runs from your CI/CD pipeline. For a side-by-side look, see our tool comparisons, including NightVision vs. Burp Suite and NightVision vs. OWASP ZAP.

No DAST tool, however, is a complete replacement for a professional offensive security test. Automated coverage of the repeatable classes buys human testers time for the novel ones, which is the model described in pentester acceleration, and NightVision works with offensive security partners who run full penetration-testing engagements.

New ground for application security testing

Five questions now decide whether a testing program covers what a team ships: which applications exist, which API routes they declare, whether the AI features inside them can be abused, whether triage decisions survive the next scan, and which cryptography will not survive a quantum computer.

Application discovery: find the apps before you test them

A scanner can only test the applications someone onboarded. Web application discovery starts from a company’s domain and finds the web apps and APIs tied to it, so the test inventory reflects what actually runs, not what someone remembered to register. It is the application-level counterpart of API discovery: one finds the apps, the other finds the routes inside them.

API discovery from source code

API discovery from source reads the route declarations in an application’s code and generates an OpenAPI specification from them before any traffic exists. That surfaces undocumented, shadow and zombie routes that spec-only and crawl-only testing cannot see.

AI and LLM endpoint security testing

Applications increasingly expose endpoints backed by a language model: a support chat, a summarizer, a search box whose model can fetch URLs or call tools. If that model can be steered into making server-side requests, an attacker can use it the way they would use any server-side request forgery bug, to call out to infrastructure they control or to read the cloud metadata service that hands out credentials (see LLM cloud metadata exposure). That behavior exists only when the model runs, so it is a dynamic testing problem.

Triage that persists across scans

Every scanner produces some findings a team decides are not real or not worth fixing. If the next scan reports them again as new, triage time compounds and real findings get buried. Triage decisions should persist: a finding marked false positive on an endpoint stays marked in future scans of that app. A finding marked resolved is not suppressed, so if the issue is still there, the next scan reports it again. Stable finding identity is what makes that possible.

Cryptography inventory and quantum readiness

Public-key cryptography such as RSA, Diffie-Hellman and elliptic-curve keys and signatures is expected to fall to a large quantum computer, and NIST’s draft transition guidance (IR 8547) deprecates it after 2030 and disallows it after 2035. Traffic recorded today can be decrypted later, so the work starts with an inventory: which applications choose which algorithms, in code, in committed keys and certificates, and in TLS configuration. A scanner outside the app sees only the handshake, so that inventory has to be built from source.

Application security testing in the age of AI-assisted development

AI-assisted development changes application security testing in two ways at once. Developers now drive testing through coding agents that can launch scans, read evidence, and draft fixes. And people who are not developers now ship software of their own, adding to a growing application attack surface faster than any security team can inventory it by hand.

The first audience uses the tools. The second never will, and the program has to cover their output anyway. In both cases the buyer, and the reviewer, is the AppSec team: same team, far more surface.

Developers drive testing through coding agents

For engineering teams, the change is where testing runs, not who is responsible for it. Claude Code, Codex, Cursor and other MCP-capable agents can operate an agent-ready scanner directly: start a scan against the running build, pull the findings, read the request and response evidence for each one, draft a remediation, and rescan to confirm the finding is gone.

The division of labor matters more than the novelty. The scan itself stays deterministic, so two runs against the same build produce the same findings backed by the same evidence, which is what makes an agent’s fix verifiable rather than merely plausible. The agent works the loop; a human reviews the change and approves the merge. Determinism on the finding, agents on the fix, humans on the merge.

The same split applies to AI pentesting tools, which explore an application the way a tester would and can return different results on two runs. For where they fit next to deterministic testing, and what to ask a vendor, see AI pentesting vs DAST.

Builders outside engineering are a source of surface, not users

The second audience will never open a scanner, and no amount of enablement will change that. Finance teams stand up dashboards. HR wires portals to vendor APIs. Operations builds low-code workflows, and internal tools get vibe-coded or generated outright by agents. Each of these is a real application with real endpoints, often handling real data, and almost none of them enter a security backlog on their own.

Expecting these builders to run security tooling is the wrong model. The workable model treats their output as surface for the AppSec team to find, onboard and test, through the same pipeline that covers engineering’s applications.

Four ways in, one engine underneath

What bridges the two audiences is how testing reaches each application. There are four ways in: black box, where a URL and credentials are enough to test any reachable app, including the ones built outside engineering; gray box, where source-assisted discovery feeds the scanner endpoints no crawl or spec would reveal; CI/CD, where scans run in the pipeline on each build; and agent-native, where a coding agent drives the same operations over MCP. The same engine, checks and evidence sit underneath all four, so a finding means the same thing whichever door it came through.

The result is one program instead of two. Engineering adopts the entry points that fit its workflow, from CI/CD to agent-native. AppSec uses black box and gray box to cover everything else, including the applications that never came through an engineering pipeline. Coverage stops depending on who built the app or whether they knew a security team existed.

Compliance mapping: federal requirements, SOC 2, PCI DSS and NIST CSF

Regulated teams have to test modern, API-heavy apps and show how that testing maps to the frameworks they answer to. The summaries below are a starting point; for a standalone walkthrough of each federal framework, see our companion guide to federal API security requirements.

Federal requirements (U.S.)

• NIST SP 800-204 series (microservices and API security): asks for gateways or meshes, policy enforcement and strong authorization. Routes extracted from code help scope that policy, and DAST exercises them with request and response evidence; on why that evidence has to come from the deployed path, see Reverse Proxy Access Control Testing and Web Cache Deception.
• CISA Zero Trust Maturity Model (ZTMM v2.0): treats applications as internet-accessible and expects them to be tested. Discovery-led DAST supplies testing and coverage inputs, and request and response evidence and exportable SARIF and CSV results feed the monitoring and ATO packages you already maintain.
• FedRAMP (NIST 800-53 Rev. 5-based): evidence-backed findings and exportable artifacts support AU and SI control narratives; source intelligence and dynamic coverage support AC (authorization), CM (change) and SC (secure communications) discussions in SSPs and annual assessments.
• Executive Order 14028: calls for secure development and greater real-world testing. DAST produces reproducible evidence and aligns with “test like an adversary.” Source intelligence helps maintain accurate API inventories and specs across services.
• OMB M-22-09 (Federal Zero Trust Strategy): asks agencies to routinely subject applications to rigorous empirical testing. Gray-box DAST operationalizes that requirement and produces artifacts for POA&Ms and governance.

SOC 2

SOC 2 is an independent attestation: a licensed CPA firm examines controls against the AICPA Trust Services Criteria, for design at a point in time (Type 1) or operating effectiveness over a review period (Type 2). For authentication, error handling and access control, an auditor asks how you know the control works, and evidence-backed findings from testing the running application answer that better than a policy document. A current API inventory matters for the same reason: controls can only be evidenced across the surface you know about. For more, see what a SOC 2 exam means for you.

PCI DSS

PCI DSS is a private contractual standard maintained by the PCI Security Standards Council and enforced through acquiring-bank contracts. Requirement 6.2.3 covers the review of custom software before release, and requirement 11.3 covers vulnerability testing of systems in scope. Custom API endpoints are where payment logic lives, and proving them secure requires observing their behavior; SAST alone won’t cut it.

NIST CSF 2.0

The NIST Cybersecurity Framework is not a regulation but a common way to describe cybersecurity goals. Its six core functions (Govern, Identify, Protect, Detect, Respond and Recover) map to testing directly: discovery and inventory serve Identify, and evidence-backed findings serve Detect and Respond.

Denial-of-wallet attacks

A denial-of-wallet (DoW) attack drives up a target’s cloud bill by flooding metered, serverless endpoints with expensive requests until the cost itself becomes the damage. One of OWASP’s Top 10 API security vulnerabilities is catalogued as Unrestricted Resource Consumption, referring to the ability of code, malicious or benign, to overtax endpoints with deluges of requests.

One pattern is an endpoint whose cost scales with a parameter the caller controls, such as an export or search route that accepts an unbounded page size: GET /api/v1/reports/export?limit=1000000&include=all. A gateway rule that caps limit stops the obvious case. But when the cost depends on what the request makes the backend do (joins, fan-out calls, file generation), you have to run it to see the bill. Model-backed endpoints add a newer version of the same problem: each request can consume paid model tokens, so an endpoint without per-caller limits is a meter an attacker can run.

Gateways do not fully solve it either. Managed API gateways are typically billed per request, so each invocation can incur a charge even when the request is rejected. It’s like a robotic security guard that sends you a bill each time it gets kicked.

The imperative: secure the growing application attack surface

Every team ships applications now. Engineering ships faster with coding agents, and finance, HR, and operations ship software of their own. The application attack surface grows with every one of them, and coverage decays silently: security dashboards stay green not because the apps are safe, but because the newest apps were never onboarded.

That is the standard to hold an application security testing program to. It should discover applications and endpoints before it tests them, so the inventory reflects what actually runs. It should test the fully authenticated application, because that is where the data lives. It should hand back findings with the request and response evidence that makes them fixable, whether the fix is written by a developer or drafted by their agent and reviewed by a human. And it should reach applications, including the ones discovery finds, through whichever door fits: black box, gray box, CI/CD, or agent-native.

Security testing that covers only the applications someone remembered to register is not coverage. Schedule a demo with a NightVision security engineer to see what discovery-driven, evidence-backed testing looks like against your growing application attack surface, or compare plans to start on your own.

Frequently asked questions

Can DAST test API endpoints that aren't in my OpenAPI spec?

Only if the scanner discovers them first. A legacy DAST that relies on a spec or a crawl tests what is documented, and that leaves shadow, versioned, and deprecated routes untested. NightVision's API discovery reads source code in supported frameworks to map the routes your code declares, including those missing from any spec, then feeds that map into the API scan. You test the routes that actually exist, not a stale OpenAPI file.

What are shadow APIs and zombie APIs?

Shadow and zombie APIs are live, reachable endpoints absent from an application's official inventory. Shadow APIs are undocumented routes, while zombie APIs are older versions left operational. Maintained specs and traffic samples can miss them, so teams should combine inventory sources and test the running application.

How do you find the applications you need to test?

Start from your domain. Application discovery uses public sources such as certificate transparency logs and DNS to find the web apps and APIs tied to it, and you confirm which are yours before they become scan targets. NightVision app discovery is available on Enterprise.

What is a denial-of-wallet attack?

A denial-of-wallet (DoW) attack drives up a target's cloud bill by flooding metered, serverless endpoints with expensive requests until the cost itself becomes the damage. It maps to the OWASP API Security Top 10 (2023) category Unrestricted Resource Consumption (API4:2023). Static scanning can flag obvious examples, such as a route with no page-size cap, but cost that depends on runtime input often has to be exercised to be seen, which is where dynamic testing helps.

Does a DAST tool replace penetration testing?

No. NightVision's discovery-driven DAST automates a great deal of attack-style testing, runs continuously in CI/CD, and produces reproducible evidence, but no automated scanner is a complete replacement for a professional offensive security engagement. Multi-user authorization testing in particular, proving that user A can reach user B's objects (BOLA) or call functions reserved for admins (BFLA), depends on knowing who should own what, and remains largely a human discipline. Let DAST catch the common, repeatable issues on each build so human testers can focus on deeper, novel attack paths. The same logic applies to AI pentesting tools, which still need reproducible evidence and a human gate on the fix: see our CISO reality check on AI pentesting. For what each approach proves, and where PCI DSS treats scanning and pentesting as separate obligations, see DAST vs Penetration Testing.

How is next-gen DAST different from legacy DAST?

Legacy DAST crawls and guesses, so it misses single-page apps, stalls on authentication and state, and can leave a significant share of active endpoints untested. Next-gen DAST inverts the order: it discovers the real API surface first, then tests it with session-aware, stateful crawling and LLM-assisted form handling. It verifies findings with request and response evidence instead of pattern-only alerts, points API findings on source-discovered targets to the file and line that defines the affected endpoint (which we detail in Source-Linked DAST), tracks coverage across builds, and runs natively inside the pipeline with safe, rate-limit-aware defaults. That evidence requirement matters more as advisories themselves become cheap to generate: see SQLite Got a Critical CVE for a Vulnerability That Doesn't Exist for what happens when a finding arrives as a severity label with nothing behind it.

How does NightVision help with federal compliance such as FedRAMP, NIST, and EO 14028?

NightVision produces inputs that map to federal guidance rather than a compliance checkbox. Gray-box DAST operationalizes the "rigorous empirical testing" called for in OMB M-22-09, and its evidence-backed findings support FedRAMP control narratives across the AC, AU, CM, SC, and SI families. Source intelligence generates endpoint inventories and OpenAPI specs from source code, which supports NIST SP 800-204 policy scoping and the secure development practices EO 14028 emphasizes.

Do I still need SAST if I run DAST?

Yes, because neither approach sees everything. SAST reads code but cannot watch behavior, while DAST watches behavior but cannot read code, so each covers the other's blind spots. That is the whole premise of combining them. NightVision pairs discovery-driven DAST with source intelligence, which maps API routes and, for supported frameworks, how each route is protected. It is not a SAST suite and does not sell IAST or SCA, so a mature program still complements it with broader SAST and dependency coverage.

Can my coding agent run security scans?

Yes, if the scanner exposes agent-ready interfaces. NightVision publishes a public MCP server and open-source Agent Skills, so Claude Code, Codex, Cursor and other MCP-capable agents can launch a scan, read each finding's request and response evidence, draft a fix, and rescan to verify the finding is gone. The scan itself stays deterministic, and a human reviews and merges the change. See NightVision for coding agents.

Can application security testing cover AI and LLM endpoints?

Yes. Endpoints backed by a language model can be tested dynamically for whether the model can be steered into calling an attacker's server or reading the cloud metadata service. NightVision runs two AI endpoint security tests and reports a finding only with proof.

How do you stop false positives from coming back on every scan?

Make triage decisions persist. In NightVision, a finding you mark false positive stays marked in future scans of that app, while a finding marked resolved is reported again if the issue is still there.

Who security-tests apps built outside engineering?

The AppSec team does; the builders never need to touch a scanner. Finance dashboards, HR portals, low-code workflows, and AI-generated internal services are real applications with real APIs, and they rarely enter a security backlog on their own. Because a discovery-driven DAST platform like NightVision can test any reachable application black box from a URL, with authenticated coverage when credentials or a recorded login are provided, AppSec can onboard and test these apps without asking their builders to change how they work. See securing apps built outside engineering.

Sources

1. NIST SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture
2. NIST SP 800-207: Zero Trust Architecture (PDF)
3. NIST Cybersecurity Framework (CSF 2.0)
4. CISA Zero Trust Maturity Model
5. OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles (PDF)
6. FedRAMP program basics
7. OWASP API Security Top 10 (2023): API1:2023 Broken Object Level Authorization
8. OWASP API Security Top 10 (2023): API4:2023 Unrestricted Resource Consumption
9. OWASP API Security Top 10 (2023): API9:2023 Improper Inventory Management
10. PCI Security Standards Council
11. AICPA: SOC 2 and the Trust Services Criteria