Summary:
This article explains how Salure develops BrynQ securely, from planning and coding to testing, review, and release.
BrynQ secure development overview
BrynQ is developed under a structured development policy based on standards such as OWASP and NIST, supported by ISO 27001 controls for system development and maintenance.
Security principles and roles
Developers follow clear security principles to reduce risks in every project.
Key roles include:
Lead Developer – responsible for code quality and security.
Manager Data & Analytics – responsible for integration of software products.
Chief Technical Officer (CTO) – responsible for the overall software stack.
Code Manager – manages the code base and its quality.
Developer / Data Analyst – implements changes in the code.
Product Owner, Project Manager, Tester, and Observer – manage requirements, planning, testing, and oversight.
Patch management and handling vulnerabilities
Linux and Windows servers receive automatic critical security updates; all software packages are checked for updates at least monthly.
Many projects run in Docker containers, making it easy to apply and test patches in an isolated environment.
Main software packages are reviewed and updated every quarter.
When a vulnerability is found, the Lead Developer assesses it, informs the CTO if needed, and they decide on actions and impact. Activities are recorded in the project management system.
Development methods and risk analysis
Teams use Scrum and a Feature Branch Workflow with a central Git repository.
Requirements are placed on the backlog, worked out with the Lead Developer, and prioritized.
For major changes, a technical description and risk analysis are created, including impact on security and personal data.
There are controls for secure development policy, change control, secure engineering, and system testing.
Branching, code review, and automation
Developers use different Git branches for bugfix, hotfix, feature, and release work; merging happens via pull requests.
Each pull request is reviewed by other developers for security, errors, complexity, and improvements.
Automated tools such as Sonarcloud and Snyk scan code and Docker images for vulnerabilities and quality issues before merging.
These steps enforce secure coding and help detect security problems early.
External development and supplier security
Sometimes Salure uses external developers to build new features in Salure applications; they work only on new functionality and never directly in the live environment.
External developers work in a sandbox Docker image with dummy data and push their code to a separate branch.
Salure performs full code reviews, tests, and security checks before external code is merged and released.
Salure keeps ownership of the source code and external developers do not get server access.
Versioning and releases
Salure uses Semantic Versioning (SemVer): major.minor.patch (X.Y.Z).
X (major) increases for non-compatible changes, Y (minor) for new compatible features, and Z (patch) for small, compatible bug fixes.
For example, version 1.10.2 means major 1, minor 10, patch 2.
Procedure:
When a change to BrynQ is planned, create a backlog item with business requirements and security aspects.
Ask the Lead Developer to prepare a technical design and risk analysis, including security and privacy.
Let a developer create a feature or bugfix branch from the main repository and implement the change.
Run automated tools (such as Sonarcloud and Snyk) on the new code and images.
Have another developer review the change via a pull request, focusing on security, quality, and impact.
After approval, merge the change into the release branch and deploy it to the staging environment for testing.
After successful tests, deploy the release to the live environment and update the version number following SemVer.
Additional Information:
ISO 27001 controls for system acquisition, development, and maintenance support this secure development lifecycle.