Advertised via security.txt
on every Preferium-managed Worker per RFC 9116 (R168).
Vulnerability Disclosure Policy
Last updated: 2026-05-19 Effective version: 1.0 (draft — pending legal review)
Preferium AS welcomes responsible reports of security vulnerabilities affecting Preferium AI Edge. This policy describes scope, safe harbor, the reporting channel, and our response commitments.
This policy is also advertised in machine-readable form at /.well-known/security.txt per RFC 9116.
1. Scope
In scope:
*.preferium.com(production)*.preferium.no(production)- Customer hostnames mapped to our edge Workers via Cloudflare for SaaS (CNAME flow), specifically vulnerabilities in OUR Worker code path — NOT customer-controlled content
- The
@preferium/edge,@preferium/api,@preferium/dashboardsource code in this repository
Out of scope:
- Customer-owned hostnames or content (report to the customer, not us)
- Third-party services (Cloudflare, Supabase, Stripe, Anthropic, etc.) — report directly to them
- Denial-of-service attacks
- Physical attacks against Preferium offices or staff
- Social engineering (phishing) against Preferium staff
- Vulnerabilities requiring physical access to a user’s device
- Self-XSS or vulnerabilities requiring fully MITM’d TLS
- Best-practice recommendations without a demonstrable exploit (e.g., “you should add header X”)
- Findings in test/staging environments unless they expose production credentials
- Issues already disclosed in our public advisories
2. Safe harbor
We will not pursue legal action against you for good-faith security research that:
- Stays within the in-scope section above
- Does not access or modify data belonging to other users beyond the minimum necessary to confirm the vulnerability
- Does not disrupt service for other users
- Does not exfiltrate personal data — confirm with the smallest possible proof and stop
- Does not publicly disclose details before we have had a reasonable opportunity to fix the issue (see §4 SLA)
- Complies with the Computer Misuse Act 1990 (UK), the Norwegian Penal Code §201 / §204 (Norway), and equivalent computer-misuse law in your jurisdiction
If you are unsure whether your testing is within scope, contact us first at security@preferium.com.
3. How to report
Preferred channel: Email security@preferium.com with:
- A clear description of the vulnerability
- Steps to reproduce
- Proof-of-concept (URL, payload, screenshot — minimal)
- Your name + contact + (optional) public Twitter/GitHub handle if you want public credit
- Whether you want public credit when the fix ships
Sensitive reports: for any report containing exploit payloads, customer data, or session tokens, email security@preferium.com first and we will arrange an encrypted channel before you send details.
Languages accepted: English, Norwegian.
We do not currently offer monetary bounties. A formal bug bounty program is planned for R175+.
4. Response SLA
| Stage | Target |
|---|---|
| Acknowledge receipt | 72 hours |
| Initial triage + severity | 7 days |
| Status update or fix shipped | 30 days |
| Coordinated disclosure | 90 days after acknowledgement, or upon fix shipping, whichever is earlier |
If we miss an SLA, we will tell you in advance and explain why.
5. Public credit
Researchers who report valid vulnerabilities and who request it will be publicly credited (with their consent) when the fix ships — name, date, and a one-line description of the vulnerability class (no exploit details).
6. Coordinated disclosure
We follow ISO/IEC 29147:2018 coordinated disclosure:
- You report privately to
security@preferium.com - We confirm + triage
- We fix
- We notify affected customers if customer data was at risk
- We agree a public disclosure timeline with you (default 90 days)
- Public advisory published (linked from this trust center) once disclosure is agreed
Contact
security@preferium.com — for sensitive payloads, email first and we will arrange an encrypted channel.
For non-security questions, see TERMS.md and PRIVACY.md.