Architecture

1. Application

2. Introduction

2.1 Document purpose

The Technical Architecture and Security Document (TASD) is a High-Level view Document (HLD), referring to Thales IS standard components. The aim is to describe the entire product.

This document describes the architecture of the Software Factory as a Product (SWaaP).

The aim of this document is to provide a general high-level view of the design and security architecture of the product.

This TASD must be updated each time there is a change in the architecture of the product.

2.2 Document scope

This document is an HLD, so the aim is not to describe in detail the different components, especially when these are standard and/or already installed inside the Thales ecosystem. Every component of the product has a low-level architecture design which is documented into specific LLDs. These designs are out of the scope of this document and are referenced in the section below called “Referenced Documentation ”.

2.3 Referenced documentation

2.4 General overview of the product

Software Factory helps Software Engineer who want to develop high quality software applications by reducing the time to write the first line of code on secured environments and maximizing collaboration and autonomy unlike others public software workbenches.

The objective of the Software Factory as a Product is to design, develop, deploy, operate and support a set of tools inside a Software Factory, provided as a Service.

Once instantiated and deployed, these services will be provided to any Thales engineer:

• Source code management, code review and web IDE (with GitLab),
• Source code AI assistant (with Code Companion),
• Pipeline management and runner(s) in Kubernetes as a service (with GitLab CI and runner) (*),
• Artefact management (with Artifactory) and software composition analysis (with Xray),
• Code quality check (with SonarQube),
• Static application security testing alias SAST (with Coverity),
• Software Composition Analysis alias SCA (with Black Duck) and notification (with Black Duck Alert),
• Golden CI/CD template (in NextGen-CICD) (*),
• Product documentation including version description document (VDD), architecture documents (DVa, TASD), product test strategy, description and results (IVP, STD, STR), administration and user manuals (SCOM, SUM) (with SF Documentation).
• Manage GitLab workspace including Export Control compliance (with Orchestator),
• Document using “diagram as code” with Kroki.

Figure 1 - Overview of the product.

(*) Note: (dotted in the above figure)

• Projects can deploy their runner within GitLab documentation.
• Golden CI/CD template are available but not yet inside the product.

The product also provides services to the team that deploys, updates and operates the instance:

• Documentation to define & manage in configuration parameters of the instance to be created/updated, according to the product variability,
• Documentation to create and update an instance of the product i.e. a Software Factory.

All this documentation is either available online or within the SF Documentation component.

The product is based on a Kubernetes environment to be easily deployed and operated with minimized dependency with the platform (public, hybrid or on premise). The product is based on several COTS (GitLab, Artifactory, Xray, SonarQube, Coverity, Black Duck, Black Duck Alert, …) or OSS (Diagram as code).

The scalability of the infrastructure is ensured by the elasticity of the Kubernetes cluster (see Sizing chapter for cluster size ) in the product documentation.

Product needs are collected, managed and implemented by the Software Factory tribe.

3. Product contexts

The product is managed by the Software Factory tribe . Release note is available on this site .

3.1 Product status at end of Q3 2025 after Cycle 23 & 24

Version 4 (end of Cycle 23) deliver major version 18 of GitLab. Other COTS also receive at least minor updates.

Version 4.1 deliver a minor version 18.2 GitLab

Cycle 24 deliver both SWaaP 4.2 and 5.0. Both versions deliver minor version 18.3 of GitLab, patch 2.2.4 of Code Companion, minor versions 0.5.0 & 0.6.0 of Software Factory Documentation, and finally version 2025.6.2 of Coverity.

The major difference for version 5.0 lies in a new deployment model described in paragraph 7.1 .

3.2 Project at Cycle 25 (End of Q4 2025)

This cycle will target classical updates of existing COTS & TOTS. Major updates will be:

• put in place a capacity of Doc as Code (if the blocking risk is closed by then)
• in addition to the new deployment model, store every artifact in OCI registry and give a capacity to transfer artifact to another air-gapped OCI registry.
• agentic in Code companion

