Development Process & Standards

SyncMate — WYHEN Pty Ltd (ABN 57 688 078 999) Version 1.0 · Effective 31 August 2026 · Owner: Founder/Technical Operator · Review: annually Mapped to: OWASP SAMM v2, OWASP ASVS

1. Scope

Governs all changes to the SyncMate application, database schema, infrastructure configuration and third-party integrations.

2. Change lifecycle

1. Intake — every change originates as a tracked item (defect, enhancement, security finding) with a description, priority and owner.
2. Design — changes touching authentication, tenant isolation, file handling or a subprocessor require a written threat-model note before implementation (see A7 methodology).
3. Branch — one branch per change, named for the item. No direct commits to the production branch.
4. Implement — against the standards in section 4.
5. Review — every change is reviewed against the checklist in section 5 before merge.
6. Automated gates — type-check, lint, build and dependency/code security scan must all pass. Any Critical or High severity finding blocks the merge.
7. Preview verification — deployed to the preview environment and functionally verified, including an access-control check where the change touches data access.
8. Promotion — merged and deployed to production. Each release is traceable to its changeset.
9. Post-release — error and log review after deployment; rollback if regression is detected.

3. Rollback

Every release is a redeployable changeset. Rollback is performed by redeploying the immediately preceding release; target time under 1 hour. Database migrations are written to be additive where possible so that an application rollback does not require a schema rollback; where a destructive migration is unavoidable, a backup is taken immediately before it is applied.

4. Coding and data standards

• Authorisation before action. Every server-side entry point verifies the caller's identity and their membership of the workspace being acted on, before reading or writing data. Route-level guards are user experience, not the security boundary.
• Tenant isolation is enforced in the database. Every table holding customer data has Row-Level Security enabled with policies scoping rows to verified workspace members, plus explicit grants. A table without policies and grants must not be created.
• Roles are stored in a dedicated roles table, never on a user profile, and are checked through a security-definer function.
• Privileged (service-role) database access is used only in server-side code, only after the caller has been verified, and is never reachable from the browser bundle.
• Secrets live only in the managed secret store, are read at request time inside server-only handlers, and never appear in source, logs, error messages or client bundles.
• Input validation on every externally supplied value, with schema validation at server boundaries.
• Third-party tokens (e.g. Xero OAuth) are stored server-side and are never returned to the browser.
• Uploads are constrained by type and size, stored in isolated per-workspace storage, and are rendered, never executed. No public object URLs.
• Logging records who did what and when for administrative and data-affecting actions, and never records credentials, tokens or full document contents.

5. Code review checklist

A change may not merge until the reviewer confirms:

• Caller identity and workspace membership are verified before any data access.
• Any new table has RLS policies and explicit grants matching those policies.
• No secret, token or credential appears in source, logs or the client bundle.
• All external input is validated.
• No privileged database client is reachable from client code.
• Errors returned to users do not leak internal detail or other tenants' data.
• Automated gates pass with no Critical or High findings.
• Where the change touches auth, isolation or file handling, a threat-model note exists.

6. Database change control

Schema changes are made only through reviewed, version-controlled migrations. Each migration must include access policies and grants for any new object. Migrations are applied to preview first and verified before production. Ad-hoc manual changes to the production schema are prohibited.

7. Dependency management

Dependencies are scanned for known vulnerabilities on every change. Findings are remediated under the severity SLAs in the Vulnerability Management Policy (A6). New dependencies are assessed for maintenance status and licence before adoption.

8. OWASP SAMM v2 mapping