Secure Software Development and Product Security

2026.1

Changineers development team follows the latest security best practices when developing software, and automates security testing throughout development lifecycle whenever possible.

Security is integrated into all phases of Changineers product development lifecycle, including:

• Secure Design:

  • App Risk classification
  • Security req definition
  • Secure application design / RFC
  • Threat modeling
  • App data flow analysis

• Secure Development and Testing:

  • Secure coding guidelines
  • Peer review

  • Security testing, for example:

    • Linting with security rules
    • Open source security analysis
    • Static secure code analysis
    • Dynamic security analysis
    • Penetration testing

  • Responsible vulnerability disclosure / bug bounty program

• Remediation:

  • Follows defined vulnerability management lifecycle
  • Ensures no high risk security vulnerability is in production

Details about the Changineers software application architecture and security are documented in the Security Architecture and Operating Model.

Policy Statements

Changineers policy requires that:

(a) Changineers software engineering and product development is required to follow security best practices. Product should be “Secure by Design” and “Secure by Default”.

(b) Quality assurance activities must be performed. This may include

• peer code reviews prior to merging new code into the main development branch (e.g. master branch); and
• thorough product testing before releasing to production (e.g. unit testing, integration testing, and UI-based testing).

(c) Risk assessment activities (i.e. threat modeling) must be performed for a new product or major changes to an existing product.

(d) Security requirements must be defined, tracked, and implemented.

(e) Security analysis must be performed for any open source software and/or third-party components and dependencies included in Changineers software products.

(f) Static application security testing (SAST) must be performed throughout development and prior to each release.

(g) Dynamic application security testing (DAST) must be performed prior to each release.

(h) All critical or high severity security findings must be remediated prior to each release.

(i) All critical or high severity vulnerabilities discovered post release must be remediated in the next release or within the defined, predetermined timeframe.

(j) Any exception to the remediation of a finding must be documented and approved by the security team.

Controls and Procedures

Source Code Management

Changineers development/engineering team uses GitHub for source code management. Access to GitHub and its configuration standards include:

• All developers must authenticate to gain access to GitHub and code repos hosted on GitHub according to standards and procedures defined in the Access Policy:

• Access control to the GitHub web interface must be enabled, via SSO and/or MFA if applicable.

• SSH public/private key access may be used for command line or git access to the code repositories.

• All code repositories in GitHub follow these configuration standards:

  • All repos must have an owner identified and listed

  • All repos are by default private

• Releases occur from the master branch at a specific commit

• Certain pull request (PR) requirements are enforced before merging, including:

• Must have at least 1 successful build to merge

• all PR tasks must be completed

Access Control of the Application (Identification, Authentication, Authorization, Accounting)

The Changineers platform implements access control on all customer-facing functionality that accesses customer data, covering Identification, Authentication, Authorization, and Accounting (IAAA):

• Identification and Authentication. User authentication is handled by AWS Cognito, which manages credentials, password policies, and multi-factor authentication. Federated identity is supported via SAML and OpenID Connect.
• Authorization. Each tenant has its own Cognito user pool and tenant data is isolated at the database layer. Within a tenant, access to specific data and actions is granted based on the user’s role.
• Accounting. User access and privileged actions are logged and retained according to Changineers auditing standards (see System Auditing).

Free and Open Source Software (FOSS) Security

Changineers uses Renovate to manage third-party dependencies in all platform repositories. Renovate:

• Inventories every software dependency declared in a repository’s lockfile.
• Opens pull requests to upgrade dependencies as new versions are released.
• Raises security-labelled pull requests when a vulnerability is disclosed for a dependency in use, via Renovate’s vulnerability alerts feature.

Dependency update pull requests follow the same review and CI process as any other change before being merged and deployed.

Static Application Security Testing (SAST)

Changineers uses static analysis during development and in CI:

• Biome lints the TypeScript codebase on every pull request. Lint failures fail CI and are treated as blocking for review.
• TypeScript strict type checking catches type errors at compile time.
• Pull request review. Changes are submitted via pull request and reviewed by another engineer before merge.

The Security team performs manual code security reviews on request via a GitHub issue.

Dynamic Application Security Testing (DAST)

Dynamic testing of the running application is performed through the annual external penetration test (see Penetration Testing).

Penetration Testing

External Penetration Testing

An external penetration testing is performed at least once a year by a qualified security researcher / ethical hacker on the security team internally and/or with an external security consulting firm.

New Platform development will be penetration tested prior to a production release, and the results of this test can be made available to Customers on-demand.

Responsible Disclosure

Changineers welcomes reports of security issues from external researchers and customers. Reports may be sent to security@changineers.com.au. The Security team acknowledges reports on receipt, investigates, and communicates the outcome to the reporter.

Production System Monitoring and Paging

Production systems are monitored continuously for health and error conditions. Monitoring sources include:

• Amazon CloudWatch for application logs, metrics, and alarms.
• Sentry for application errors and exceptions.

Alerts from these sources are routed through incident.io, which pages the on-call engineer and coordinates incident response.

Revision History

Date	Summary	Approved by
2020-01	Initial revision.	James Gregory
2026-04-24	Refreshed application security procedures.	James Gregory