Internet exposure and attack surface

A vulnerable package that runs on something the internet can reach is more urgent than the same package in a batch job. Vulnetix answers “is this exposed?” for a finding by joining it to the cloud resources a connected cloud account reports.

The data comes from the cloud scan of a connected AWS account (see /cloud-security/). Without a connected account, every finding reads as not exposed, because nothing is known.

How a finding is matched

1. Repository. A cloud resource is attributed to a repository by the cloud scan (sourceRepoFullName). The finding’s repository must equal it. When the finding’s repository name has no owner (some CLI paths record a bare payments), the name after the slash is compared instead.
2. Publicly reachable. Read directly from the provider: RDS PubliclyAccessible, EKS endpointPublicAccess, an EC2 public IP.
3. Package. The cloud scan also records the software observed on each resource. The finding’s package matches when the purls agree with version, qualifiers and subpath removed, or, when either side has no purl, when the package name (case-insensitive) and ecosystem agree.

Match strengths

matchStrength	Means	Banner
package-on-resource	The finding’s package was observed on a publicly reachable resource attributed to its repository	red, “exposed” wording
repo	The repository has at least one publicly reachable resource, but the package was not observed on one	red, weaker wording
none	Nothing publicly reachable is attributed to the repository	none

Both exposed strengths are shown in red; the wording tells them apart.

The Attack Surface tab

The SCA finding page shows a banner when the finding is exposed, and an Attack Surface tab with two halves:

Half	Contains	Plan
Cloud	The attributed resources, their exposure paths (ingress kind, public IP or hostname, ports, how it was determined) and which of them carry the package	Pro and above (cloud integrations). On a lower plan the half is empty and cloudEntitled is false; the request does not fail.
Insights	The repository’s latest vulnetix analyze run: egress domains, public domains, maintainers, and the repository’s place on the tech stack graph	every plan

The page describes now; there is no time-shift.

Method	Path	Returns
GET	/v1/scanner-results/finding/{findingUuid}/attack-surface	repoName, internetExposed, matchStrength, cloudEntitled, counts {resources, exposed, packageMatches}, resources, domains {egress, public}, maintainers, insights
GET	/v1/scanner-results/finding/{findingUuid}	The finding, with attackSurface {internetExposed, matchStrength, resourceCount, exposedCount, topExposure} when the repository has any attributed resource

Using exposure to rank

Two risk strategy metrics apply the same match, so a finding tiered as exposed opens to a page that agrees:

Metric	Equals
INTERNET_EXPOSED_PACKAGE	matchStrength is package-on-resource
INTERNET_EXPOSED	matchStrength is repo or stronger

Put INTERNET_EXPOSED_PACKAGE above INTERNET_EXPOSED: it is the stronger claim. Neither is in the system default ladder.

Campaigns can also select on exposure with the scope filter exposure.internetExposed.

Related

• Asset relationships and labels for the graph the Insights half draws from
• /cloud-security/ for connecting an AWS account