Skip to content

Latest commit

 

History

History
140 lines (99 loc) · 5.17 KB

File metadata and controls

140 lines (99 loc) · 5.17 KB

🛡️ Security Policy & Responsible Use

God's Eye is a serious offensive-security tool. It finds real vulnerabilities on real targets. Use it only on systems you own or have written permission to test.


Why this doc exists

God's Eye v2 can do damage. The same pipeline that surfaces a critical CVE correlation on your own asset will surface it just as well on your ex-employer's infrastructure — and the latter is a crime. This document sets the boundary between useful and illegal use, and it explains how to report vulnerabilities in the tool itself when you find them.


Responsible use

Ethical guidelines

DO:

  • Use for authorized penetration testing engagements
  • Participate in bug-bounty programs within their declared scope
  • Conduct security research on systems you own or have written permission to test
  • Help improve defense through responsible disclosure
  • Follow coordinated vulnerability-disclosure processes

DO NOT:

  • Scan systems without explicit permission
  • Chain vulnerabilities or exfiltrate data on targets you don't own
  • Violate bug-bounty program terms of service
  • Use God's Eye for initial access, lateral movement, or persistence on unauthorized systems
  • Sell or republish scan results without the asset owner's consent

Reporting Security Issues in God's Eye itself

If you discover a vulnerability in the tool (e.g., input injection via the CLI, SSRF in a fetch module, prompt injection against the AI layer), report it privately.

  1. DO NOT open a public GitHub issue.
  2. Email the maintainer or open a private security advisory on the repository.
  3. Include:
    • Affected component (package path + version or branch)
    • Reproduction steps
    • Impact assessment
    • Suggested fix if available

Response Timeline

Stage Target
Acknowledgment Within 48 hours
Initial assessment Within 7 days
Fix development Driven by severity (24h critical → 30d low)
Public disclosure After a patched release

Security Best Practices

For Users

  1. Always verify authorization before scanning.
  2. Keep the tool updated — v2 modules add new probe types that may break old rules of engagement you had in place.
  3. Scope the AI layer — AI modules send finding evidence to the LLM. With the default Ollama path this stays on your machine, but if you swap in a cloud provider later, make sure your ROE permits that.
  4. Respect rate limits — adaptive per-host limiting is built in, but some targets have hard ceilings; honor them.
  5. Secure your scan results — output files may contain exposed credentials, internal hostnames, CVE mappings.

For Contributors

  1. Review module code for SSRF, command injection, and path traversal before merging.
  2. Never log raw secrets. The secrets.Kind field is redacted by default; don't bypass redaction in new modules.
  3. Keep network-dependent tests behind -tags integration so CI doesn't leak traffic to third parties.
  4. Add new probe types to the ROE-impact note in the release changelog.

Compliance

Users must comply with all laws applicable to them, including:

  • United States — Computer Fraud and Abuse Act (CFAA), 18 U.S.C. § 1030
  • European Union — GDPR, NIS2 Directive
  • United Kingdom — Computer Misuse Act 1990
  • International — Budapest Convention on Cybercrime
  • Local — anything stricter than the above in your jurisdiction

Bug Bounty Programs

When using God's Eye in a bug-bounty context:

  1. Read the program's scope, including out-of-scope paths.
  2. Respect "no automated scanning" rules — several modules (brute-force, permutation, smuggling probe) qualify.
  3. Never test in production unless the program explicitly permits it.
  4. Submit findings through the program's channel, not publicly.
  5. Disclose only after authorization.

Data Protection

Scan results may contain sensitive information:

  • Private IP addresses and internal hostnames
  • Technology stack details with exact versions
  • Identified vulnerabilities and working PoCs
  • Cloud asset metadata

Your responsibilities:

  1. Encrypt scan results at rest.
  2. Delete them when no longer needed.
  3. Do not share outside the engagement without the asset owner's consent.
  4. Comply with data-protection laws applicable to the target's jurisdiction.

Disclaimer

NO WARRANTY: This software is provided "AS IS" without warranty of any kind.

NO LIABILITY: The author is not responsible for:

  • Misuse of this tool
  • Unauthorized access attempts
  • Legal consequences of improper use
  • Data breaches or service disruptions caused by your scans
  • Any damages arising from use

USER RESPONSIBILITY: You are solely responsible for ensuring:

  • You have proper authorization
  • Your use complies with all applicable laws
  • You accept all risks
  • You will not hold the author liable

Remember: unauthorized computer access is illegal. Always get written permission first.