Security

Purpose

Ensures the software meets security standards and complies with regulatory requirements.

Security and Compliance

The main goal of the security process in place is to define a security assessment and threat modeling. To identify potential security threats and vulnerabilities in the software, we adopt the following practices.

Vulnerability Detection

We continuously monitor the software supply chain and released components through:

• Daily automated vulnerability scanning of dependencies and container images (SBOM-based), covering all supported product versions.
• Findings are automatically categorized by severity and tracked until resolution.
• Development teams are notified promptly when critical issues are detected.

Vulnerability Classification

All identified vulnerabilities are classified using standard CVE severity levels:

• Critical
• High
• Medium
• Low

Older unresolved vulnerabilities are treated with increased priority, ensuring long-standing issues are addressed before newer low-impact ones.

Assessment and Remediation Strategy

When a new vulnerability is detected, the Witboost security team follows a clear remediation process:

Initial Assessment

It evaluates the vulnerability, including potential impact and resolution effort.

Quick Fix Handling

If a vulnerability can be resolved quickly, it is addressed immediately.

Impact Evaluation

For more complex cases, we assess whether the vulnerability is actually exploitable in the context of Witboost deployments.

Resolution and Tracking

When remediation is required, vulnerabilities are addressed based on both severity and exploitability:

• Critical or High vulnerabilities that are exploitable in Witboost are treated with the highest priority and we start working on them within 24 working hours from their detection and when a resolution is available. They are fixed as soon as possible, following the same urgency as top-severity production issues.
• Critical or High vulnerabilities that are not exploitable in Witboost are handled with a lower priority, comparable to medium-severity issues, and scheduled accordingly.
• Medium and Low vulnerabilities are managed through our regular Dependency Update Policy and ongoing maintenance process (see section below).

All remediation activities are tracked internally and delivered through updated product releases and patches when fixes are available.

Dependency Update Policy

Witboost follows an active dependency maintenance program to ensure the software remains secure and up to date over time.

Continuous monitoring

All third-party libraries and components are regularly reviewed for security advisories and available updates.

Routine updates

Minor and patch-level dependency updates are applied continuously, and all relevant components are reviewed and upgraded as part of the preparation process before every Witboost major or minor release.

Patch releases, instead, are primarily intended to deliver security fixes and critical corrections. For this reason, dependencies are not automatically upgraded in every patch release unless required to remediate a known vulnerability or significant issue.

Dependency upgrades are evaluated case by case, based on factors such as security impact, compatibility, and overall release stability.

Planned major upgrades

When a dependency introduces an update with breaking behavior, it is carefully assessed and scheduled as part of our ongoing product roadmap to ensure stability and compatibility.

Ownership and accountability

Dependency health is actively maintained by the engineering teams responsible for each product area, ensuring timely upgrades and long-term sustainability.

Customer Communication

For vulnerabilities with customer impact, Witboost ensures transparent communication:

• Customers are informed when exploitable critical or high-risk vulnerabilities affect released versions.
• Security updates and patched releases are provided promptly.
• Guidance is shared when customer action may be required (e.g., upgrading to a fixed version).

Additional Security Practices

Periodic penetration testing

Witboost undergoes regular penetration testing performed by independent third-party security specialists. These assessments simulate real-world attack scenarios to identify potential weaknesses. Any findings are remediated promptly and validated through follow-up testing when necessary.

Secure development and code review

Security is embedded into the development lifecycle through manual code reviews, automated static analysis (SAST), and governance by a dedicated Security Lead. This ensures that common security risks, such as injection vulnerabilities, insecure configurations, or unsafe deserialization, are identified and mitigated early in the release process.

Compliance with industry standards

Witboost follows established security and operational best practices and aligns with internationally recognized standards, including:

• ISO 27001 (Security of Information)
• ISO 27701 (Security of Information according to GDPR)
• ISO 9001 (Quality System)
• ISO 22301 (Business Continuity)

Application Security

On a more general scope, Witboost adheres to the following security policies and techniques to ensure comprehensive protection.

Authentication and Authorization

