Application Security (SAST)

Security is a top priority for Nalpeiron. We use various methods to protect your data from unauthorized access and tampering, including our own tools and those of third-party security providers. These tools continuously monitor our cloud infrastructure for potential misconfigurations. In addition, we have a suite of automated tests (unit and integration) that are automatically executed after each commit to the repository and block deployments if a fault is detected.

Further, we maintain various systems that continuously monitor everything from the software pipeline to our infrastructure in layers to prevent problems and security issues.

Zentitle2 uses robust security checks on our Repository, Cloud, Container, and Domain.

Our tools integrate with our compliance suite, Drata for SOC2.

SAST

Zentitle2 runs a SAST engine based on best-in-class open-source scanners. This module's goal is to find security issues in our code and run reports for our Customers' cybersecurity reviews.

Reports

We can generate reports that can be used as part of your cybersecurity assessment. The documents include SBOM (Software Bill of Material) and SAST (Static Application Security Testing is performed automatically on all production repositories and docker containers) reports that form part of our Software Development Lifecycle.

To request the latest Nalpeiron security audit report, follow the Help menu in Zentitle2, where you can create a Support Ticket and ask for a secure link to the latest reports.

Application Security

Zentitle uses various unique parameters in the verification process.

The client application is verified based on using a Nalpeiron-issued tenant ID & product ID (these are embedded in the app client code) and the activation code (license code) issued to an end user (customer) that is private to the application user.

The development process embeds the tenant ID & product ID in the application (see our licensing client examples), and the activation code unlocks the transaction, acting like a password in the process. The Licensing API processes the various unique components and responds with the access token, which is then used to authenticate refresh requests.

Additionally, all communication takes place over a secure HTTPS connection.

Application Activation Process

Our APIs use SSL endpoints with valid certificates to establish secure connections.

This way, we guarantee that data is encrypted in transit and can not be tampered with or listened to.

Offline activation process

We generate key pair on the client for offline activation to perform a two-way token exchange.

The public key is available on the API Credentials page and can be used for encryption and verification. The private keys are kept secret and stored in an encrypted database in our highly secure infrastructure.

First, the application creates a new key pair. The public key is embedded in the offline activation request and encrypted using the server's public key. Next, on the server, we decrypt the request, perform the activation, and encrypt the response using the client's public key. This way, only the client can decrypt this message.

Webhook payload signature

We use asymmetric encryption with unique key pairs for each customer.

Webhook payloads are signed with the private key stored in our system, and this signature can be verified using the public key to prove that the webhook call is coming from the Zentitle2 system.

Management API

Zentitle2 Management API uses OAuth2 over HTTPS to manage authentication and authorization.

OAuth2 is an open standard for authorization that enables applications to access resources from other apps or services securely. We use client_credentials in the API.

Licensing API

Licensing API doesn't use OAuth2 to authenticate requests. Instead, authentication is based on tenantId, productId, and entitlement Activation Code. The first call to the Activate endpoint returns an access token, which is used in later requests.

We also use the concept of Nonce. It's a random value generated and returned in headers with each call and must be sent in headers in the next call to the API.

See our API docs for more details on authentication:

• https://license.zentitle.io/docs#section/Authentication - licensing API (OnPrem)

• https://api.zentitle.io/docs#section/Authentication - management API (SaaS & backoffice integraton)

HTTPS data exchange explained: