Application Exposure

Application Exposure connects the code you write to the things it runs on. An application is the unit: it has repositories behind it, environments it runs in, assets it deploys to, and findings from every kind of scanning.

That linkage is the point. A vulnerability in a library matters differently depending on whether the service using it is internet-facing, and neither a code scanner nor an infrastructure scanner can tell you that on its own.

Applications

An application ties together:

Attachment	What it gives you
Repositories	The source it is built from
Environments	Where it runs - production, staging, and so on
Asset mappings	The infrastructure it deploys to
Findings and risk	Everything found, rolled up

Asset rules

Mapping applications to assets by hand does not survive contact with a real estate: instances are replaced, resources are renamed, and a manual list ages from the moment it is written.

Asset rules map by rule instead - match on tags, naming, or cloud account - and resolve continuously in the background. An application's asset list stays current as infrastructure changes underneath it.

Prefer rules over manual mappings for anything that scales or is replaced automatically.

Repositories

Connect GitHub or Azure DevOps under Integrations. Repositories are discovered from the connection, then associated with applications.

Scanning

Three kinds, answering different questions:

Type	Question	Needs
SAST	Is the code we wrote unsafe?	Source access
SCA	Are the dependencies we use vulnerable?	Source access
DAST	Is the running application exploitable?	A reachable URL

SCA usually produces the most findings and the most actionable ones. Most applications carry far more third-party code than first-party, and a dependency upgrade is generally a smaller change than a code fix.

DAST is the one that tests reality. SAST and SCA reason about code; DAST exercises the deployed application and finds things only present once everything is assembled - misconfiguration, exposed endpoints, behaviour that only appears at runtime. It needs a URL the scanner can reach, which for internal applications means a scanner on a network that can see it.

Findings

Application findings land in the same queue as everything else, with the same severity scale, statuses and SLAs. See Findings and triage.

Two things specific to this area:

• One vulnerable dependency across forty services is forty findings. That is deliberate - each service is upgraded separately - but when it is genuinely one piece of work, group and act in bulk rather than forty times.
• Reachability matters more than severity here. A Critical in a code path nothing calls is less urgent than a High in a request handler. Severity does not know that; your environment and asset mappings do.

Getting started

1. Connect a source control integration.
2. Create an application and attach its repositories.
3. Add asset rules so it knows what it runs on.
4. Enable scanning. SCA first - it gives the most for the least setup.
5. Add DAST for anything with a reachable URL.

API

The endpoints behind this section are in the API reference.

Next

• Integrations - connecting source control
• Findings and triage - working the results
• Assets - how applications relate to infrastructure