Transparency

Software Bill of Materials

Standard Inventory v1.0 — Last reviewed: May 15, 2026 — Framework version: @slingr/framework@0.2.1

This page is Slingr’s public Standard Inventory of the principal open-source components used in the solutions we build for clients. It is the document referenced by Section 5.4(a) of our Master Services Agreement and exists for three purposes: to give procurement and security teams a clear view of the supply chain we operate on; to let clients confirm that the licensing terms of those components are compatible with their distribution and use requirements; and to support the right-to-leave commitment in our Open Exit terms by making the dependencies visible whether or not you stay with us as your operator.

Slingr’s engagements are technology-agnostic. The list below reflects the components Slingr most commonly uses across its engagements; the specific dependencies present in any given Solution depend on the architecture chosen by Client in the applicable Work Order and may differ from the Standard Inventory. Each client’s engagement-specific Software Bill of Materials is delivered as part of the transition deliverables under Section 11 of the MSA, or on written request to security@slingr.io.

License posture. All components in the Standard Inventory below are licensed under permissive open-source licenses (MIT, Apache 2.0, BSD-2-Clause, BSD-3-Clause, ISC, BlueOak, WTFPL). None impose copyleft obligations (GPL, AGPL, LGPL) on a Client’s proprietary applications when used in the manner contemplated by the Solution architecture. If a future engagement requires inclusion of a copyleft-licensed component, Slingr will disclose this in the applicable Work Order and explain any implications for Client’s distribution rights.

Slingr-developed framework

The core orchestration framework, authored and maintained by Slingr, is published as @slingr/framework on the npm registry and licensed under Apache License 2.0. The framework provides type-safe models, validation, JSON serialization, workflow actions, ORM integration, and the supporting building blocks Slingr uses to assemble custom applications.

ComponentVersionLicensePurpose
@slingr/framework 0.2.1 Apache-2.0 Slingr’s open-source orchestration framework for smart business applications. Source available at github.com/slingr-stack/framework.

Backend dependencies (framework runtime)

The packages below are pulled in by @slingr/framework as production dependencies. Versions reflect the minimum compatible range declared in the framework’s package.json; the version actually installed in a Solution is the latest matching version at install time and is captured exactly in the engagement-specific SBOM at transition.

ComponentVersion rangeLicensePurpose
Web and API
@apollo/server^5.0.0MITGraphQL server
@as-integrations/express5^1.1.2MITApollo Server × Express integration
@pothos/core^4.10.0ISCGraphQL schema builder
cors^2.8.5MITCross-origin resource sharing
express^5.2.1MITHTTP server framework
fastify^5.6.1MITAlternative high-performance HTTP framework
multer^2.0.2MITMultipart form / file upload handling
Identity, authentication, authorization
bcryptjs^3.0.2BSD-3-ClausePassword hashing
jsonwebtoken^9.0.2MITJSON Web Tokens (signing / verification)
express-jwt^8.5.1MITJWT middleware for Express
passport-jwt^4.0.1MITPassport.js JWT strategy
@casl/ability^6.7.3MITPermission / authorization rules
@ucast/core^1.10.2Apache-2.0Universal condition AST
@ucast/mongo^2.4.3Apache-2.0MongoDB-style query parser
@ucast/mongo2js^1.4.0Apache-2.0MongoDB-style query compiler
Data, ORM, workflow
typeorm^0.3.26MITSQL ORM and migrations
@dbos-inc/dbos-sdk^4.7.9MITDurable workflow / transactional execution engine
@dbos-inc/typeorm-datasource^4.7.9MITDBOS integration for TypeORM
cron-parser^5.5.0MITCron expression parser for scheduled jobs
Validation and serialization
class-validator^0.14.2MITDecorator-based validation
class-transformer^0.5.1MITObject ↔ class serialization
reflect-metadata^0.2.2Apache-2.0Runtime metadata reflection (required by decorators)
tsyringe^4.8.0MITLightweight dependency injection
Logging and observability
winston^3.18.3MITStructured application logging
winston-daily-rotate-file^5.0.0MITDaily log file rotation
Utilities
dotenv^16.4.7BSD-2-ClauseEnvironment variable loading
glob^11.0.3BlueOak-1.0.0File pattern matching
uuid^9.0.1MITUUID generation
Financial arithmetic (where elected in a Work Order)
financial-number^4.0.4WTFPLArbitrary-precision financial arithmetic
@slingr/financial-arithmetic-functionslatestWTFPLSlingr’s financial calculation helpers

Frontend stack (peer dependencies)

Solutions that include a web UI use the following peer dependencies, supplied by the application that consumes the framework. The framework does not bundle these; they are installed by the application according to the Work Order. Specific UI components and themes vary by engagement.

ComponentVersion rangeLicensePurpose
react^18 || ^19MITUI library
react-dom^18 || ^19MITReact DOM renderer
@umijs/max^4.6.22MITUmiJS Max application framework
antd^5.0.0MITAnt Design component library
antd-style^3.7.0MITAnt Design styling utilities
@ant-design/icons^5.0.0MITAnt Design icon set
@ant-design/pro-components^2.0.0MITHigher-level Ant Design layout / form components
@apollo/client^4.0.0MITGraphQL client
graphql^16.0.0MITGraphQL reference implementation
@monaco-editor/react^4.7.0MITMonaco code editor (used in admin / configuration UIs)
dayjs^1.11.0MITDate / time utility

Runtime and infrastructure

Solutions ship on the runtime and hosting platform elected in the applicable Work Order. The primary defaults are:

ComponentVersionLicense / termsPurpose
Node.js≥ 20 LTSMITJavaScript runtime (framework requires Node 20+)
npm≥ 10Artistic-2.0Package management
TypeScript^5.9Apache-2.0Application language (build-time)
PostgreSQL14+ (typical)PostgreSQL LicensePrimary application database via TypeORM
Google Cloud PlatformmanagedGoogle Cloud termsDefault Slingr-managed hosting environment
Kubernetescloud-managed (GKE)Apache-2.0Container orchestration

Where a Work Order specifies an alternative cloud provider (AWS, Azure, or Client-managed infrastructure) or an alternative database, the runtime stack reflects that election in the engagement-specific SBOM.

Third-party services

Solutions may integrate with third-party services that are not open source. These are not part of the SBOM in the strict sense, but are disclosed for completeness. The specific services used in an engagement are identified in the applicable Work Order.

Vulnerability monitoring

Slingr monitors public vulnerability disclosures (CVEs, GitHub Security Advisories, npm audit, the operating-system vendor advisories applicable to the runtime) against the components listed above. Where the managed solution model is elected in a Work Order, Slingr applies security patches in the ordinary course as part of the monthly subscription fee, as described in Schedule 1 §S1.8 of the MSA. Critical vulnerabilities are addressed under the Severity 1 response time in Schedule 1 §S1.10.

How to request an engagement-specific SBOM

Each Client’s engagement-specific Software Bill of Materials, reflecting the exact components and versions deployed in that engagement, is delivered as part of the transition package under Section 11 of the MSA. Clients may also request a snapshot at any time during the engagement, in a standard format (CycloneDX or SPDX, on request), by writing to security@slingr.io.

Reporting a concern

To report a vulnerability, a license question, or any other concern regarding a component listed in this inventory, contact security@slingr.io. Slingr acknowledges receipt within a commercially reasonable time and investigates as appropriate.

This Standard Inventory is updated when Slingr adopts or replaces a component in the curated stack. The framework version and the last-reviewed date at the top of this page identify the current revision.