AWCMS-Mini is the Bun + Astro 7 + PostgreSQL baseline for AhliWeb application development. Security reports should be handled privately and must not include production secrets, customer data, database dumps, access tokens, or screenshots that expose restricted information.

package.json is the release version (SemVer, Changesets-driven — see CHANGELOG.md). The base generic backlog (docs/awcms-mini/06_github_issues_detail.md, 18 issues) is complete, so there is no separate lower "first production-support target" version — the version currently released on main is the supported one. Contract (OpenAPI/AsyncAPI info.version) and module descriptor (src/modules/*/module.ts version/status) follow their own independent SemVer policy (ADR-0008, docs/adr/0008-independent-contract-and-module-versioning.md) and are not mechanically tied to the package release version.

Use GitHub private vulnerability reporting from the repository Security tab whenever possible:

https://github.com/ahliweb/awcms-mini/security/advisories/new

Include:

• affected file, workflow, dependency, or documented control
• reproduction steps or proof of concept using synthetic data only
• impact and affected security property
• suggested fix, if known

Do not open public issues for exploitable vulnerabilities. Public issues are acceptable only for non-sensitive hardening work that does not reveal an exploit path.

• Runtime and package manager: Bun.
• Backend platform: Bun-only; Node.js is not allowed unless a maintainer-approved, documented exception exists.
• Database target: PostgreSQL with RLS.
• Security automation: GitHub secret scanning, push protection, Dependabot alerts/security updates, and CodeQL code scanning.
• Repository policy: no real secrets, credentials, customer data, database dumps, or raw production logs in Git, issues, pull requests, or documentation.

1. Triage privately and confirm the affected scope.
2. Patch in the smallest safe scope.
3. Add or update tests, docs, and audit notes when the issue changes behavior or operating procedure.
4. Verify with available Bun commands and GitHub security checks.
5. Publish an advisory only after the fix is available or an agreed disclosure window is reached.

Best-effort targets for good-faith private reports:

These are goals, not guarantees; timelines depend on severity and complexity.

In scope: documented security controls and standards in this repository (RBAC/ABAC/RLS design, audit/masking rules, idempotency, sync HMAC), CI/workflow configuration, dependency manifests, and — once application code exists — the code under src/, server/, scripts/, and sql/.

Out of scope: third-party services and providers referenced only as optional integrations, findings that require a compromised host or physical access, and issues in example/illustrative domain content that do not affect the base standard.

We consider good-faith security research conducted under this policy to be authorized. If you make a good-faith effort to comply with this policy during your research, we will not pursue or support legal action against you for that research. Good faith includes: using only synthetic/test data, not accessing or modifying data you do not own, not degrading service for others, and giving us a reasonable time to remediate before any disclosure. If in doubt, ask first via the private advisory channel.

With your consent, we are happy to credit reporters in the advisory and release notes.