Coordinated Vulnerability Disclosure Policy
Effective: August 21, 2026 (v0.1)
RFC 9116 contact card: /.well-known/security.txt
TL;DR: Found a real security bug in PixelProof, EntryProof, TariffWatch, or the shared Digital Empire infrastructure? Report it via the form at the bottom of this page, or email hello@citationsafe.com. We will not sue you for good-faith research within the scope defined below. We will acknowledge within 24 hours for critical severity, 5 business days otherwise. We will publicly credit you on our hall of fame with your consent after the fix ships.
1. Introduction and commitment
Digital Empire operates a portfolio of compliance-oriented SaaS products: PixelProof for Meta Conversions API integrity monitoring, EntryProof for CPSC electronic filings, TariffWatch for Section 232 metal-tariff exposure. Our customers are e-commerce operators, importers, and compliance officers who trust us with sensitive commercial data -- HTS classifications, purchase orders, pixel-fire logs, and payment metadata. Security is not an appendage to that trust; it is the trust.
We are a small, focused team, and we do not currently claim SOC 2 Type II certification, ISO 27001 attestation, or a 24/7 SOC. What we do claim is that we treat every credible external report as a first-priority issue, we do not hide behind legal threats when researchers act in good faith, and we ship fixes on the timelines committed below. This policy documents that commitment in operational terms so a researcher considering whether to report to us has predictable, published answers to every operational question that matters.
This is v0.1 of the policy. It is honest about what we can commit to today and where the gaps are -- formal attorney review, formal monetary bounty tiers, dedicated triage staffing -- rather than shipping an aspirational-but-fictional enterprise-grade program. When those gaps close, this document changes and the changes are dated at the bottom of the page.
2. Scope
2.1 In scope
- Any customer-facing web surface on
digital-empire-app.vercel.appor on the production custom domains for each product (pixelproof.*,entryproof.*,tariffwatch.*) -- landing pages, scanners, checkouts, admin dashboards, waitlist forms, help articles, comment-filing flows, inclusion-rebuttal drafting flows, retention pages, embed widgets. - All API routes under
/api/*on those hosts, including webhooks (/api/*/webhooks/stripe) and cron endpoints (/api/cron/*). - Chrome / browser-extension code shipped under Digital Empire branding (PixelProof extension, PriceProof extension, Meta Ad Fleet Monitor extension as they ship).
- Email flows sent from
hello@citationsafe.com-- SPF, DKIM, DMARC configuration; header injection in transactional templates; unsafe HTML in dynamically-generated email bodies. - Configuration flaws in the deployment pipeline that expose secrets, PII, or unauthorized-access paths -- misconfigured Vercel environment variables, leaked service-role Supabase keys in build logs, publicly-readable Storage buckets.
- Business-logic vulnerabilities in checkout, refund, referral, coupon, or admin-authorization flows (e.g. bypassing amount validation on
/api/*/checkout, replaying a webhook to double-credit a subscription, promoting a non-admin session to admin).
2.2 Out of scope
- Vulnerabilities in third-party services we integrate with -- Stripe, Supabase, Vercel, Resend, PostHog, Sentry, Cloudflare, GitHub. Report those directly to the vendor.
- Denial-of-service, volumetric attacks, distributed brute-force. Application-layer resource exhaustion tied to a specific code defect IS in scope; a botnet flooding our origin is not.
- Social engineering of Digital Empire staff, contractors, or customers.
- Physical attacks on Andy's workstation, office locations, or our vendors' data centers.
- Reports that consist entirely of automated scanner output without a demonstrated exploit or a concrete failure mode.
- SPF / DMARC / DNS-hygiene notes on domains we have already killed or are in the process of killing. If you are unsure whether a domain is live, ask.
- Missing security headers on marketing / blog / help subpaths where no state-changing operation exists.
- Rate-limit bypass on read-only endpoints where the underlying resource is public.
- Reports that require compromise of the reporter's own account or a colluding second account without demonstrating a cross-tenant impact.
3. Safe harbor
Digital Empire will not pursue civil action, initiate criminal complaint, or contact law enforcement in response to security research conducted in good faith and consistent with this policy. Research activities described here are authorized under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), and we consider such research to constitute authorized access. This aligns with the U.S. Department of Justice's May 19, 2022 revised policy on §1030 charging decisions (see the DOJ announcement), which directs federal prosecutors to decline prosecution of good-faith security research that avoids harm to individuals and the public.
"Good faith" for this program means: (a) you stay within the in-scope surface defined in §2.1; (b) you access only the minimum data necessary to demonstrate the issue; (c) you do not exfiltrate, retain, alter, or destroy production data belonging to Digital Empire or its customers beyond what is needed to prove the finding; (d) you do not degrade the service for other users; (e) you report the finding via §7 and give us the disclosure window in §5 before any public discussion; (f) you do not attempt to phish, social-engineer, or otherwise deceive Digital Empire personnel or customers.
Safe harbor cannot bind third parties -- if your testing incidentally affects a service Digital Empire uses (Stripe, Supabase, Vercel, an upstream DNS provider), that vendor's own terms and legal posture apply. Please scope your testing so it targets Digital Empire surfaces specifically. We cannot indemnify you against a third-party action.
If we believe in good faith that your testing has strayed outside this policy, our first action will be to email you at the address you provided and ask you to stop, not to file suit or contact law enforcement. Litigation and criminal referral are not our first, second, or third response.
4. Response SLAs
SLAs below are calendar targets measured from the timestamp of your submission. They apply to reports that meet the scope in §2 and provide enough detail for us to reproduce the issue. If your report does not include reproduction steps, we may spend our first response asking for them rather than acknowledging severity -- please include a minimum-viable reproduction in your first message.
| Severity | Acknowledgment | Initial assessment | Target resolution |
|---|---|---|---|
| Critical | 24 hours (any day) | 72 hours | 30 days |
| High | 72 hours | 5 business days | 60 days |
| Medium | 5 business days | 10 business days | 90 days |
| Low / Info | 5 business days | 15 business days | Next quarterly cycle |
We commit to at least one substantive status update every two weeks between acknowledgment and resolution -- no silent windows longer than that. If we miss an SLA, email us again; that means something dropped through, not that we lost interest. The first SLA (acknowledgment) is the one under which our own admin queue alerts us if a report goes stale (see §9).
5. Coordinated disclosure timing
We follow the coordinated-disclosure model: after acknowledgment, we ask you to hold public disclosure until either the fix has shipped and been verified in production, or 90 days have elapsed from your original report, whichever is earlier. If we need longer than 90 days for a genuinely difficult fix, we will proactively request an extension and provide a written justification; you retain the right to disclose after the original 90 days regardless.
When the fix ships, we will notify you with the commit SHA and the deploy URL. Once you have confirmed the fix, you are free to publish a write-up, CVE request, blog post, or conference talk with our full endorsement. We will link back to your write-up from the hall of fame if you provide the URL.
If you disclose publicly before the 90-day window expires and before we have shipped a fix, we reserve the right to accelerate our own advisory publication to protect our customers, which may include public confirmation of the finding and its exploitability. We do not consider this a punitive action; it is our responsibility to customers who may need to take defensive action of their own.
6. Bug bounty (v0 -- honest scope)
Digital Empire does not currently operate a monetary bug bounty program. We recognize this places us below the credibility bar of a HackerOne / Bugcrowd program, and we are honest about why: we are early-stage, our security budget is our own eyes plus this policy, and shipping a monetary bounty tier we cannot reliably fund would be worse than shipping none at all. What we DO offer, effective today:
- Public acknowledgment on the hall of fame with your preferred handle, a link back to your write-up, and the severity + vulnerability class of your finding, with your consent.
- Swag for confirmed medium-or-higher findings -- a Digital Empire t-shirt and sticker pack, shipped worldwide at our cost, when we ship the merch line (target Q4 2026).
- Discretionary cash thank-you for confirmed critical or high-severity findings, case-by-case, decided at time of resolution. Ask when you report if this matters to you; we will tell you upfront rather than after the fact. Historical range: $100 to $1,000, honestly.
PGP encryption is optional, not required. Plaintext email is fine; we use TLS-inbound Resend routing. If you prefer to encrypt, our PGP key (or an honest placeholder while Andy generates the real key) lives at /pgp-key.txt. We commit to publishing a formal monetary tier table (fixed dollar ranges per severity) once we cross $10K MRR and have the operational runway to fund it predictably. Until then, this section is what we can honestly commit to.
7. How to submit
- Web form (recommended): fill in the form below. Your submission goes directly to our triage queue and fires an alert to the operator. TLS 1.3, HSTS preloaded, per-request nonce-based CSP.
- Email: send to hello@citationsafe.com. Plaintext is fine; PGP is optional. Key at /pgp-key.txt.
- Private GitHub Security Advisory: open at empire-distribution/security/advisories/new. Visible only to Digital Empire maintainers and you.
Whichever channel you use, please include: (a) a summary of the vulnerability in one sentence, (b) the affected URL or component, (c) reproduction steps, (d) your best-guess severity classification (we may re-classify), (e) any impact analysis you can share, and (f) your preferred name / handle for public credit.
8. Ineligibility (what we don't consider a report)
The following do not draw against this policy's SLA and are not eligible for acknowledgment or discretionary thank-you. We appreciate the note but will treat it as informational, not as a program submission:
- Vulnerabilities in third-party services (see §2.2).
- "Best-practice" observations without a demonstrated exploit or concrete failure mode.
- SPF / DMARC / DKIM notes on domains we have already killed. If you are unsure whether a domain is live, ask before submitting.
- Reports generated entirely by an automated scanner with no manual verification, no exploit chain, and no impact analysis.
- Reports on staging or preview URLs (
*-*.vercel.apppreview builds) that do not reproduce on the production custom domains. - Volumetric / bandwidth-exhaustion "DDoS" reports without a specific code defect (see §2.2).
- Missing security headers on truly-static, no-state-change surfaces where the omitted header addresses no realistic attack.
9. Our own triage operations
Every submission creates a row in our internal portfolio.security_reports table (Supabase, RLS-enabled, service-role-only read/write). The row fires an alert to the operator's email plus a Slack channel we monitor. Our internal admin queue at /andy/security-reports (passkey-gated, WebAuthn) surfaces active reports sorted by severity and SLA breach, so we cannot silently drop a report through inbox neglect. If a critical report is unacknowledged after 24 hours, the queue flags it in red.
When a report resolves, we record the fix commit SHA on the row. If you consent to public credit, that SHA becomes the "fix commit" column on the hall of fame, so anyone can independently verify the fix landed.
10. Legal boilerplate
This policy is v0.1 and has not yet undergone formal outside-counsel review. We commit to a formal review before v1.0 (target Q1 2027). The safe harbor language in §3 reflects our operational intent and our reading of DOJ guidance; it is not, by itself, a contract, and it does not create rights enforceable against parties other than Digital Empire. Nothing here waives Digital Empire's rights against actors operating outside the good-faith scope defined in §3.
This policy is licensed under a permissive framework consistent with the disclose.io reference -- reuse and adapt for your own program if useful.
11. Contact
Email: hello@citationsafe.com
PGP key: /pgp-key.txt (currently a placeholder; see file for details)
RFC 9116 contact card: /.well-known/security.txt
Hall of fame: /hall-of-fame
Data Processing Agreement: /dpa
GitHub private advisory: empire-distribution/security/advisories/new
Digital Empire Holdings LLC - 30 N Gould St Ste N, Sheridan WY 82801
Submit a security report
Prefer email? Send to hello@citationsafe.com. This form submits over HTTPS with a per-request CSP nonce; your submission goes straight to our triage queue.