Technical Discovery and Analysis of a Fintech Platform

At Lineate, we prioritize security as a standard practice, and our thorough analysis uncovered several critical issues that required attention. Our high-level concerns included the following:

• Coexistence of production and lower environments on the same infrastructure and without proper security boundaries

• Lack of security audit tools within the continuous integration pipeline

• Outdated software dependencies

More specifically, we identified the following issues:

• Production secrets in code repositories were being hardcoded without encryption

• The identity server had reached the end-of-life (EOL) stage

In addition to our analysis, we used Snyk to conduct a security scan of the project code repositories.

The scan reports included vulnerability breakdowns by code repository, level of severity, and links to the affected files. To ensure ongoing security and minimize the risk of introducing new vulnerabilities, we recommended integrating vulnerability testing as part of the code-build pipeline. There are several paid and open source solutions we use to perform code dependency checks, container image checks, and static analysis. Among these solutions are Snyk, Veracode, Twistlock, SonarQube, Dependency-Track, OWASP Dependency-Check, Anchor, and Trivy.  We recommend including solutions like these in any build process. 

Response

In response to these and other findings, we devised a set of actionable recommendations to effectively address each issue.

High-level recommendations that align with our standard best practices:

• Establish separate private networks and dedicated compute resources for production and lower environments.

• Incorporate security audits into the continuous integration pipeline so that vulnerable code is prevented from being deployed.

• Institute dependency management practices.

Other specific recommendations:

• Consider enforcing the use of TLS 1.2 instead of more vulnerable versions, like TLS 1.0 and TLS 1.1, to ensure secure communication.

• Restrict access to application database servers within the internal network to mitigate the risk of brute-force attacks.

• Use secure vaults for secret management and regularly rotate secrets to minimize the impact of potential breaches.

• Implement CSRF token validation for relevant APIs to prevent request forgery attacks.

• Pin existing versions of all dependencies to ensure that known vulnerabilities are not inadvertently introduced into newer versions.

• Enhance form input validation by constraining input to the application domain to prevent malicious input from compromising the system's security.

Other Findings

During our analysis, we thoroughly examined various aspects of the platform and identified several noteworthy findings.  

On the software architecture side, we discovered that the platform was designed in a way that requires a separate environment for each customer integration. This design choice was made to accommodate the unique nature of integrations for each partner, ensuring data isolation and integration specificity. However, in this type of design, as the number of customers grows, the maintenance of these separate environments becomes increasingly challenging. Unless these integrations were meant to result in completely different business workflows and user experiences, we strongly recommended unifying the architecture and software design to embrace multi-tenancy.

Furthermore, our analysis explored infrastructure costs, where we discovered instances of unused or oversized resources. This finding presented an opportunity for potential savings through optimizing resource allocation and eliminating unnecessary expenses.

Regarding performance and scalability, we observed that services were distributed across different regions. To enhance efficiency and reduce network latencies between services, we recommended consolidating workloads and resources within the same region. This approach would contribute to improved performance and scalability across the platform.

In the production environment, we noticed that the cluster was running on a single node. While this configuration may be acceptable for lower environments, it is crucial for production environments to have enough nodes to ensure high availability. We recommended starting with at least three nodes to facilitate leader selection in the event of machine or zone failures.