This document outlines the policies we follow to ensure the integrity, confidentiality, and availability of our software systems. It provides guidelines for our development team to follow throughout the software development lifecycle, from initial coding to deployment and maintenance.

The policy covers key areas such as version control, change management, development principles, security testing, and vulnerability management. By adhering to these practices, we aim to create robust, secure software that protects our users' data and maintains the trust they place in our products.

All team members are expected to familiarize themselves with this policy and implement these practices in their daily work. Regular training and updates will be provided to keep our team informed of the latest security best practices and emerging threats in the software development landscape.

Table of contents

1. Version Control & Change Management

Code changes are managed through Git and Gitlab and all code should be checked into version control at least daily. Repositories are set up in a way that directly pushing to the main branch is prohibited. Any passwords, API keys or other secrets in code commits are refused by Gitlab and .

Changes are made through feature branches and these changes are proposed and merged through the use of merge requests. In order to be merged and deployed to production multiple CI checks have to pass. The CI jobs perform extra checks on code quality, dependency vulnerabilities and automated regression tests to help reduce the risk of human error.

In addition to the CI checks at least one other person has to check and approve the merge request. The merge requests checks for code design and clarity, in addition to also checking the changes against the OWASP checklist.

2. Development & Security Principles

Our approach to security is built on three fundamental pillars:

1. Confidentiality: Users of our systems should only see the data they are permitted to see. Nothing more, nothing less.
2. Integrity: Data should not be modified unintentionally and measures should be taken to ensure the data is correct and remains that way.
3. Availability: Our user's data should be accessible whenever, wherever in a (fairly) speedy fashion. This requires our systems to be highly available.

Based on these pillars, we adhere to the following principles:

• Start with secure defaults. Default accounts and passwords should be changed and specific accounts should be configured as a replacement. Only relevant ports should be exposed (often this means only port 443 is exposed), and access to the outside network should be limited to what is required, if any is required at all.