4. Requirements

The product has no classical requirements. It is designed and developed based on business use cases.

4.1 Functional & Business Requirements

4.1.1 Requirements summary

Software Factory as a Product is a product that permits to deploy and operate Software Factory instances. These Software Factories are provided as a service to build software-based solutions and enhance engineering efficiency through:

• secured, reliable and easy to use environments,
• engineering practices enhancements,
• inner sourcing,
• providing/supporting software building blocks for equipment segment.

The services provided by the Software Factory are:

• secured, reliable, automated and easily portable to another asset,
• scalable in term of users and geographic location,
• updated frequently to keep up with the latest supported versions.

The product provides assets to deploy and operate the following services:

• SF Documentation: user documentation, but also product documentation and practices.
• GitLab: source code management.
• JFrog Artifactory: artifact repository.
• JFrog Xray: software composition analysis (SCA) solution that natively integrates with Artifactory, giving developers and DevSecOps teams an easy way to proactively identify vulnerabilities on open source and license compliance violations, before they manifest in production releases. This binary analysis tool and policy engine, scans container images in an Artifactory repository to identify known vulnerabilities reported from a variety of sources. It performs deep recursive scans to check all of an application’s components for both known risks and license policy compliance, and populates metadata for the images.
• GitLab Runners: the ability to launch pipeline jobs that are managed by GitLab.
• SonarQube: ability to manage code quality.
• Coverity: ability to manage code vulnerabilities using Static Application Security Testing (SAST) practice.
• Black Duck: ability to manage dependencies graph, licenses and vulnerabilities using Software Composition Analysis (SCA) and Software Bill of Materials (SBOM) practices.
• Black Duck Alert: ability to manage Black Duck alerts.
• Orchestrator: ability to label indicating each applicable regulation on PESCE.
• Diagram as code rendering: ability to convert a textual representation of a diagram into an image.

4.1.2 Prerequisites

The product is cross-platform and seamless deployment designed. Requirements are also limited by the least mandatory dependencies:

(*) alternative for mandatory (one or other).

Table 1 - SWaaP prerequisites.

Product is designed with least privilege principle. In that way, a namespace admin privilege is required for Flux operator.

The product is also integrated in ECOL (reference ) and we defined a link between ECOL and our product requirements annex 1 .

Product is supporting:

• Flux v2.6.X
• Kubernetes >= 1.31

4.1.3 Variability

High-level variability model and high-level product plan is described in Table 2 :

Variability Tree	Feature Name	End Q1-2026	End Q2-2026
	Code management, CI (GitLab)
	Web IDE (GitLab)
	GitLab Runner
	Runner(s) in K8S (as a Service)
	Documentation for dedicated runner
	Artefact management (Artifactory)
	Artefact vulnerability scan (Xray)
	Code quality management (SonarQube)
	SAST (Coverity)
	SCA (Black Duck)
	SCA alert (Black Duck Alert)
	Golden CI/CD template (NextGen-CICD)
	Orchestrator
	SF Documentation
	Best practices / process / training catalogue
	Diagram as code

Table 2 - Variability Model.

Figure 2 - Variability Model Legend.

Code management and CI with GitLab and Artifactory are identified as critical items.

4.2 Security requirements

Software Factory product contributes to those basic security stories that have to be applied on TDP.

• [BSS-7] The product shall have a Threat Model.
• [BSS-9] The developed part of the product shall be assessed with SAST.
• [BSS-10] The developed part of the product shall be assessed with SCA.
• [BSS-11] The developed part of the product shall be assessed with DAST.
• [BSS-12] The product access shall be performed through a single Identity Provider.
• [BSS-18] The product shall ensure data encryption at rest.
• [BSS-23] The product shall manage vulnerability and patch.
• [BSS-24] The product shall allow security monitoring.
• [BSS-28] The product security shall be evaluated with a pentest.
• The product shall implement multi-tenancy, that is to say shall provide data isolation to end-users.
• The product shall be analyzed with sheep dip alias “station blanche” to detect malware.

