What separates a safe vulnerability-scanner check from an intrusive or denial-of-service check, and what does restricting a scan to safe checks cost in accuracy?
answer
- observe versus exercise the flaw
- proof versus inference
- what safe mode falls back to
- report uncertain findings or suppress them
basics
~20 sA safe check decides from observation — a banner, a version, a harmless response — while an intrusive check exercises the flaw and can crash or change the service. Safe-only scans replace proof with inference: more uncertain findings, some flaws missed.
solid answer
~50 sChecks differ in how they reach a verdict. A **safe** check observes: it reads a banner or version, sends a well-formed request and inspects the answer, or reads an installed version locally. An **intrusive** check sends what the flaw needs — a malformed or oversized input, a real exploitation attempt — and judges by the result; a **denial-of-service** check confirms the flaw by seeing whether the service stops responding. Scanners commonly ship with safe checks enabled by default, and in that mode many checks that would otherwise exercise a flaw fall back to banner and version inference. The cost is proof: findings now inherit inference's false positives (backported or rewritten banners) and false negatives (hidden versions), and flaws with no version signal may go unreported. A separate reporting-sensitivity setting then decides whether an uncertain inference is reported or suppressed.
go deeper
Recall the split: safe checks observe banners, versions and harmless responses, while intrusive and denial-of-service checks exercise the flaw and can disturb the service.
Explain why safe mode changes accuracy: checks fall back to version inference, bringing its false positives and false negatives, and the reporting-sensitivity setting decides whether uncertain findings appear.
Show judgement about when inference is not good enough — disputed criticals, configuration-only mitigations — and how you would obtain proof without risking production.
Weigh proof against availability for the estate: which classes of findings you accept as inferred, and what evidence standard a disputed critical must meet before it is closed.
## Three ways a check can reach a verdict Every vulnerability check is a small procedure: collect evidence, apply a rule, report. What separates check types is **how much the evidence-gathering touches the target**. | Check type | What it sends | How it decides | Risk to the target | |---|---|---|---| | **Safe** (observational) | Normal client traffic, or local reads with credentials | Banner, version, response shape, installed version | Low | | **Intrusive** | Malformed or oversized input, an exploitation attempt | Whether the flaw's behaviour actually occurred | May change state or crash the service | | **Denial-of-service** | Input designed to exhaust or crash the service | Whether the service stops responding | Outage by design if the flaw is present | An intrusive check produces **proof**: the flaw was there because it behaved like the flaw. A safe check produces **inference**: the flaw is probably there because the evidence matches a pattern. ## What "safe" does and does not guarantee Scanners commonly ship with a safe-checks option enabled by default, which excludes the checks whose authors judged them capable of harming the target. That option is a strong default, but it is a judgement, not a guarantee: - It describes the *check*, not the *target*. A fragile embedded device or an old network stack can misbehave under ordinary, well-formed traffic, or under the port discovery that precedes the checks. - It does not limit load. Thousands of safe checks in parallel are still thousands of connections. - It says nothing about credentials. A credentialed scan is not intrusive because it logs in; local checks are mostly reads. ## What restricting a scan to safe checks costs In safe mode, many checks that would otherwise exercise a flaw fall back to banner and version comparison. The accuracy cost follows directly from that substitution: 1. **More false positives.** Every weakness of version inference returns: backported fixes that leave the advertised version unchanged, banners rewritten by a proxy, version strings that do not reflect a configuration workaround. 2. **More false negatives.** If a service hides its version, the inference has nothing to match, and the check reports nothing — which reads exactly like a clean result. 3. **Some flaws go unreported.** A flaw that depends on configuration or behaviour, with no version signal at all, can only be confirmed by exercising it; with that forbidden, the check either does not run or cannot conclude. The trade is usually worth it on production systems — the point is to know whether the cost is being paid. ## The reporting-sensitivity dial Because inference is uncertain, scanners commonly expose a separate setting for what to do when a check **cannot confirm** a flaw: - **Report every possible finding** — maximum recall, more false positives for someone to triage. - **Avoid potential false alarms** — report only when the evidence is unambiguous, accepting that some real flaws stay silent. - **A middle setting** — the scanner's normal balance between the two. This dial is independent of safe checks. A safe-only scan set to report everything is the noisiest configuration; a safe-only scan set to avoid false alarms is the quietest and the most likely to miss something. ## When proof is worth the risk There are cases where inference is not good enough, and an intrusive check is the right tool: - A critical finding is disputed and the owners cannot produce local evidence either way. - A mitigation is configuration-only (a disabled feature, a filtering rule) and leaves the version string unchanged, so only behaviour can show whether it works. - A replica or staging copy exists where a crash costs nothing. Even then, it is run deliberately, against named targets, with the owner's agreement — how that is scheduled belongs to running the scan programme, not to how a check decides. ## What to take away Safe and intrusive describe **how a check gathers evidence**, and that decides the **kind of answer** it can give: inference or proof. Safe mode protects the target by accepting inference's errors in both directions; the reporting-sensitivity setting then chooses which of those errors you prefer to see. A candidate who can say which of their findings are inferred, and why, understands their scanner.
- Is a safe check guaranteed not to affect the target?No. Safe means the check's author judged it non-destructive for a normally behaving service. Fragile embedded devices, old network stacks and some industrial controllers can misbehave under ordinary, well-formed traffic, including the port discovery that precedes the checks. Safe mode lowers the risk; it does not remove it, and it does nothing about the total load a scan generates.
- Why can a safe-mode scan miss a flaw entirely rather than flag it?Some flaws have no version signal from outside: the service hides its version, or the bug depends on configuration the banner does not reveal. If the only way to tell is to trigger the flaw and safe mode forbids that, the check cannot conclude and reports nothing — a false negative indistinguishable from a clean result.
saying these in an interview costs you the question
- Safe checks cannot affect the target in any way.
- Intrusive checks are just slower versions of the safe ones.
- A safe-mode finding proves the flaw rather than inferring it.
- Turning safe checks off only adds denial-of-service tests.
- A credentialed scan is always intrusive because it logs in.