> 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-and-roadmap/responsible-use-and-limitations.md). # Responsible Use & Limitations Guidelines for using SHELLZERO X responsibly and understanding the limitations of automated security assessments. *** ### Overview SHELLZERO X provides website security assessments and vulnerability intelligence to help users identify potential weaknesses in publicly observable systems. Responsible use requires appropriate authorization, careful interpretation of findings, and an understanding of what automated security checks can and cannot establish. ### Authorized Use Only scan domains and systems that you own or have explicit permission to assess. Before conducting a scan: * Confirm that you are authorized to assess the target. * Understand any applicable organizational policies and third-party service terms. * Ensure your activities comply with applicable laws and regulations. * Avoid attempts to access, disrupt, or modify systems without authorization. Public accessibility does not automatically grant permission to perform intrusive testing. ### Understanding Passive Scanning Passive scanning examines publicly observable information without intentionally exploiting vulnerabilities or disrupting the target system. SHELLZERO X's website security checks focus on information such as: * SSL/TLS configuration. * HTTP security headers. * Publicly detectable technologies and software versions. * DNS and email authentication records. * Public certificate information and subdomains. * Website reachability and related infrastructure indicators. The precise scope depends on the checks available and the information exposed by the target. ### Important Limitations | Limitation | What It Means | | ------------------------ | ---------------------------------------------------------------------------------------------- | | Incomplete Visibility | Publicly observable information does not reveal every internal system or application weakness. | | False Positives | A reported issue may not apply to the target's actual configuration. | | False Negatives | Some issues may remain undetected because relevant information is unavailable. | | Version Uncertainty | Detected software versions may be incomplete or inaccurate. | | Changing Conditions | Configurations and vulnerability information can change after a scan. | | No Guarantee of Security | A clean report does not prove that a website is free from vulnerabilities. | ### Interpreting Findings Responsibly Treat scan results as indicators that may require additional investigation. Before making changes: 1. Review the evidence supporting the finding. 2. Confirm whether the issue applies to the affected environment. 3. Consult authoritative vendor documentation where relevant. 4. Evaluate the potential impact of the proposed correction. 5. Test changes where practical before applying them to production systems. Do not assume that a reported vulnerability confirms exploitation or that a security alert proves a compromise. ### Handling Sensitive Information Security findings can reveal information about an organization's infrastructure. * Share reports only with authorized recipients. * Avoid publishing sensitive technical details unnecessarily. * Protect account credentials and access tokens. * Follow applicable data protection requirements when storing or sharing scan results. * Report suspected vulnerabilities through appropriate, authorized channels. ### Responsible Disclosure If you identify a potential vulnerability affecting a third-party system, avoid exploiting it or accessing information beyond what is necessary and authorized. Where possible, notify the affected organization through its established security contact or vulnerability disclosure process. Provide enough information to explain the issue without unnecessarily exposing sensitive data. ### Final Considerations Automated security scanning is one component of an effective cybersecurity program. It should complement appropriate patch management, application testing, infrastructure monitoring, access controls, and incident response procedures. Users remain responsible for obtaining authorization, validating findings, and deciding how to address identified risks. --- # 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-and-roadmap/responsible-use-and-limitations.md?ask=&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.