4.2.1 Thales’s classification

The product data has C2 – THALES GROUP INTERNAL classification. Instances of the product can have their own classification level.

4.2.2 Regular-based classification

The product has no defense / government classification. But instances can have their own independently.

Some components of the product have Export Administration Regulations. Example:

• GitLab

TODO Personal data.

4.3 Environment requirements

The product has its own environments for tests purpose. Instances can have their own independently (classically at least staging & production).

TODO check if we declare this here or in a testing section.

The product shall be tested on several reference platforms that reflect the target environments (for example KaaS over AKS cluster and Tanzu cluster). Non-regression tests are designed to ensure stability of functions and integration of the product updates. Performance tests are also designed to ensure usability of the product. Those tests may be also executed on dev instances of the platforms.

5. Architecture decision record

Here is a list of approved decisions:

Table 3 - List of architecture decision record.

Details are in ADR

6. Architecture description

6.1 Business architecture and allocation to services

You will find in Figure 3 business architecture for software code and CI/CD engineering allocated to services:

Figure 3 - Business architecture allocated to services.

Note: in dash, external items.

6.2 Application architecture

Physical architecture of the product is described in Figure 4 :

Figure 4 - Physical architecture.

Note: in dash, external items not managed by the product.

6.2.1 User roles / user rights management

The product has some generic roles. Currently there is no correlation between these roles and roles that can be defined at component level.

6.2.2 RACI

Here is the RACI (Responsible, Accountable, Consulted, Informed) of SWaaP:

6.3 Product delivery

SWaaP delivery is composed of OCI artifacts see diagram below , that are located under oci://artifactory.thalesdigital.io/docker-virtual-softwarefactory/sf/swaap/releases :

• charts: helm charts of SWaaP
• gitrepos: Git repositories in oci format of customer-template and swaap.
• images: container images of SWaaP
• metadata: artifacts from editors to manage Air Gap SWaaP

An extra repository is also required to manage SonarQube plugins in https://artifactory.thalesdigtal.io/artifactory/generic-virtual-softwarefactory

These data are variables of SWaaP configuration of customer Git repository in:

• cfg-swaap-version.yaml (see template )
• and cfg-swaap-variables.yaml (helmRepositoryUrl, imageRepositoryUrl and sonarPluginRepositoryUrl see template )

Figure 5 - Delivery.

A mirrored version is available on TDP C3-CA:

• oci://artifactory.tdp.infra.thales/proxy-docker-softwarefactory/sf/swaap/releases :
• https://artifactory.tdp.infra.thales/artifactory/proxy-generic-softwarefactory

A mirrored version is available on Carma:

• oci://carma.corp.thales/softwarefactory-c3-docker/sf/swaap/releases :
• https://carma.corp.thales/artifactory/softwarefactory-c2-generic

