Skip to content

Security: aszender/commerce-sync-platform

Security

SECURITY.md

Security Policy

Project status

Commerce Sync Platform is a portfolio reference implementation, not a hosted service or a production-certified commerce platform. The local Docker Compose credentials are demonstration values and must never be reused outside local development.

The current release has known security boundaries:

  • Shopify-style webhook requests are HMAC validated.
  • Administrative sync and dead-letter endpoints require x-admin-api-key when configured and fail closed without ADMIN_API_KEY in production. User identity and role-based authorization are not implemented.
  • Tenant identity is currently supplied by requests/events; database row-level security is not configured.
  • Production secret management, TLS termination, and automated backup/restore are outside the current local deployment.

Do not expose the demonstration stack directly to an untrusted network.

Dependency audit

On 2026-07-25, compatible dependency updates were applied with npm audit fix. The remaining production findings are in the OpenTelemetry dependency family and require a coordinated breaking upgrade; development-only findings also remain in the Jest/ESLint/Drizzle toolchain. They are tracked rather than suppressed. CI runs an audit report so changes remain visible, but the portfolio build does not claim zero-vulnerability certification.

Supported versions

Until the first stable portfolio release, security fixes are applied only to the latest commit on main. No older release line is supported.

Version Supported
Latest main Yes
Older commits or forks No

Reporting a vulnerability

Please use GitHub's private vulnerability reporting feature for this repository, if enabled. Otherwise, contact the repository owner privately through the contact method on their GitHub profile.

Include, when possible:

  • affected endpoint, module, or dependency;
  • reproduction steps or a minimal proof of concept;
  • expected and observed behavior;
  • potential impact, including tenant or customer-data exposure;
  • suggested mitigation, if known.

Do not include real credentials, customer information, or production payloads. Please allow reasonable time for triage before public disclosure.

Response process

The maintainer will:

  1. acknowledge receipt when a private contact channel is available;
  2. reproduce and assess severity;
  3. prepare a fix and regression test;
  4. update affected documentation and dependencies;
  5. disclose the issue after remediation when disclosure is appropriate.

No response-time SLA is promised for this non-commercial portfolio project.

Security expectations for contributors

  • Never commit secrets or personal data.
  • Treat webhook payloads, logs, traces, and dead-letter records as potentially sensitive.
  • Use constant-time comparison for authentication material.
  • Enforce tenant access from trusted identity rather than request payload alone.
  • Protect operational endpoints before any non-local deployment.
  • Review dependency and container findings; do not silence them without a documented reason.

There aren't any published security advisories