Security and Vulnerability Disclosure

Effective date: September 22, 2026

This page describes how we protect client data and how we build securely, and how to report a vulnerability. It is written for clients, prospects and security researchers.

Seros is a solution development company. We do not currently operate a hosted customer-facing service: our website is static, and systems we build are normally deployed to infrastructure the client owns and controls. The controls below describe how we handle client material during an engagement, and the engineering practices we apply to what we build.

1. No certification is claimed

Seros, LLC does not hold SOC 2 Type I or Type II, ISO/IEC 27001, PCI DSS, HITRUST, or any other security certification or attestation. We do not claim compliance with any of them. If that changes, this page will say so and the report will be available under NDA.

We also do not currently offer a HIPAA Business Associate Agreement. Do not send protected health information to us or put it into a system we host without a separate signed agreement.

Saying this plainly is deliberate. A security page that implies certifications the company does not have is a misrepresentation, and enterprise security reviewers check.

2. How we build and run software

The controls below are limited to practices verified in our own application source and in how we run engagements. They are not a security certification, and they are not a promise about infrastructure a client operates themselves after handover.

Architecture - The product is designed for a multi-tenant application with tenant-scoped data access. - Production deployment uses Vercel-compatible hosting and durable PostgreSQL storage. - Local SQLite and fake providers are development and test modes, not production customer services.

Encryption and credentials - Application secrets are supplied through environment configuration and are not intended to be committed to source control. - Passwords are stored as password hashes rather than plaintext. - Transport encryption and encryption-at-rest are supplied by the hosting and database providers; they are verified against the production account before any client system goes live.

Access control and abuse prevention - In applications we build, tenant boundaries and connected integration scopes are enforced in application routes and database access helpers. - The application includes rate limiting and replay/idempotency protections for relevant request paths. - Session cookies are signed, HttpOnly and SameSite=Strict; production cookies also use Secure. Sessions expire after 12 hours, and password changes supersede older password-versioned sessions. - In systems we build, administrators on the client side control which sources are connected, who has access, and the human confirmation step before a consequential write. - SSO and MFA are not currently represented as implemented Seros customer features.

Development and response - Automated tests and type checks are part of the application verification workflow. - Audit events are recorded for relevant security and administrative activity. Retention and operational monitoring must be confirmed against the deployed environment. - Subprocessors are listed at Subprocessors. A vendor is added, with a signed DPA, before it processes client personal data.

AI providers - The default AI transport is local Ollama/Qwen. Customer content is limited to the relevant data needed for a generation, and AI output requires human review. - A hosted AI transport is optional. No hosted AI provider or provider-specific security promise is made here until one is selected and added to the subprocessor list.

3. Customer responsibilities

Security is shared. You are responsible for:

• Who you invite, what role you give them, and removing people who leave.
• Protecting credentials and API keys, and rotating them if exposed.
• Enabling multi-factor authentication or single sign-on for your users.
• Deciding which systems to connect and what scope to grant.
• Not putting prohibited data into a system we build or host, or sending it to us (see the Acceptable Use Policy).
• Reviewing AI output before acting on it.

4. Incident notification

If we become aware of a security incident affecting your data, we will notify you without undue delay and within 72 hours, with what we know at the time, and will update you as the investigation progresses. The contractual detail is in Section 9 of the DPA.

5. Vulnerability disclosure policy

We want to hear about security problems. This section is our commitment to researchers who act in good faith.

5.1 How to report

Email team@seros.dev with:

• A description of the issue and its impact.
• Steps to reproduce, ideally with a proof of concept.
• The URLs, endpoints, accounts and timestamps involved.
• Your name or handle, if you want credit.

Encrypt if you prefer: not published; email in plain text and we will arrange an encrypted channel if needed. Use one report per issue. We will publish a /.well-known/security.txt file pointing at this policy: https://seros.dev/.well-known/security.txt.

5.2 What we commit to

These are targets, not contractual commitments, unless a signed agreement says otherwise.

5.3 Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will:

• Consider your research authorised under the Computer Fraud and Abuse Act, applicable Georgia computer crime law, and any anti-circumvention provisions of the DMCA, to the extent those laws allow us to authorise it;
• Not pursue or support civil or criminal action against you for that research;
• Waive any claim that your research breached our Terms of Service or Acceptable Use Policy; and
• If a third party brings action against you for research conducted in accordance with this policy, make it known that your activity was authorised.

This authorisation extends only to us. We cannot authorise testing of systems owned by our subprocessors or by other third parties; report those to their owners. If legal action is initiated by a third party and you complied with this policy, we will make that clear.

If you are unsure whether something is in scope, ask first at team@seros.dev.

5.4 Scope

In scope - https://seros.dev and its subdomains that we operate. - The Seros web application and public API. - Our official mobile or desktop clients, if any exist.

Out of scope - Third-party services and infrastructure we do not control, including our hosting, payment, email and AI model providers. - Denial-of-service and volumetric testing. - Social engineering of staff, customers or vendors, and physical security testing. - Automated scanning that generates significant traffic, without written permission. - Reports generated solely by an automated tool with no analysis or demonstrated impact. - Findings that are configuration opinions rather than exploitable issues: missing security headers with no demonstrated impact, SPF/DMARC policy preferences, TLS cipher preferences, version disclosure, clickjacking on pages with no sensitive action, missing rate limits with no demonstrated abuse, self-XSS, and issues requiring a rooted device, a physically present attacker or an already-compromised account.

5.5 Rules

• Only test accounts and data you own or have explicit permission to test.
• Never access, modify, exfiltrate or delete another party's data. If you encounter personal data, stop, do not save it, and tell us in the report.
• Stop as soon as you have confirmed the vulnerability.
• Do not disclose publicly until we have fixed the issue, or until 90 days after your report, whichever comes first, and coordinate the wording with us.
• Do not demand payment in exchange for withholding a report. That is extortion, not research, and the safe harbour does not apply to it.

5.6 Rewards

We do not currently operate a paid bug bounty. We will credit researchers by name or handle in an acknowledgements list at https://seros.dev/security#56-rewards if they want it. Whether a bounty is introduced is no paid bounty at this stage; credit offered instead.