Security policy.
SQUR runs offensive-security tooling. We value security research that helps us improve. This policy describes how to report a vulnerability and what to expect from us.
Scope
In scope
*.squr.aiproduction domainssqur-ai/*GitHub repositories- Authenticated and unauthenticated paths on
app.squr.ai - API endpoints at
api.squr.ai - The
asm.squr.aifree attack-surface scanner - Email infrastructure (
*.squr.aioutbound, cold-outreach campaign domain) - Open-source tools published under
squr-ai/*
Out of scope
- Third-party services we use (Resend, Firestore, Cloud Run, Statuspage.io) — please report to those vendors
- DNS misconfigurations not under SQUR control
- Issues requiring physical access to a SQUR-issued device
- Social-engineering attacks against SQUR employees
- Denial-of-service attacks (do not test)
- Issues on test/staging subdomains (
*-staging.squr.ai,*-dev.squr.ai) - Vulnerabilities in dependencies we cannot patch — please report upstream first
- Missing or "incomplete" email-authentication DNS records (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI) without a working spoofing or interception proof of concept
- Missing security headers, cookie flags, or CAA/DNSSEC records without a demonstrated exploit
- TLS/SSL configuration ratings and cipher-suite reports from online checkers
- Clickjacking on pages with no sensitive state-changing action
- Software version disclosure or raw automated tool output without a proven security impact
Reports in these categories are treated as informational. We may still fix them, but they do not qualify for acknowledgement SLAs, credit, or escalation.
How to report
GitHub security advisory
Open a private security advisory on the squr-ai/.github repo. We receive an immediate notification.
Email security@squr.ai
Include the vulnerability description, reproduction steps, your assessment of impact, and contact info. PGP key fingerprint on request — email us first.
Include in your report
- Clear description of the vulnerability
- Steps to reproduce, including any required setup
- The impact you assess (confidentiality / integrity / availability)
- Your name and a way to contact you
- Optional: a suggested fix
Do not publicly disclose the issue, share details outside SQUR, or attempt to access data belonging to other users while testing.
What to expect
| Stage | SLA | Action |
|---|---|---|
| Acknowledgement | 1 business day | We confirm receipt and assign a tracker ID |
| Initial assessment | 5 business days | We classify severity and confirm in-scope |
| Status updates | Every 14 days | Progress on remediation |
| Fix + disclosure | ≤ 90 days | We work with you on disclosure timeline |
| Credit (your request) | — | Hall-of-fame, CVE credit, blog mention |
We operate a 90-day coordinated disclosure window by default. We may extend for complex issues; we will not extend without your agreement.
Rewards
We do not operate a paid bug bounty and do not offer monetary rewards or compensation for reports. We credit valid, in-scope findings through our hall of fame, CVE credit where applicable, and blog mentions. Requests for payment as a condition of disclosure are not consistent with good-faith research under this policy.
Good-faith research is welcome.
If you act in good faith — accessing only what's necessary to demonstrate the issue, not accessing or modifying other users' data, not disrupting our services, and giving us reasonable time to fix — we will not pursue legal action and will work with you publicly to credit your finding.
We will not invoke the DMCA, computer-fraud statutes, or similar laws against good-faith research consistent with this policy.
Hall of fame
We publicly credit security researchers who help us improve. List forthcoming.