> For the complete documentation index, see [llms.txt](https://shellzerox.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shellzerox.gitbook.io/docs/security-reports/understanding-scan-results.md).

# Understanding Scan Results

Learn how to interpret SHELLZERO X scan reports, security indicators, and detected issues.

### Overview

SHELLZERO X scan results help you understand publicly observable aspects of a website's security configuration. Reports may include configuration checks, detected technologies, vulnerability matches, domain information, and other security indicators.

Understanding these results helps you identify issues that require verification and determine appropriate next steps.

### What a Scan Report May Include

| Result Category        | Description                                                                      |
| ---------------------- | -------------------------------------------------------------------------------- |
| Security Grade         | An overall indicator of the website's assessed security posture, where provided. |
| SSL/TLS                | Findings related to certificates and encryption configuration.                   |
| Security Headers       | Results for HTTP headers associated with browser security controls.              |
| Technology Detection   | Identified technologies and exposed software version information.                |
| Vulnerability Findings | Potential matches between detected technologies and known vulnerabilities.       |
| DNS and Email Security | Findings related to DNS records and email authentication.                        |
| Subdomain Security     | Discovered subdomains and potential configuration risks.                         |
| Reachability           | Website response behavior and related infrastructure information.                |

The categories displayed depend on the checks performed and the information available for the scanned domain.

### Understanding Finding Details

When reviewing an individual finding, focus on the following information where available:

* **Finding name:** Identifies the issue or configuration being reported.
* **Affected asset:** Indicates the domain, hostname, or component associated with the result.
* **Evidence:** Shows the observed information supporting the finding.
* **Severity:** Indicates the reported level of concern, if provided.
* **Recommendation:** Suggests a possible corrective action, where available.

Not every finding will contain all these fields.

### Interpreting Security Grades

If a scan includes an overall security grade, treat it as a summary of the checks performed rather than a complete measure of security.

A grade can help identify areas for further review, but it does not establish whether a website is exploitable, compromised, or fully protected.

Consider the underlying findings and the context of the website before making security decisions.

### Prioritizing Findings

Use the following factors to decide which issues to investigate first.

| Factor                | Consideration                                                                           |
| --------------------- | --------------------------------------------------------------------------------------- |
| Potential Impact      | Could the issue affect confidentiality, integrity, or availability?                     |
| Public Exposure       | Is the affected service accessible from the internet?                                   |
| Exploitation Evidence | Is there credible evidence that the vulnerability is actively exploited?                |
| Confidence            | Is the finding supported by clear evidence, or does it require additional verification? |
| Remediation           | Is a reliable fix or mitigation available?                                              |

A high-severity finding may deserve urgent attention, but the actual priority should reflect the system's exposure and business context.

### Recommended Review Workflow

1. Review the report's overall results.
2. Identify the findings that appear most significant.
3. Examine the evidence for each issue.
4. Verify the finding against the actual configuration or authoritative vendor information.
5. Apply an appropriate fix or mitigation.
6. Run another scan to check for changes.

Keep a record of important findings and remediation actions to support ongoing security reviews.

### Common Misinterpretations

**A clean scan means the website is secure.**

Not necessarily. Passive scans cannot identify every vulnerability, especially those requiring authentication, internal access, or application-level testing.

**A detected technology means it is vulnerable.**

Not necessarily. Vulnerability matches may depend on version detection and specific conditions that require verification.

**A security grade explains every risk.**

An overall grade summarizes selected checks. Review individual findings to understand the underlying issues.

**A finding confirms a compromise.**

A configuration issue or vulnerability match does not by itself prove that an attacker has accessed the system.

### Limitations

Scan results reflect the information and checks available at the time of assessment. Website configurations, software versions, and vulnerability intelligence can change.

Use scan reports as an aid to security assessment, alongside direct verification and appropriate technical review.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://shellzerox.gitbook.io/docs/security-reports/understanding-scan-results.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.