Building Blocks

Overview

The Sciamus OM platform has been meticulously designed with a focus on High-Availability, Resilience and Scalability. These guiding principles have led to the decision to develop it as a set of Java and SpringBoot microservices, offering flexibility and ease of deployment on container clustering platforms. These microservices communicate asynchronously, facilitated by a RabbitMQ High Availability Cluster serving as the robust communication layer. The persistence layer is powered by MongoDB, renowned for its scalability and performance.

In terms of identity and access management, the platform seamlessly integrates with Keycloak, a robust solution and the de facto industry standard in its class. Keycloak provides the flexibility needed for seamless integration with any OAuth2 compatible solution as per specific requirements.

The recommended deployment setup entails deploying the microservices within a Kubernetes cluster, whether hosted in-house or on a private cloud infrastructure. Additionally, a dedicated RabbitMQ HA cluster is established as a StatefulSet to ensure the reliability of messaging services, further enhancing the platform's resilience and performance.

Core

Optional

Cloud

Sciamus OM has been tested on following cloud platforms:

• Amazon Web Services
• Google Cloud Platform
• Google Kubernetes Engine on-prem

CI/CD

The Sciamus Order Management system has been prepared for deployment following the CI/CD paradigm. Helm charts have been prepared to enable easy integration of Sciamus OM build and deploy stages into the mechanisms used in the respective environment. All Sciamus Order Management parameterization is performed by setting the appropriate variables in the values files for individual microservices.

Our development process includes automated procedures for code quality checks, dependency management, and licensing control. It is essential that our product is developed according to the highest standards. Each new version undergoes code scans performed by tools like SonarQube, ensuring adherence to coding best practices, security guidelines, and performance benchmarks. Dependency management is handled through automated tools that track and verify third-party libraries to maintain compatibility, security, and stability. This prevents version conflicts and ensures that our system remains up to date with the latest improvements and patches. Licensing control ensures that all incorporated dependencies comply with legal and organizational requirements. Automated checks verify that open-source and third-party components align with approved licenses, preventing potential legal or compliance issues.

Automation of Trivy Scanning and SonarQube Analysis in Pipelines

1. Source Code Scanning and Static Analysis In the first stage of the CI/CD process, the following tasks are performed: Trivy scans the pom.xml file to identify vulnerabilities in project dependencies. SonarQube performs static code analysis to assess code quality and detect potential security risks. Logging and Presentation of Results: Trivy scan results are displayed in the console and stored as an artifact for developers to review. Trivy data is sent to a database for later visualization in Grafana. SonarQube analysis results are also stored in the database per project and branch to facilitate interpretation and analysis in Grafana.

2. Image Scanning After Build After the image is built, additional scanning is performed: Trivy scans the final container image to detect potential vulnerabilities. The results of this scan are also stored in the database and presented in Grafana. Thanks to this process, developers have access to comprehensive security and code quality insights at both the development stage and after the final artifact is created.

Good Practices in DevSecOps

To ensure a high level of security in DevOps processes, the following DevSecOps practices should be implemented: Source Code Scanning – Regular static code analysis using SonarQube helps detect issues and vulnerabilities early. Dependency Scanning – Trivy analyzes configuration files like pom.xml to identify vulnerable libraries and dependencies. Container Image Scanning – After the image is built, it should be scanned with Trivy to detect potential vulnerabilities. Container Image Signing – Using cryptographic signatures to confirm the integrity and authenticity of container images. Secret Scanning – This process involves analyzing source code to detect sensitive information such as API keys, credentials, and certificates. Scanning should cover both the current codebase and historical changes in the repository. Implementing pre-commit hooks and enforcing security rules can help prevent accidental exposure of secrets in the code. Using Distroless Images – Using distroless container images (which only include essential dependencies) is a good practice to minimize the attack surface. By utilizing these images, unnecessary system tools and libraries that may contain outdated versions or vulnerabilities are eliminated. This approach reduces the risk of security issues and potential attacks.