We’re upgrading our email infrastructure — for immediate response, email andrewjgaber@gmail.com meanwhile.
Skip to main content

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

2.2 Out of scope

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.

SeverityAcknowledgmentInitial assessmentTarget resolution
Critical24 hours (any day)72 hours30 days
High72 hours5 business days60 days
Medium5 business days10 business days90 days
Low / Info5 business days15 business daysNext 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:

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

  1. 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.
  2. Email: send to hello@citationsafe.com. Plaintext is fine; PGP is optional. Key at /pgp-key.txt.
  3. 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:

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.

Confirmation emails send from andrewjgaber@gmail.com while we upgrade infrastructure.

What is the vulnerability? What is the potential impact? (min 20 characters)

Step-by-step instructions or a curl command that demonstrates the issue.

Link to a screencap, exploit script, or PGP-encrypted attachment (Gist, Dropbox). For sensitive material, encrypt with our PGP key (/pgp-key.txt).

By submitting, you agree not to publicly disclose this finding until we coordinate disclosure timing per §5 of the policy above. Prefer email? Send to hello@citationsafe.com (PGP optional, key at /pgp-key.txt).