Application security,
the whole web layer, continuously.
Every public application, login portal and API endpoint you expose, discovered and assessed from the outside. Security headers, exposed development environments, outdated frameworks and authentication surfaces an attacker would reach first.
CVEs prioritised with CVSS, EPSS and KEV, not ranked by count.
Application Security at a glance
What we observe
Public applications and APIs, missing security headers, exposed staging and admin interfaces, outdated framework versions.
How it's scored
Each observation maps to a published, versioned rubric. Click any score component to see the evidence behind it.
What happens next
Findings route to the application owner with remediation guidance, and the score moves when the fix is observable.
What we observe
- Subdomain enumeration and liveness across the estate
- Technology discovery on live hosts and high-signal paths
- CVE detection backed by NVD
- Security headers and their configuration
- Subresource integrity on third-party assets
What arrives on a finding
- CVSS, EPSS and KEV status on every CVE
- Prioritisation by what is actually being exploited
- The affected asset and how it was discovered
- Remediation with an SLA
- MITRE ATT&CK tactic and technique mapping
Anatomy of a finding
| Finding | Known-exploited CVE on a public application, on a subdomain not in your asset inventory |
| Evidence | The technology and version detected, and the path it was observed on |
| Why it matters | Presence on the KEV list means exploitation is confirmed in the wild, not theoretical |
| Who it affects | Anyone who can reach the host, which, being public, is everyone |
| Remediation | Patch or decommission; the asset was likely forgotten rather than accepted |
EPSS and KEV prioritised web application vulnerability findings
Application security from outside, without a login
External application assessment covers what a visitor's browser can see, which is less than a code review and considerably more than most organisations check.
Transport security first: TLS version and cipher configuration, certificate validity, chain problems, and expiry. Certificate expiry is worth its own mention because it is the single most common finding across every portfolio, it causes visible outages, and it is entirely preventable, an expired certificate on a payment subdomain is read by an assessor as a maintenance signal well beyond its direct risk.
Then security headers (content security policy, HSTS, frame options, referrer policy) and exposed application components: admin interfaces, API documentation published unintentionally, debug endpoints, version-disclosing responses, and JavaScript dependencies with known vulnerabilities.
What no external assessment can tell you about an application
Authorisation logic, business logic flaws, injection vulnerabilities behind authentication, and anything requiring a valid session are not externally observable. They need authenticated testing, and often source access.
This is the boundary worth being explicit about, because application security is where outside-in tooling is most often oversold. An organisation with a perfect external application score can still have a broken access control on an authenticated endpoint that hands one customer another customer's data, and that is frequently the finding that ends up in a breach notification.
So the module's honest role is hygiene and exposure rather than application assurance. It tells you your transport security is sound and nothing is exposed that should not be. It does not tell you the application is secure, and a vendor claiming their external scan does is describing something that cannot be done.
Hygiene findings correlate with everything else
The findings here are individually modest and collectively predictive. An organisation with expired certificates, missing HSTS, exposed debug endpoints and outdated JavaScript libraries is not usually an organisation with rigorous internal application security practice.
That correlation is why these findings carry weight in vendor assessment out of proportion to their direct severity. You are not primarily worried about the missing referrer policy. You are reading it as a signal about whether anybody is maintaining the estate, and in a context where you cannot see inside, observable maintenance discipline is one of the few honest proxies available.
It is also why remediation is worth doing even when each item looks trivial. The findings are cheap to fix, and fixing them changes what an assessor, an underwriter or a prospective enterprise customer concludes about the organisation behind them.
Common questions
Does this replace application penetration testing?
No. External assessment covers transport security, headers and exposed components. Authorisation logic, business logic flaws and anything behind a login require authenticated testing and often source access. Any vendor claiming an external scan secures an application is describing something that cannot be done.
What is the most common finding?
Certificate expiry, across every portfolio we assess. It causes visible outages, it is entirely preventable, and assessors read it as a maintenance signal well beyond its direct risk.
Why do security headers matter if they are not vulnerabilities?
Individually they are modest. Collectively they are predictive: an estate with missing headers, exposed debug endpoints and outdated JavaScript is rarely one with rigorous internal practice. In an assessment where you cannot see inside, observable maintenance discipline is one of the few honest proxies.
Do you check JavaScript dependencies?
Client-side libraries served publicly are identified and matched against known vulnerabilities. Server-side dependencies are not externally visible.
Can a good score here mean the application is secure?
No, and it is important to be clear about that. It means the externally observable layer is sound. Broken access control on an authenticated endpoint would not appear here, and that is a common source of real breaches.
Will fixing these findings clear them automatically?
Yes, on the next scan. Most are configuration changes rather than code changes, which is why they tend to be the fastest improvements available to a rating.
Where this connects
Network security module →
Services and versions across the external estate.
How scoring works →
How application hygiene findings are weighted.
Vendor onboarding →
Reading hygiene findings as a maintenance signal during evaluation.
Rate your own application security first
See what attackers and insurers see. Free for your own organisation.