Coretsia Framework is in active development.
- Prelude: implemented
- Phase 0 — Spikes and prototypes: implemented
- Phase 1 — Core: active development
- Stable production release: not available yet
Until the first stable public release is published, security handling is performed on a best-effort basis for the default development branch.
At the moment, Coretsia does not provide long-term-supported stable release lines.
| Version / line | Supported | Notes |
|---|---|---|
Default branch (main) |
Yes* | Best-effort fixes during active development |
Tagged Phase 0 snapshots (0.x) |
No | Historical implementation milestones, not stable support lines |
| Any older commit / fork / unpublished snapshot | No | Upgrade to the current default branch before reporting |
* "Supported" here means vulnerability reports are reviewed and may be fixed in the active development branch. It does not mean a stable security SLA is available.
Please do not open public GitHub issues for suspected security vulnerabilities.
Report vulnerabilities privately to:
Include, when possible:
- affected package(s) or path(s)
- exact version, tag, or commit hash
- PHP version and environment details
- minimal reproduction steps
- impact assessment
- any proof-of-concept or logs that help reproduce safely
For valid reports, the project will generally try to:
- acknowledge receipt;
- reproduce and assess severity;
- prepare a fix on the active development branch;
- publish the fix in the appropriate public commit or release note when ready.
Response and remediation timing is not guaranteed at this stage of the project.
Security reports are especially helpful for issues involving:
- unsafe file/path handling
- secret leakage or redaction bypasses
- authentication / authorization flaws
- request handling vulnerabilities
- dependency or supply-chain risks in shipped runtime/tooling code
- sandbox or boundary violations that break documented invariants
The following are usually out of scope unless they lead to a concrete exploitable weakness:
- purely theoretical concerns without a reproducible impact
- issues in unsupported historical snapshots
- local environment misconfiguration outside the repository defaults
- feature requests or general hardening suggestions without a vulnerability
Please allow time for investigation and remediation before any public disclosure.
Once the project has stable release lines, this policy can be expanded with version-specific support windows, coordinated disclosure timelines, and security advisory procedures.