Witboost delegates the authentication to a third-party service provider, chosen from a list of supported ones (all main OAuth 2.0 providers are supported, and new ones can be easily integrated); usually customers will use their default providers (like Microsoft Entra ID) which provides a secure and reliable authentication mechanism. The service provider can support different security levels, like multi-factor authentication, and WItboost will integrate with it also to get the organization structure: which users and groups are supported, and how users are assigned to the groups they belong to. This ensures that only authorized users can access the software and that their identities are verified securely.

Authorization is handled through an RBAC (Role-Based Access Control) system, where users and/or groups are assigned roles that determine what actions they can perform in the software. The roles are collections of specific permissions: they are defined based on the user's job function and responsibilities, and they are assigned to users by the administrators. This ensures that users can only access the features and data that are relevant to their role, and that sensitive information is protected from unauthorized access.

The combination of the two mechanisms ensures that the software is secure and that only authorized users can access it, and that it can completely governed from outside Witboost. Even the RBAC mechanism is managed inside Witboost, a customer can define the roles only fro groups, and change the assignment of the users to the groups from the organization provider. In this way, the customer can manage the access to the software without the need to access the software itself. Alternatively, the customer can define the roles and assign them to the users directly from Witboost, and the product will manage the access to the resources.

Infrastructure Security

The infrastructure where Witboost is installed, is provided by the customer, and the customer is responsible for the security of the infrastructure. This means that the customer can choose to deploy Witboost on-premises or on a cloud provider, and to provide all the necessary security measures to protect the infrastructure.

Witboost requires a Postgres database, and Kubernetes cluster to run. Usually the Postgres database is provided through a managed service, and the customer can choose to deploy the product on a managed Kubernetes service (like GKE, EKS, or AKS) or on a self-managed Kubernetes cluster. In both cases, the customer is responsible for the security of the cluster.

The customer can implement different security measures to protect the infrastructure, and to make the data reliable (like backups, disaster recovery, and high availability).

Usually, customers choose to deploy Witboost in one or more Kubernetes clusters, and to use a managed Postgres database to store the data. The Kubernetes clusters are not reachable from the internet, and all the communication with the software is done through a reverse proxy that is managed by the customer. If any of the pods need to contact external services, the customer can configure the firewall rules to allow only the necessary traffic.

One important example of external interaction could be between the "Provisioning Coordinator" module, and the Tech Adapters, which are external services that are used to provision the resources in the third-party systems. Since the Tech Adapters are developed and maintained by the customer, but their execution can create/destroy resources in the third-party systems, the customer can deploy them outside of the Kubernetes cluster, and needs to be sure that they are invoked only by the Provisioning Coordinator, which handles the authorization. To ensure that the Tech Adapters are invoked only by the Provisioning Coordinator, Witboost allows you to setup an mTLS (mutual TLS) communication between the two services. This is performed by generating a certificate for the Provisioning Coordinator, and configuring the Tech Adapters to accept only requests that are signed by the certificate. This ensures that only the Provisioning Coordinator can invoke the Tech Adapters, and that the communication is secure.

Monitoring and Logging

As already introduced, the deployment of Witboost is managed by the customer, who can decide to deploy it on-premises or on a cloud provider. In both cases, the customer is responsible for the security of the infrastructure. The customer can then access different functionalities to monitor the software and the infrastructure.

Witboost provides an auditing mechanism, which stores all the actions performed by the users in the system. The audit log contains information about the user who performed the action, the action itself, the timestamp, and the resource involved (along with the URL, module, and type of action). The audit log is stored in the database, and it can be accessed by the administrators to review the actions performed by the users and to investigate any suspicious activity.

Every pod has an API that can be invoked to check its health status. This is the same mechanism used by Helm to check the readiness and liveliness of the microservices. The API returns a status code that indicates whether the pod is healthy or not, and it can be used by the administrators to monitor the health of the software and to take action if any issues are detected.

In addition to this, every Witboost's pod (the software is deployed in a microservices architecture) generates logs that can be collected and stored in a centralized logging system. The log level of each pod can be configured by the customer, and the logs can be accessed by the administrators to monitor the health of the software and to troubleshoot any issues that may arise.