Secure Software Development and Product Security

2025.8

Matrak engineering team, under the leadership of the CTO, follows the latest security best practices when developing software, and automates security testing throughout development lifecycle whenever possible. The CTO is ultimately responsible for the security of the platform.

Security is integrated into all phases of Matrak 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 that includes:
  - Linting with security rules
  - Open source security analysis
  - Static secure code analysis
  - Automated code review agents for security implications
  - Penetration testing (ad hoc based on significant changes)
Remediation:
- Follows defined vulnerability management lifecycle
- Ensures no high risk security vulnerability is in production

Details about the Matrak software application architecture and security are documented on the product development / engineering wiki.

Policy Statements

Matrak policy requires that:

(a) Matrak 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 automated and manual product testing before releasing to production, including comprehensive unit tests and end-to-end tests that validate authentication and authorization for all endpoints;
manual business reviews are conducted before releases.

(c) Security considerations are integrated throughout the development process via code reviews, automated code review agents, and comprehensive testing.

(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 Matrak software products.

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

(g) Comprehensive automated testing including unit tests and end-to-end tests must validate authentication and authorization for all endpoints 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 30 days, whichever is sooner.

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

Controls and Procedures

Software Development Process

Overview

Software development at Matrak follows a release strategy that provides traceability for production software changes. Features, enhancements, and bugs are written up as Issues in Jira. An engineer on a small team proposes changes necessary and creates a review for the team (GitHub). Continuous integration (GitHub Actions) kicks off unit and functional tests which pass before changes are merged into the repository. Once the review is complete, the changes are now deployed to the development environment where regression and end-to-end tests are run before the new code replaces the existing in-service code (test then deploy model). Small teams can decide to follow a source-control branching strategy that makes sense: git-flow, github flow.

Matrak practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (using technologies such as Terraform and AWS Cloudformation) and managed under source control.

Matrak’s multiple lower environments (dev, test) provide an ecosystem of sample data sets that exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change – typically captured as part of the issue description/writeup).

Deployments to production are gated by change control process where an issue is opened which identify what is new/changed (Jira). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes. This process keeps the set of differences between the development environment and the production environment as low as possible.

In the continuous delivery mindset, features are not released by the deployment of code into production, instead features are enabled in production at the appropriate time (dark launching). Feature toggle enablement in production is gated by a change control ticket (Jira) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.

Secure Development Standards

Traceability of code changes allow for our software to be a living entity. Our current system for documenting changes is Jira. Every commit and/or Pull-Request, should have a Jira supplied that describes contextually why this change is necessary and reasonable. These artifacts over time allow for one to trace the lineage of why our production software and services change over time.

All Matrak git repositories have a company standard configuration from a GitHub perspective. This standard is a guideline and can be relaxed, but socialize when those exceptions are needed. One example of an exception, is the wiki repository, as editing a wiki and always requiring a PR in this setting slows down 'flow'.

Repository standards are maintained and documented internally by the engineering team.

NOTE: The Sandbox project (and repos) do not follow this standard. And certain projects might be excluded (e.g. wiki).

Developers follow the branch strategy and code review process below:

All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.
- These changes must be covered under 1) a unit test where possible, or 2) integration tests.
- Integration tests are required if unit tests cannot reliably exercise all facets of the change.
Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.
- Commit messages should be wrapped to 72 characters.
- Commit messages should be written in the present tense. This convention matches up with commit messages generated by commands like git merge and git revert.
- Additionally, the commit messages should start with the Jira Issue ID when applicable.
Once the feature and corresponding tests are complete, a pull request (PR) will be created using the GitHub web interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.
Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically by adding reviewers as PR approvers.
- Other engineers will review the changes, using the guidelines above.
- Engineers should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.
- If changes/commits are made to a PR, it should reset previous approvals and require review and approvals again before the PR can be merged.
- Once the review process finishes, each reviewer should approve the PR, at which point the original author(s) may merge their change into the main branch (i.e. master).
- PR can only be merged with at least one approval from a reviewer other than the author.
If the feature or defect interacts with sensitive data, or controls access to sensitive data, or contains security/risky infrastructure changes to the target environment, the code changes must be reviewed by the engineering team before the feature is marked as complete.
- This review must include a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10.
- This review must also verify that any actions performed by authenticated users will generate appropriate audit log entries.

Release Strategy

Features, enhancements, and bugs are written up as issues (Jira). An engineer on a small team proposes changes necessary and creates a review for the team (GitHub). Continuous integration (GitHub Actions) kicks off unit and functional tests which pass before changes are merged into the repository. Once the review is complete, the changes are now deployed to the development environment where regression and end-to-end tests are run before the new code replaces the existing in-service code (test then deploy model). Small teams can decide to follow a source-control branching strategy that makes sense: git-flow, github flow.

Matrak practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (Terraform) and managed under source control.

Matrak's multiple lower environments (dev, test) provide an ecosystem of sample data sets that can be used to exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change - typically captured as part of the issue description/writeup).

Deployments to production are gated by change management process where an issue is opened which identify what is new/changed (Jira). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes.

This process keeps set of differences between the development environment and the production environment as low as possible.

Features may be released via code deployments or features may be enabled in production at an appropriate time (dark launching). Feature toggle enablement in production is gated by the same change management ticket (Jira) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.

Detailed process and procedures for code promotion and production release: See Configuration and Change Management.

Source Code Management

Matrak 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 repos
All code repos in GitHub follow these configuration standards:
All repos must have an owner identified and listed
All repos are by default private
Certain branch restrictions are enabled, including:
The master branch cannot be rebased
Restrict direct commits into master
Restrict history rewrites of master
Restrict deletion of master
Certain pull request (PR) requirements are enforced before merging, including:
Must have at least 1 review approval to merge
Must have at least 1 successful build to merge
all PR tasks must be completed

High Level Application Security Requirements

All Matrak software must be developed to include the following general application security principles and requirements. Web applications must also protect itself against the OWASP Top 10 vulnerabilities.

Protect sensitive customer data such as PII and account passwords. Encrypt data stored (at rest).
Secure data in transit and customer communications via TLS.
Provision strong access control (authentication and authorization). Prevent and report unauthorized access.
Log all transactions and activities to be able to tell who did what, when, where, and how. Mask or remove sensitive data in logs.
Implement client security at application endpoints (e.g. browser, mobile app).
Communicate securely across application endpoints and between service consumers/producers.
Use secure defaults to ensure security when in all error conditions.
Check and maintain the security of all third party and open source libraries/components/dependencies.
Validate all data inputs; encode data outputs when appropriate.
Deploy and configure applications securely to production.
Perform regular vulnerability analysis and apply security patches promptly.
Secure privileged access to production environments and ensure ongoing application monitoring.

All software code must complete a set of security scans/testing prior to being deployed to production, including open source dependency scanning, static and dynamic application security testing, as well as periodic penetration testing.

Pre-production testing is performed with nonproduction data in nonproduction environments. Health checks are performed regularly or automated in production.

Software vulnerability identified through any of the above processes shall be reported and tracked following Matrak Vulnerability Management process as defined in the Vulnerability Management Policy and Procedures.

Secure Design and Application Threat Modeling

The engineering team considers security implications throughout the development process. Security considerations are integrated into feature development through:

Code review processes that include security analysis
Automated code review agents that flag potential security issues
Comprehensive testing including authentication and authorization validation
Manual business reviews before releases

Penetration Testing

External Penetration Testing

External penetration testing is performed ad hoc based on significant product changes that warrant security assessment. Testing is conducted by qualified external security consulting firms when deemed necessary by the CTO and engineering team.