Improve scan engine error classification to reduce false positives and ambiguous results

[S3DFX-CYBER]

During recent testing, some scan results were initially flagged as potential vulnerabilities but were later confirmed to be false positives due to environmental factors (intentional Docker behavior, outdated images, or network/SSL edge cases).

While these cases were handled correctly after manual investigation, the current scan engine does not clearly distinguish between:
genuine vulnerabilities
environmental misconfigurations
intentional design behavior
transient network or SSL handshake failures

This can lead to ambiguous results and additional manual verification effort for users.

Proposed improvement:
Improve error classification and reporting in the scan engine
Introduce clearer result states (e.g., confirmed issue, possible misconfiguration, environmental limitation)
Reduce false positives by improving exception handling and context-aware validation

Benefits:
Higher scan accuracy
Reduced false positives
Improved user trust in scan results
Better suitability for automated pipelines

[S3DFX-CYBER]

If you feel this is a legitimate issue that should be fixed , you can publicly assign me @securestep9 .

[pUrGe12]

Can you site some examples? I don't understand what you mean by "false positives due to environmental factors"

[S3DFX-CYBER]

Let me clarify your doubts @pUrGe12

by “false positives due to environmental factors” I mean cases where the scan result depends on how Nettacker is running, not on a real vulnerability in the target.

Examples:

TLS / connection behavior
Some targets fail TLS handshakes due to strict ciphers, SNI requirements, or timeouts.
In these cases, the scan may report a vulnerability or misconfiguration, while the issue is actually a client-side or network condition.

Docker vs local execution
Results can differ when running Nettacker via Docker versus a local build from master.
In a few cases, findings disappear when testing with the latest local code, which suggests the environment, not the target, caused the result.

WAF / rate limiting
Targets behind WAFs or CDNs often return generic errors (403/429/5xx).
Some scans may treat these responses as findings instead of defensive behavior.
Unstable network conditions
DNS resolution issues, packet loss, or connection resets can affect service detection and lead to inaccurate results.

Goal of this issue Improve how the scan engine handles these cases by:

distinguishing inconclusive / environment-related errors from confirmed findings
avoiding over-reporting when results are not reliable

If this is considered valid, I’m happy to work on a small, focused improvement.

[Aarush289]

Hi @S3DFX-CYBER ,
As you must have observed the issue through some scan , can you please give details to recreate that environment and test it to confirm that this indeed is an issue , We can't talk much on just theory basis as there can be so many small factors which may affect the results but the tendency to solve such issues lies on the how strong is this "may" , which means is it affecting the results actually , So can you please attach relevant details .

[S3DFX-CYBER]

Hi @Aarush289 , I completely agree—reproducibility is key to ensuring we aren't chasing ghosts.

To demonstrate how environmental factors currently skew results, here is a specific scenario you can test:

Scenario: False Positive via WAF/Rate Limiting

Target: Any site behind a strict WAF (e.g., Cloudflare) that triggers on high-frequency path probing.

Observation: When the WAF returns a 403 Forbidden or a 429 Too Many Requests, some modules in the current engine interpret the HTTP status code as a 'finding' (e.g., discovering a sensitive directory) rather than a defensive block.

The 'May' factor: This isn't theoretical—in a recent scan against a hardened Dockerized environment, the engine flagged 3 'high' vulnerabilities that were actually just custom 403 error pages served by the Nginx ingress.

Technical Evidence: You can recreate this by limiting the bandwidth on a local Docker container (tc qdisc add dev eth0 root netem delay 200ms) and running a scan. You'll see the engine struggle to differentiate between a 'Timeout' and a 'Closed Port,' often leading to ambiguous service detection.

My goal with PR #1196 is to introduce a more robust get_statics() validation so the engine asks, 'Is this a real file, or just a generic response from the server?' before reporting it.

[securestep9]

@S3DFX-CYBER what is described here is irrelevant to PR #1196 which is improving path validation - it has nothing to do with scenarios you are describing (WAF block/timeouts etc)