Vulnerability Disclosure Policy

Suggested public route: /security/vulnerability-disclosure (or fold into /security — see SECURITY.md §7) Effective: {{EFFECTIVE_DATE}}

1. Our commitment

HallPal treats security as a first-class responsibility. If you believe you've found a vulnerability in HallPal's dashboard, firmware, or infrastructure, we want to hear about it. This policy sets out how to report + what you can expect from us in return.

We commit to:

• Acknowledge your report within 5 business days.
• Assess the report within 10 business days + share our preliminary judgement on severity + validity.
• Fix confirmed vulnerabilities as fast as their severity warrants (see §5 for target timelines).
• Credit you publicly (if you want; anonymous is also fine) once the fix is deployed.
• Not pursue legal action against you for good-faith research conducted within the scope of this policy (see §3).

2. Scope

In scope:

• The web dashboard at hallpal.divz.io + any subdomain.
• The HallPal firmware running on Homebase (hallpass-esp32) + Pass (hallpass-slave-esp32) devices.
• The device-facing HTTP API under hallpal.divz.io/api/homebase/*.
• HallPal-controlled subdomains + services referenced from the dashboard.

Out of scope:

• Third-party services HallPal uses (Vercel, Cloudflare, Anthropic, Google, Resend, Supabase). Report those directly to the vendor; we'll cooperate.
• Physical attacks on HallPal offices or personnel.
• Social engineering of HallPal employees or customers.
• Denial-of-service attacks (including load-testing the site or API without prior written coordination).
• Any test that would risk degrading service for other users, or that would touch actual student data.
• Reports of missing "best practice" headers (e.g. missing Expect-CT) that have no exploitable path.

3. Safe harbor for good-faith research

If your research is conducted:

• In scope (see §2)
• In good faith (with intent to identify + report vulnerabilities, not to cause harm or exfiltrate data)
• Without accessing, modifying, or disclosing customer data beyond the minimum needed to demonstrate the vulnerability
• Without causing service degradation for other users
• Through this policy's reporting channel (§4)
• Without publicly disclosing the vulnerability before we've had a reasonable time to fix it (see §6)

then HallPal will:

• Not pursue civil or criminal action against you under the Computer Fraud and Abuse Act (CFAA), state computer-misuse laws, anti-scraping laws (e.g. Cal. Penal Code § 502), or the DMCA anti-circumvention provisions.
• Waive any breach-of-terms-of-service claim under our Terms of Service as it applies to the acts of research covered by this policy.
• Coordinate with you on public disclosure per §6.

This safe harbor is a limited commitment applicable only to acts that meet ALL of the above conditions. Acting outside those conditions is not covered.

4. How to report

Email security@hallpal.divz.io.

For sensitive reports, encrypt with our PGP key:

• Fingerprint: {{PGP_KEY_FINGERPRINT}}
• Public key: {{PGP_KEY_URL}}

Include:

• A clear description of the vulnerability.
• Steps to reproduce (screenshots, HTTP requests, PoC code fragments).
• The affected URL, endpoint, or firmware version.
• Your assessment of severity + potential impact.
• Whether you'd like credit for the finding (name / handle) or to remain anonymous.
• Whether you're subject to any coordinated-disclosure timeline that overrides §6.

5. Severity + response targets

We use the following severity + target-fix windows. These are targets, not contract terms — actual times depend on complexity.

Severity	Description	Target time to fix
Critical	Direct access to student data, remote code execution, session takeover, privilege escalation to platform-super	7 days
High	Access to another school's data, unauthenticated read of significant data, XSS on an authenticated page	30 days
Medium	Authenticated XSS with limited scope, IDOR to non-sensitive data, missing rate limit on a sensitive endpoint	90 days
Low	Missing security header without an exploit chain, verbose error messages, information disclosure without user impact	Best effort, batched with related work

6. Public disclosure timeline

We ask that you give us 90 days from your initial report to fix the vulnerability before you disclose it publicly. If we can't fix within 90 days, we'll:

• Explain why + share our updated timeline.
• Offer you an interim mitigation you can note in your disclosure.
• Coordinate the disclosure date + wording with you.

If we deploy the fix sooner + agree on a joint disclosure, you're welcome to publish immediately after deployment.

If we do NOT respond to your initial report within the 5-business-day window in §1, or if you've received no substantive update within 30 days, you may disclose publicly on your own timeline. This is the industry-standard escape hatch against unresponsive vendors + it applies to HallPal too.

7. Rewards

HallPal does not currently run a paid bug-bounty program. We recognize valid disclosures with:

• Public credit on our security page (see SECURITY.md), with your preferred name / handle / affiliation.
• A thank-you email from a HallPal engineer describing the fix.
• HallPal-branded swag at our discretion — send us an address after disclosure + we'll send something.

If we transition to a paid program later, past reporters may be retroactively considered at our discretion.

8. What we won't do

• We won't take legal action against you for research within the safe harbor.
• We won't share your report with anyone outside HallPal's security-response team without your permission.
• We won't ask you to sign an NDA in exchange for accepting your report.

9. Contact

Vulnerability reports: security@hallpal.divz.io General security questions: see SECURITY.md §8

---

Appendix: security.txt file contents

Publish the following at /.well-known/security.txt per RFC 9116. The file MUST be served at that exact path (with or without a hyphen) to be discoverable by security tools + researcher extensions. Content-Type: text/plain; charset=utf-8.

The file below is unsigned. For maximum trust, sign it with the security team's PGP key (gpg --clearsign security.txt produces security.txt.asc) and host the signed version at the same path.

# HallPal security disclosure

Contact: mailto:security@hallpal.divz.io
Contact: https://hallpal.divz.io/security/vulnerability-disclosure
Expires: {{EXPIRES_ISO_TIMESTAMP}}
Encryption: https://hallpal.divz.io/.well-known/pgp-key.txt
Preferred-Languages: en
Canonical: https://hallpal.divz.io/.well-known/security.txt
Policy: https://hallpal.divz.io/security/vulnerability-disclosure
Acknowledgments: https://hallpal.divz.io/security#acknowledgments

How to serve it in Next.js:

The simplest wire-up is a static file:

• Drop the file (with {{PLACEHOLDER}} values filled) into public/.well-known/security.txt. Next.js serves everything under public/ as static assets, so it becomes reachable at /.well-known/security.txt.

If you want dynamic values (e.g. rolling Expires: date):

• Add a route handler at app/.well-known/security.txt/route.ts that returns the file contents with Content-Type: text/plain.

Notes on the fields (per RFC 9116):

• Contact: — required. At least one. Email + a web form URL is the recommended shape.
• Expires: — required. Set to no more than 1 year in the future. Re-issue before it lapses; a stale Expires: invalidates the file for tools that check.
• Encryption: — recommended. URL to the PGP key.
• Preferred-Languages: — recommended.
• Canonical: — recommended.
• Policy: — recommended. Points to the human VDP.
• Acknowledgments: — recommended. Points to the security page section where past reporters are credited.

Add public/.well-known/security.txt.sig with the PGP-signed version if using signed distribution.