Security Policy

Supported versions

Security fixes apply to the currently deployed Static service and the app builds that service currently accepts. Modified or self-hosted deployments are not supported.

Reporting a vulnerability

Please report a suspected vulnerability privately to info@ceresemil.com with the subject Static security report. This is the preferred security contact. Please do not publish a report before we have had a reasonable opportunity to investigate and coordinate a response.

The canonical policy is https://static.ceresemil.com/security. Automated discovery is available at https://static.ceresemil.com/.well-known/security.txt. Static does not currently operate a bug-bounty program or promise payment.

Include, where available:

• the affected feature, public URL, and visible app or service version;
• clear reproduction steps and the security impact;
• a minimal proof of concept that avoids personal data and destructive actions;
• redacted request IDs, timestamps, logs, or screenshots;
• a safe way to contact you for follow-up.

Do not include authentication headers, sign-in links, device identifiers, private content, or unrelated user data. We aim to acknowledge a complete report within 5 business days and provide an initial assessment within 10 business days. These are targets, not guarantees. We will share material status changes when practical and discuss a reasonable disclosure timeline with the reporter.

For a confirmed vulnerability, we aim to provide a remediation target and request retesting when useful. We may publish an advisory or release note when appropriate for affected users. Credit is included only with the reporter’s consent. CVE handling depends on the issue and distribution model.

Safe research boundaries

Good-faith research must:

• use accounts and data you own or have explicit permission to test;
• stop immediately if you encounter another person’s data;
• avoid privacy violations, social engineering, credential theft, persistence, malware, denial of service, spam, and physical attacks;
• avoid automated account creation, resource-exhaustion, or high-volume testing without prior written approval;
• avoid modifying or deleting production data, bypassing payment systems, or degrading availability;
• keep request volume low, comply with rate limits, and report the issue promptly.

Ceres Emil does not intend to initiate legal action for good-faith research that stays within these boundaries. This statement does not cover deceptive, harmful, unlawful, or third-party conduct, and it does not create a payment commitment or waive any legal rights.

Secrets and sensitive evidence

Never send live credentials, authentication artifacts, private keys, payment or purchase evidence, personal content, or other sensitive data unless we have agreed on a safe transfer method. Redact sensitive values from all initial evidence. If a secret may have been exposed, say so in the private report so it can be revoked and rotated.

Out of scope

Issues limited to unsupported modified deployments, missing headers on non-production local development servers, self-XSS, theoretical findings without realistic impact, or unvalidated automated scanner output are generally out of scope. Older-build findings are still useful when they reproduce against or materially affect the current service. Product bugs without security impact should use normal support.