Security & Responsible Disclosure

Digital Empire Holdings LLC builds compliance tooling (PixelProof, EntryProof, TariffWatch) for regulated sellers. If you find a security vulnerability in any of our products, we want to know before anyone else does. This page is our good-faith invitation to security researchers: report it responsibly, and we will fix it fast and credit you for finding it.

1. How to report

Email hello@citationsafe.com with:

The affected URL/endpoint and product.
Steps to reproduce (a proof-of-concept request/script is the fastest way to get triaged).
What you were able to access, modify, or observe that you shouldn't have been able to.
Your preferred contact method and, if you want public credit, the name/handle to use.

For anything involving real customer data (not your own test account), encrypt your report with our PGP key, see Section 6.

2. Scope

In scope:

digital-empire-app.vercel.app and all its routes (/meta-monitor, PixelProof, /cpsc-efile, EntryProof, /tariffwatch, TariffWatch, /andy/* internal admin).
Any *.digital-empire-app.vercel.app preview/alias subdomain (e.g. digital-empire-app-three.vercel.app).
Any future custom domain we point at this application (announced on this page when live).
Our public API routes under /api/* on the domains above.

Out of scope:

Social engineering of our team, contractors, or customers (phishing us to prove phishing works is not a finding).
Denial-of-service or load/stress testing of any kind, our rate limits are there for a reason; testing around them is out of scope even if you don't trigger an outage.
Spam, content injection into forms purely to prove a form accepts text, or SPF/DKIM/DMARC reports that don't demonstrate actual spoofing risk.
Findings in third-party vendors we use (Stripe, Supabase, Vercel, PostHog, Sentry, Resend, Apollo), report those directly to the vendor; see our sub-processor disclosure for the full list.
Missing security headers or best-practice suggestions with no demonstrated exploitability (we welcome the suggestion by email, but it won't be treated as a vulnerability report).
Vulnerabilities requiring physical access to a user's device, or a user's own already-compromised device/browser.
Reports from automated scanners with no manual verification or working proof-of-concept.

3. Response-time commitment

Acknowledgment: within 3 business days.
Initial triage/severity assessment: within 7 business days of acknowledgment.
Fix timeline: critical (real data exposure or account takeover), same-day mitigation, full fix within 7 days; high, 30 days; medium/low, next regular release cycle, typically within 90 days.
Status updates: we'll tell you where things stand at least every 2 weeks until resolved, not go silent.

This is a solo-founder-scale operation, these are honest commitments we intend to hit, not a 24/7 enterprise SOC's SLA. If we miss one, email again; it means something fell through, not that we stopped caring.

4. Safe harbor

We will not pursue legal action against a researcher who: stays within the scope above, makes a good-faith effort to avoid privacy violations and service disruption, does not access more data than necessary to demonstrate the issue, reports promptly and does not publicly disclose before we've had a reasonable chance to fix it (90 days from acknowledgment, or sooner if we confirm the fix is live), and does not exploit the finding beyond what's needed to prove it.

5. Recognition

Every confirmed, in-scope report earns a place in our researcher Hall of Fame below, with your name or handle (your choice) and the product affected. We do not currently run a fixed-payout bug bounty program, we're too early-stage to publish a bounty table we can't guarantee. For a confirmed critical or high-severity finding, we consider a discretionary cash thank-you case-by-case; ask when you report if that matters to you, and we'll tell you upfront rather than after the fact.

Hall of Fame

No confirmed reports yet as of August 13, 2026, be the first. Reporters who ask to stay anonymous are thanked here without a name.

6. PGP key for encrypted disclosure

For reports involving real customer data or exploit details you don't want in plaintext email, encrypt to:

Fingerprint: AF63 DB28 6D55 DA1A C3C7 22CE 28A7 5102 0622 6D37

Full public key: /.well-known/pgp-key.txt (also published via the Encryption field of our /.well-known/security.txt, per RFC 9116).

7. Our own security practices

We hold ourselves to the same standard we ask researchers to help us meet: every request goes over HTTPS with HSTS preload; a per-request nonce-based Content-Security-Policy blocks inline script injection; CSRF-protected origin checks guard every state-changing POST endpoint; row-level security is enabled on every Supabase table so a compromised API key can't read across tenants; and rate limiting sits in front of every public-facing scan/checker endpoint to blunt abuse. None of that makes us unhackable -- it's why we run this program instead of pretending we don't need one.

8. Why the out-of-scope list exists

Social engineering, DDoS, and spam are excluded from scope not because they're unimportant, but because they don't map to a fixable code defect the way an injection or auth-bypass bug does -- reporting "I could email your support address" doesn't give us anything actionable to patch. Reports that demonstrate a real application-layer weakness (broken access control, injection, auth bypass, sensitive data exposure, insecure direct object references) are exactly what this program exists for.