Offensive Services

Vulnerability Scanning

New vulnerabilities are published worldwide every day. Most do not concern you. Some do — and the only question is whether you learn about them before the attacker does. A vulnerability scan continuously matches your systems against those publications and tells you which of them are actually open in your organisation.

The distinction

What a scan delivers — and where it stops

A scanner works against a catalogue: known weaknesses, published as CVE, rated by CVSS. It checks your systems against that catalogue and reports the matches. That is thorough, fast and repeatable at will — which makes it the method of choice for continuous monitoring.

What it cannot do is form chains. A scanner sees the unpatched test system and the over-privileged service account — but not that together they form a path into the customer database. That takes a person who understands your organisation. It is the job of the penetration test.

The two methods are therefore not alternatives but companions: the scan maintains basic hygiene all year round, the test examines once or twice a year what the scan fundamentally cannot see. Test only, and you are blind for eleven months. Scan only, and you never find the interesting cases.

A dark building appears transparent, its internal structure visible as a fine lattice. A horizontal line of light travels across it; where it meets a weakness, a point lights up.

The scope

What we examine

A scan is only as good as its field of view. We therefore start at four points — beginning with taking stock, because what nobody knows about, nobody checks.

The outer skin

Everything reachable from outside: web servers, mail servers, VPN access, exposed management interfaces. We regularly find systems here that nobody in the organisation remembered — the test instance from two years ago, the subdomain of a discontinued campaign.

The internal network

From inside the picture differs. We scan with credentials, not just from the outside in: only the authenticated scan sees the actual patch level, installed software and misconfigurations. A scan without credentials is guessing.

Web applications

Your own and purchased applications are examined separately — against the usual classes of flaw and against known gaps in the libraries in use. The dependencies in particular are the blind spot: your application is current, the framework underneath is not.

Cloud configuration

In the cloud, most incidents arise not from gaps but from settings: an open storage bucket, an over-broad permission, a security group open to every address. This check runs against the providers' guidance and against your own.

The real problem

Why most scan reports go unread

In a mid-sized network a scanner readily finds several thousand results. Put that list on the table unprocessed and reliably nothing happens: it is too long, too technical, and it does not say where to begin. The report goes into the folder, and the next scan says the same thing.

So we do not deliver a raw list. Every finding is assessed against your situation: is the system reachable from outside? Does it process data worth protecting? Is exploit code known? A critically rated gap on an isolated test system is less urgent than a medium one on the payment server — the catalogue value alone does not say that.

What remains is a list that can be worked through. We filter out false positives beforehand rather than leaving them to you.

Only those who measure can see the direction

The process

From finding to closed vulnerability

What happens when a scan finds something serious — say a critical gap in your shop? Not a call at midnight, but a process both sides know.

daily: automated check of the outer skin
weekly: full scan of the internal network
24 hours: notification deadline for critical findings
1–2×: penetration test per year alongside

01
Notification — for critical findings on the same day, naming the system affected, the gap, and an assessment of how urgent it is.
02
Context — what the finding means for your business: which data would be affected, which processes would stop, whether it is already being exploited.
03
Instructions — the concrete route to remediation, described for your environment. Not a pointer to a vendor advisory, but the steps.
04
Rescan — after remediation we check specifically. Only then is the finding considered closed.
05
Prevention — where the same class of flaw recurs, we talk about the cause rather than the individual case.

Compliance

What the evidence is worth

NIS2 and ISO 27001 both require managed vulnerability handling — not merely scanning, but demonstrable treatment of the result. That is exactly what emerges here as a by-product: an unbroken history of when something was found, assessed, remediated and verified.

If you want to place that history in an overall position, you will find it again in Sightadel under the network and endpoint domains. The security score shows the development over time — the same figure for auditors, insurers and your own board.

In closing

Known gaps are the cheapest gaps

The vast majority of successful attacks use not an unknown vulnerability but one for which a fix has existed for months. That is the bad news — and at the same time the good: this part of the risk can be reduced with reasonable effort, long before the hard cases come into play.

Talk to us about scope and cadence. For a first scan of the outer skin we need nothing more than your domains.

FAQ

Frequently asked questions

What is the difference from a penetration test?

The scan checks automatically against a catalogue of known vulnerabilities and runs continuously. The penetration test is manual work, finds chains and business-logic flaws that appear in no catalogue — and is correspondingly more costly. Both make sense: the scan as continuous operation, the test once or twice a year.

Does scanning disrupt operations?

Normally not. Scans of the outer skin run at throttled speed, internal scans by arrangement outside peak hours. For sensitive systems — older controllers, medical devices — we agree gentler methods or take them out of the automated run.

Why do you need credentials for the internal scan?

Without authentication the scanner only sees what a system shows outwardly and infers the version from that. This produces false results in both directions. Authenticated, it reads the actual state. The accounts need read access only and are disabled again after the scan.

How do you handle false positives?

We filter them out before handover. What you receive is confirmed. A report in which every third entry is wrong costs your team more time than it saves — and ensures nobody looks at the next one.

Can we scan only the externally reachable systems?

Yes, and that is the usual entry point. Your domains are enough, there is nothing to install. The internal examination can be added later, once the benefit is visible.

Offensive Services

Reputation takes years. Destruction takes seconds.

Talk to us before somebody else does. The first conversation is free and we reply the same business day.

Send an inquiry Call in an emergency