Dit artikel legt uit hoe Salure BrynQ veilig ontwikkelt, van planning en codering tot testen, review en uitrol.
Overzicht veilige ontwikkeling van BrynQ
BrynQ wordt ontwikkeld volgens een gestructureerd ontwikkelbeleid dat is gebaseerd op richtlijnen zoals OWASP en NIST, ondersteund door ISO 27001-maatregelen voor systeemontwikkeling en onderhoud.
Beveiligingsprincipes en rollen
Ontwikkelaars werken volgens duidelijke beveiligingsprincipes om risico’s in elk project te verkleinen.
Belangrijke rollen zijn onder andere:
Lead Developer – verantwoordelijk voor de kwaliteit en veiligheid van de code.
Manager Data & Analytics – eindverantwoordelijk voor integratie van softwareproducten.
Chief Technical Officer (CTO) – verantwoordelijk voor de totale softwarestack.
Code Manager – beheert de codebasis en de kwaliteit.
Developer / Data Analyst – voert wijzigingen in de code uit.
Product Owner, Project Manager, Tester en Observer – voor requirements, planning, testen en toezicht.
Patchmanagement en omgaan met kwetsbaarheden
Linux- en Windows-servers krijgen automatisch kritieke beveiligingsupdates; alle softwarepakketten worden minstens maandelijks op updates gecontroleerd.
Veel projecten draaien in Docker-containers, zodat patches eenvoudig kunnen worden toegepast en getest in een geïsoleerde omgeving.
Primaire softwarepakketten worden elk kwartaal beoordeeld en bijgewerkt.
Als een kwetsbaarheid wordt ontdekt, beoordeelt de Lead Developer deze, informeert zo nodig de CTO, en samen bepalen zij acties en mogelijke impact. Activiteiten worden vastgelegd in het projectmanagementsysteem.
Ontwikkelmethoden en risicoanalyse
Teams gebruiken Scrum en een Feature Branch Workflow met een centrale Git-repository.
Requirements komen op de backlog, worden uitgewerkt met de Lead Developer en geprioriteerd.
Voor grote wijzigingen wordt een technische beschrijving en risicoanalyse gemaakt, inclusief de impact op beveiliging en persoonsgegevens.
Er zijn maatregelen voor secure development policy, change control, secure engineering en systeemtesten.
Branching, code review en automatisering
Ontwikkelaars gebruiken verschillende Git-branches voor bugfix, hotfix, feature en release-werk; samenvoegen gebeurt via pull requests.
Elke pull request wordt door andere ontwikkelaars beoordeeld op beveiliging, fouten, complexiteit en verbeterpunten.
Geautomatiseerde tools zoals Sonarcloud en Snyk scannen code en Docker-images op kwetsbaarheden en kwaliteitsproblemen voordat er wordt gemerged.
Deze stappen dwingen secure coding af en zorgen voor vroege detectie van beveiligingsproblemen.
Externe development en leveranciersbeveiliging
Soms schakelt Salure externe developers in voor nieuwe functies in Salure-applicaties; zij werken alleen aan nieuwe functionaliteit en nooit direct in de live omgeving.
Externe developers werken in een sandbox-Docker-image met dummydata en pushen hun code naar een aparte branch.
Salure voert volledige code reviews, tests en securitychecks uit voordat externe code wordt samengevoegd en uitgerold.
Salure blijft eigenaar van de broncode en externe developers krijgen geen servertoegang.
Versienummering en releases
Salure gebruikt Semantic Versioning (SemVer): major.minor.patch (X.Y.Z).
X (major) wordt verhoogd bij niet-compatibele wijzigingen, Y (minor) bij nieuwe compatibele functies, en Z (patch) bij kleine, compatibele bugfixes.
Bijvoorbeeld: versie 1.10.2 betekent major 1, minor 10, patch 2.
Procedure:
Maak bij een geplande wijziging aan BrynQ een backlog-item met businessrequirements en beveiligingsaspecten.
Laat de Lead Developer een technisch ontwerp en risicoanalyse opstellen, inclusief aandacht voor security en privacy.
Laat een developer een feature- of bugfix-branch aanmaken vanuit de hoofdrepository en de wijziging implementeren.
Laat geautomatiseerde tools (zoals Sonarcloud en Snyk) controles uitvoeren op de nieuwe code en images.
Laat een andere developer de wijziging reviewen via een pull request, met focus op beveiliging, kwaliteit en impact.
Na goedkeuring wordt de wijziging in de release-branch gemerged en naar de stagingomgeving uitgerold voor testen.
Na geslaagde tests wordt de release naar de live omgeving uitgerold en wordt het versienummer volgens SemVer bijgewerkt.
Aanvullende informatie:
ISO 27001-maatregelen over systeemverwerving, -ontwikkeling en -onderhoud ondersteunen deze secure development lifecycle.