We take security seriously and appreciate responsible disclosures. If you believe you’ve found a vulnerability, please follow the process below.

• Supported Versions
• Reporting a Vulnerability
• Our Process & Timelines
• Severity Guidance
• Coordinated Disclosure
• Scope
  • In scope
  • Out of scope
• Non-qualifying Reports
• Questions

We currently provide security fixes for the latest minor release line and the main branch.

Note This project is pre‑1.0. Public APIs and contracts may evolve quickly. Please upgrade to the latest release before reporting issues whenever possible.

Do not open a public issue.

Use one of the following private disclosure channels:

1. GitHub Security Advisory (preferred) Use Security → Advisories → Report a vulnerability in this repository.

2. Email Send details to baris.sayli@gmail.com with subject:

   SECURITY: <short summary>
   

Please include:

• A clear description of the issue and its potential impact
• A minimal proof‑of‑concept (PoC) or reproduction steps
• Affected version(s) (tag or commit hash)
• Environment details if relevant
• Suggested remediation ideas (optional but welcome)

We aim to handle reports responsibly, transparently, and without unnecessary delay.

• Acknowledgement: typically within a few days
• Triage & Reproduction: prioritized based on severity and scope
• Fix Planning: aligned with impact, determinism, and contract stability
• Release: fixes are published once validated

For sensitive issues, coordinated disclosure may be used. Reporters are kept informed at key milestones.

We follow a pragmatic, CVSS‑inspired classification:

• Critical / High Remote code execution, authentication bypass, or vulnerabilities enabling broad compromise

• Medium Information disclosure, privilege escalation, or DoS limited to a single service or boundary

• Low Hardening gaps, misconfigurations, or limited edge‑case misuse

Severity directly influences prioritization and release timing.

• We prefer coordinated disclosure. Please do not share details publicly before a fix is released.
• With your consent, reporters may be credited in release notes or acknowledgements.

• api-contract Shared response, paging, and error contracts (ServiceResponse<T>, Meta, Page, RFC 9457 extensions)

• customer-service Spring Boot server / OpenAPI producer

• customer-service-client Generated client, template overlays, and client‑side adapters

• OpenAPI templates, schema customizers, and build instructions contained in this repository

• Vulnerabilities exclusively caused by third‑party dependencies (report upstream first)
• Demo or test‑only code not used in production contexts
• Deployment‑specific misconfigurations outside this repository

To keep focus on impactful issues, we generally exclude:

• Best‑practice recommendations without a realistic exploit scenario
• Generic rate‑limiting or DoS reports without novel attack vectors
• Missing security headers in demo or development endpoints
• Social engineering or physical attack scenarios
• Issues that require modifying generated code directly instead of templates or shared contracts

Important Generated code is treated as disposable output. Security fixes must target contracts, templates, or generators, not generated artifacts.

If you’re unsure whether something qualifies as a security issue, contact:

baris.sayli@gmail.com

We’re happy to help triage before a formal report.

Thank you for helping keep the community safe 🙏

This policy reflects the project’s core principle:

Security, like API contracts, should be addressed at clear boundaries — not patched as an afterthought.