For first delivery to a new team that is going to use the product, a customer Git repository has to be created copying, forking, or inspired from the customer template of SWaaP. To be consumed by Flux CD (see [#71-deployment]), this Git repository has to be hosted either in a Git server, or as an OCI aside others SWaaP deliveries.

Cadence of version is describe in the Product Lifecycle , and future versions are announced in releases .

6.3.1 Air Gap

SWaaP is also delivered as a standalone package in order to be deployed without having access to our deliverables. This delivery & deployment mode is currently in exploration.

This mode requires an artifact repository alongside the targeted deployment (see PRE_020 in Prerequisites ).

• A ‘downloader’ runs the oras command to pull the SWaaP Air Gap delivery.
• A ‘deliverer’ transfers securely the delivery to the Air Gap environment.
• An ‘uploader’ runs the oras command to push the SWaaP package to the local registry as a standard SWaaP delivery.

Once done, a platform can deploy a SWaaP instance as described in Deployment

You will see further documentation in delivery .

6.4 Infrastructure architecture

This chapter describes classical integration an instance of the product can have.

6.4.1 Software Factory API

Here is a list of services that can be integrated with the Software Factory.

(1) Protocol and ports are example that may be set for production.

6.4.2 Infrastructure sizing

Currently data are located in each LLD.

7. Operational and maintenance

Except next chapter deployment, this chapter is not applicable to the product itself. It describes what can we recommend doing for Software Factory instances.

7.1 Deployment

7.1.1 Principle

SWaaP product has to be deployed and updated using Flux , which has to be installed in the Kubernetes cluster (see prerequisites ). Conf as code has to be managed with a Git repository dedicated to Software Factory instance, called customer repository. This repository can be initialized with the [Customer template] and is own by the platform team. For updates, the platform team will change the swaap-version in the customer repository, and also check the potential updates of the [Customer template] in the release note.

Several instances (such as staging, pre-production, production, or any other name) in several clusters can be managed with the same Git repository. See customer template documentation for further details

7.1.1.1 Initial configuration

Application admin can deploy or upgrade doing, as you will see in figure 6 :

• Set the integration values in a Git repository (1), such as version of SWaaP used, OCI registry location, service hostname, SSO integration, mail server, S3 object storage credentials, and secret (*). Set also the location of this Git repository as either a Git server or an OCI registry location.
• Apply the cluster configuration (2).

Therefore, a GitRepository object is created and will be reconciled by Flux, using a specific service account.

(x) Numbers are related to link label in figure 6

(*) For more details, see the full documentation

Figure 6 - Setup.

7.1.2 Reconcile mechanism and services install and update

Flux tries to reconcile the content of the Git repository with the resources in Kubernetes namespace (1) executing:

• Create or update any native Kubernetes resources (ConfigMap, service, deployment, ingress …) or Flux resources (helm repository, helm release) (2).
• One or several specific Flux resources called helm release can be part of the deployment (3). If so, Flux will perform an equivalent of helm install/update using helm chart from helm repository and values from one or several ConfigMaps.
• The helm install/update equivalent install or update the Kubernetes resources managed by helm (4).

For local changes (5) instance Admin can edit the instance source code. For upgrade from the product (MR) the instance Admin validates the merge request.

Flux will perform the reconcile each time there is a change in the source code.

(x) Numbers are related to link label in figure 7

Figure 7 - Flux.

7.2 DRP Failover principles

Failover is ensured by Kubernetes mechanism. If a process crash or a service does not respond, the associated pod restarts.

Observability plays a large part in monitoring the health of services.

7.3 High availability and redundancy principles

Currently no high availability is provided by the product, even if some tools are able to support it.

7.4 Scheduling/Batches

Not applicable at product level.

7.5 Security patch management

When a vulnerability is discovered is published by a software editor, it is essential to have a well-defined response plan to ensure the prompt and effective implementation of the patch. Our process permits to ensure an SLA regarding vulnerabilities. For further details, see Security_patch_management .

7.6 Backup

We recommend to manage point in time restore at platform level. Like that it is possible to restore synchronously:

• volumes,
• database,
• and object storage.

Alternative backup procedure is indicated in every component LLD.

7.7 Monitoring

There is no transverse capacity of monitoring. The product support Prometheus/Grafana. Monitoring of component is detail in every LLD and SCOM.

7.8 Capacity planning

TODO Capacity planning

7.9 User management

There is currently no transverse capacity of managing users. On/off boarding has to be performed at component level.

7.10 TMA/Administration

There is no administration at product level. See component LLD.

8. Annex

8.1 Annex 1 - ECOL requirements traceability

List of ECOL requirement is described in Table 4 . And traceability from SWaaP prerequisites to ECOL requirement is described in Table 5 .

Table 4 - ECOL requirement needs for Software Factory.

Table 5 - SWaaP prerequisites to ECOL requirement traceability.