Service
Vulnerability Assessments
Full-estate discovery, triaged by real exploitability rather than raw CVSS.
A raw scanner export is not an assessment. A mid-sized estate produces thousands of findings, most of which are unreachable, already mitigated by something else, or irrelevant to how the system is actually deployed. The work is the triage: establishing which findings are exploitable in your environment, and putting them in the order a team can genuinely work through.
How this works
Discovery before scanning
A scan only covers what it is pointed at, so the first task is establishing what exists. Cloud inventory, DNS, certificate transparency, load balancer and ingress configuration, and the routing layer between them. The hosts that turn up here and not on the asset list are consistently the ones running something old, because nobody has been patching what nobody remembers owning.
Validation against your deployment
Every finding that reaches the report has been checked against how the software is actually configured. A vulnerable version behind authentication, with the affected feature disabled, is not the same finding as the same version exposed to the internet. This is where the volume comes down, and it is the difference between a list and an assessment.
Ordering by consequence
CVSS scores a vulnerability in the abstract. It does not know that one of your hosts holds the backups and another holds a marketing site. Findings are ordered by what exploitation would actually reach in your estate, which regularly promotes a medium above a critical and gives a team a queue worth working top down.
A baseline you can repeat
The output is structured so a later assessment can be compared against it: same identifiers, same asset naming, so the second run answers whether you are getting better rather than starting the argument again.
What we look for
- Internet-exposed services running versions with known, reachable exploits
- Assets absent from your inventory: forgotten subdomains, orphaned cloud resources, staging systems on public addresses
- Default and unchanged credentials on infrastructure and appliances
- Missing patches on the specific paths that are reachable, rather than every patch level in the estate
- Certificate and TLS configuration that will fail before someone notices
- Security controls present but not enforcing: logging without retention, MFA available but optional, backups untested
What you get
- Discovery across the estate, including the hosts nobody remembered
- Every finding validated against your deployment before it reaches the report
- A queue ordered by exploitability and consequence rather than by score
- Machine-readable output alongside the written report, so it can feed your own tracking
- A baseline that a later assessment can be measured against
What this does not include
- Exploitation beyond what is needed to confirm a finding is real
- Patching or configuration changes on your systems
- Continuous monitoring: this is a point-in-time assessment, and it says so on the front page
- Compliance certification, though the output maps cleanly into a compliance programme
Questions people ask
- How is this different from penetration testing?
- Breadth against depth. An assessment covers the whole estate and answers what is wrong. A penetration test covers a scope and answers what someone could do with it, including chains an assessment does not attempt. If you have done neither, an assessment first is usually the better spend.
- Can you work from our existing scanner output?
- Yes, and it saves time. The value added is the discovery of what your scanner is not pointed at, and the triage of what it returned. A large export with no triage is the normal starting condition rather than an unusual one.
- How often should this be repeated?
- That depends on how fast your estate changes rather than on a calendar. A stable estate gains little from monthly scanning; one where teams deploy new cloud resources weekly is out of date within a month. The baseline is built so the interval can be decided from evidence rather than habit.