AWCMS is a Bun + Astro 7 + PostgreSQL modular-monolith foundation for building ERP applications and business-integration solutions on top of it — it is not an ERP itself (ERP domain modules such as finance, inventory, and payroll live in separate extension/derived repos; see ADR-0022). Security reports should be handled privately and must not include production secrets, customer data, database dumps, access tokens, or screenshots that expose restricted information — this applies with extra weight given tenant business data handled here and, for derived ERP applications built on this foundation, financial/HR-payroll data.
| Version | Supported |
|---|---|
main / latest tagged release |
Yes — actively developed and supported |
| Older tagged releases (not latest) | Best-effort only; upgrading to latest is the primary remediation |
package.json is the release version (SemVer, Changesets-driven — see CHANGELOG.md). Contract (OpenAPI/AsyncAPI info.version) and module descriptor (src/modules/*/module.ts version/status) follow their own independent SemVer policy (see docs/adr/) 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/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 — including, for derived ERP applications built on this foundation, financial ledgers, payroll, tax/integration data
- 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, enforced on every tenant-scoped and business-entity-scoped table (including, for derived ERP applications built on this foundation, their own ERP domain tables).
- RBAC/ABAC default-deny access control on all non-public endpoints.
- Idempotency required on high-risk mutations (posting transactions, payroll runs, financial adjustments, integration syncs — the last two being concerns of derived ERP applications built on this foundation).
- Audit trail with redaction on sensitive business/financial actions.
- 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.
- External business-solution integrations (payment gateways, marketplaces, tax/Coretax, logistics providers) connect via outbox/queue, never direct synchronous calls from critical transaction paths.
- Triage privately and confirm the affected scope.
- Patch in the smallest safe scope.
- Add or update tests, docs, and audit notes when the issue changes behavior or operating procedure.
- Verify with available Bun commands and GitHub security checks.
- Publish an advisory only after the fix is available or an agreed disclosure window is reached.
Best-effort targets for good-faith private reports:
| Stage | Target |
|---|---|
| Acknowledge receipt | within 3 business days |
| Initial severity assessment | within 7 business days |
| Fix or mitigation plan | within 30 days for high/critical |
| Coordinated disclosure | after fix is available, or 90 days, whichever comes first |
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, ERP module security), CI/workflow configuration, dependency manifests, and 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 platform 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.