NEOMSA ESB Release Strengthens Supply Chain Security Through SBOM and Dependency Hardening

NEOMSA ESB is a domestic on-premise integration platform based on Apache Camel and the Camel Karavan project. It provides a visual designer for integration routes while preserving the ability to edit generated YAML routes manually, store them in Git, and review them as code.

The platform includes a web-based designer, a Quarkus backend, a VS Code extension, and a catalog of components and Kamelets. It targets typical enterprise integration scenarios involving accounting, reporting, CRM, ERP, and industry-specific ABS/MES systems.

Why Dependency Composition Represents a Separate Risk Contour

An ESB acts as a central concentration point for data flows between processing systems, ERP, MES, CRM, anti-fraud, and regulatory reporting. Compromise of the bus therefore grants influence over the entire integration perimeter rather than a single application. Sensitive payment details and personal data transit through the bus memory even when they are not stored there.

Integration layers are deployed for years, while libraries age faster than platform releases. Apache Camel alone contains hundreds of components, so even limited usage results in a wide attack surface in the final build.

Automated Release Verification Process

Builds are fully automated. Every pipeline run performs the following steps:

• Generation of an SBOM in CycloneDX format stored as a pipeline artifact.
• SCA analysis using Grype on the SBOM and OWASP Dependency-Check on the repository tree, including frontend lock files.
• SAST with SonarQube and Semgrep using offline rule sets.
• Secret scanning with Gitleaks across the repository and commit history.
• Aggregation of all findings into DefectDojo for deduplication and SLA tracking.

Images are built with Kaniko and tagged with the short commit hash, ensuring full traceability from artifact to source code.

Vulnerability Remediation Approach

The guiding rule is to raise each component only to the minimum version that resolves the reported advisory, not to the latest available release. This principle avoids unintended changes to default settings, function behavior, or removal of legacy methods.

For transitive dependencies, forced version overrides with exact pinning are applied. When multiple major branches of the same package coexist, overrides are defined separately for each branch.

Several non-trivial cases required manual engineering decisions:

• postcss 7.x had no patch; the consuming resolve-url-loader package was upgraded, removing the vulnerable branch entirely.
• The lodash advisory listed 4.17.23 as the last vulnerable version, yet 4.17.24 did not exist; after testing, 4.18.1 was selected following maintainer guidance against 4.18.0.
• An update to a browser-support library altered compilation targets and broke a downstream package; the target set was adjusted to prevent the problematic transformation.
• A lock file contained mismatched version, download URL, and checksum fields; a new verification step now checks all 5,866 lock-file entries for consistency.

Results and Platform Migration

After remediation the build showed zero Critical and High vulnerabilities. The remaining 59 Medium and 53 Low findings were documented in DefectDojo. Most belonged to build tools rather than runtime components.

Accumulated data demonstrated that point fixes had reached diminishing returns on the aging frontend build tooling. The team therefore migrated the fork to Camel Karavan 4.18, which uses Vite. The total package count dropped from 5,872 to 1,683, and the main interface contour shrank from 1,641 to 598 packages.

The same SBOM, scanning, and verification process continues for every build, ensuring the improved composition remains under control for customers.