forge-sql-orm

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The public Git repository contains the full interim history, not only releases: work happens in feature branches and pull requests (https://github.com/forge-sql-orm/forge-sql-orm/pulls) and every commit to master is visible. Between releases, interim builds are also published automatically for testing: a weekly snapshot of master to GitHub Packages (dist-tag "latest", .github/workflows/weekly-gpr.yml) and a weekly snapshot of the Drizzle v1 line (dist-tag "drizzle-v1", .github/workflows/weekly-gpr.v1.yml). Final releases (e.g. 2.2.5) are published separately at https://github.com/forge-sql-orm/forge-sql-orm/releases.

Weekly Builds:
https://github.com/forge-sql-orm/forge-sql-orm/pkgs/npm/forge-sql-orm
https://github.com/forge-sql-orm/forge-sql-orm/pkgs/npm/forge-sql-orm-cli
https://github.com/forge-sql-orm/forge-sql-orm/pkgs/npm/forge-sql-orm-extra

Repository on GitHub, which uses git. git is distributed.

Every release has a unique version (2.2.3, 2.2.4, 2.2.5, ...).

Each release is identified by a Git tag matching its version number (e.g. 2.2.3, 2.2.4, 2.2.5); the repository has 51 tags: https://github.com/forge-sql-orm/forge-sql-orm/tags. Each GitHub Release is attached to its tag, for example https://github.com/forge-sql-orm/forge-sql-orm/releases/tag/2.2.5.

Every release has human-readable release notes grouped by theme (New, Improvements, Dependency Updates), not raw git log output. They are published on the GitHub Releases page (https://github.com/forge-sql-orm/forge-sql-orm/releases, e.g. https://github.com/forge-sql-orm/forge-sql-orm/releases/tag/2.2.5) and mirrored in CHANGELOG.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CHANGELOG.md). The notes describe user-visible changes and their impact, for example new APIs, behaviour changes and etc...

No publicly known vulnerabilities in the project's own code have been fixed so far

Non-trivial SECURITY[.md] file found file in repository: https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md. [osps_do_02_01]

GitHub Issues: https://github.com/forge-sql-orm/forge-sql-orm/issues

I acknowledge bug reports quickly, usually the same day. Reports from the last 12 months: #1422 (https://github.com/forge-sql-orm/forge-sql-orm/issues/1422) was answered on the day it was opened; #2128 (https://github.com/forge-sql-orm/forge-sql-orm/issues/2128) was answered within hours, fixed in 2.1.28 (node-sql-parser moved to optionalDependencies), and then led to an architectural change in 2.2.0 (cache, Rovo and node-sql-parser moved out of core into the optional forge-sql-orm-extra package, tracked in #2321, #2326 and #2332). Older report #177 (https://github.com/forge-sql-orm/forge-sql-orm/issues/177) was answered in 3 days.

I respond to enhancement requests and questions. In the last 12 months the project received few external requests, and all were answered: Discussion #2271 (https://github.com/forge-sql-orm/forge-sql-orm/discussions/2271) about cache expiry was answered, and #2768 (https://github.com/forge-sql-orm/forge-sql-orm/issues/2768, option to silence applySchemaMigrations logs) was answered and shipped in release 2.2.5 as an optional { logger, logHistory } argument. An older request, #177 (https://github.com/forge-sql-orm/forge-sql-orm/issues/177), was answered in 3 days. Accepted enhancements are recorded in the CHANGELOG (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CHANGELOG.md).

Reports and responses are kept in GitHub Issues (https://github.com/forge-sql-orm/forge-sql-orm/issues) and GitHub Discussions (https://github.com/forge-sql-orm/forge-sql-orm/discussions). Both are public, searchable, and every issue and discussion has its own permanent URL.

SECURITY.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md) explains how to report vulnerabilities, which versions are supported and what I commit to do.

SECURITY.md asks reporters to send vulnerabilities to me by private email and not to use public GitHub issues. GitHub private vulnerability reporting is also enabled for the repository (Security tab, "Report a vulnerability").
https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md

No vulnerability reports have been received in the last 6 months, so there is no response time to measure. SECURITY.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md) commits me to acknowledge any report within 48 hours.

The software is built from source with a single command, npm run build (TypeScript compiler producing CommonJS and ESM output in dist/). forge-sql-orm-extra and forge-sql-orm-cli each have their own npm run build (the CLI uses Vite). The build is run automatically in CI (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/.github/workflows/node.js.yml) and the steps are described in CONTRIBUTING.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CONTRIBUTING.md).

The project uses standard JavaScript tooling: npm scripts, the TypeScript compiler (tsc) and Vite for the CLI package.

All build tools (Node.js, npm, TypeScript, Vite) are FLOSS, and the project can be built with only these tools.

The project has an automated test suite written with Vitest (FLOSS, MIT) and released in the same public repository: 37 test files for the core package in tests/, plus 8 for forge-sql-orm-extra and 7 for forge-sql-orm-cli. How to run it is documented in CONTRIBUTING.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CONTRIBUTING.md, "Pre-commit Requirements") and the tests run automatically in CI (.github/workflows/node.js.yml).

The tests are invoked in the standard npm way: npm run test (or npm run test:coverage for coverage) in the repository root and in each package (forge-sql-orm-extra and forge-sql-orm-cli).

Coverage is measured with Vitest (v8 provider) and enforced in CI: each of the three packages (core, forge-sql-orm-extra, forge-sql-orm-cli) has thresholds of 80% for statements, branches, functions and lines, and the build fails if coverage drops below them. Coverage is also reported to SonarCloud, Codacy and Qlty.

Tests for new functionality are required by policy. CONTRIBUTING.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CONTRIBUTING.md) states that any new logic must include corresponding unit tests, and the pull request template (.github/PULL_REQUEST_TEMPLATE.md) has a checklist item "I have added tests that prove my fix is effective or that my feature works". In addition, CI enforces coverage thresholds of 80% in each package, so a change without tests fails the build.

Recent major changes were accompanied by tests. The 2.2.0 modular split added tests for the new forge-sql-orm-extra package (for example resolveForgeSqlOrmOptionsExtra with comprehensive defaults, and unit tests for the ForgeSQLORM public API delegation methods). The new { logger, logHistory } options of applySchemaMigrations (release 2.2.5, #2768) are covered in tests/src/webtriggers/applyMigrationsWebTrigger.test.ts, and the select result ordering fix changed tests/src/utils/forgeDriver.test.ts together with src/utils/forgeDriver.ts. The test suite has 52 test files across the three packages.

The policy is documented in the instructions for change proposals: CONTRIBUTING.md says that any new logic must include unit tests and describes the coverage thresholds, and the pull request template asks contributors to confirm that they added tests.

The project uses ESLint with typescript-eslint (npm run lint, configured in eslint.config.mjs) and TypeScript strict mode ("strict": true and noImplicitAny in tsconfig.json). Knip (npm run knip, knip.config.ts) additionally reports unused and unlisted dependencies, unresolved imports, duplicates and unused enum members as errors, and Prettier (npm run format:check) enforces a consistent code style. All of them run in CI on every pull request and in a husky pre-commit hook.

I enable warnings as strictly as practical. TypeScript runs in strict mode in all three packages; ESLint (typescript-eslint) has no-explicit-any, no-console, unused variables and undefined identifiers at error level on top of the recommended rule set; Knip reports unused dependencies and exports of the dependency graph as errors; and Prettier format checks run in CI. A husky pre-commit hook runs lint-staged, the build, Knip and lint before every commit. On top of that, every pull request goes through SonarCloud with a strict Quality Gate (the Security Rating on new code must be A), Codacy, DeepScan, Qlty (function complexity threshold 8, see qlty.toml), CodeQL and the AI reviewer CodeRabbit. A few Sonar rules are suppressed explicitly in sonar-project.properties, so the exceptions are visible in the repository.

npm run lint currently reports no errors and no warnings, and CI fails on lint errors, so findings are fixed before merging. The few intentional exceptions are marked in the source with explicit eslint-disable comments (mainly no-console for deliberate logging, and no-explicit-any at Drizzle ORM type boundaries). Findings from the other analyzers are fixed as well: Codacy and DeepScan are required checks for merging, SonarCloud findings are fixed before merging (for example rule S8234 in PR #2810), and every pull request is also reviewed by the AI reviewers CodeRabbit and Codacy AI Reviewer, whose comments must be resolved before merging.

I am the primary developer and founder of the project, and I design it following the Saltzer and Schroeder principles. Fail-safe defaults and least privilege: the Rovo integration is deny-by-default and accepts only a single SELECT statement against explicitly configured tables and fields, with optional row-level security; JOINs, subqueries, window functions and data-modifying statements are rejected (forge-sql-orm-extra/src/rovo/Rovo.ts). Complete mediation: all queries go through one driver (src/utils/forgeDriver.ts) that always uses Forge prepared statements with bound parameters. Input validation with allowlists: the Rovo guard validates the statement type, the target table and the selected columns against an allowlist, and date/time values are validated against the range Forge supports. Limited attack surface and economy of mechanism: advanced features (caching, Rovo, SQL parsing) are split out of the core package into the optional forge-sql-orm-extra package, so users who do not need them do not include that code or its dependencies. Open design: security does not depend on hidden implementation details, and the code and documentation are public. I also published a security pattern for connecting Rovo with Forge SQL (https://community.developer.atlassian.com/t/rovo-forge-sql-a-secure-pattern-for-natural-language-analytics-in-forge-apps/97028), later packaged as a reusable guard executor. Vulnerabilities are handled through SECURITY.md.

I know the common errors that lead to vulnerabilities in a database library (OWASP Top 10 and CWE Top 25) and how to counter them. SQL injection (CWE-89): queries are built with Drizzle ORM and executed through Forge prepared statements with bound parameters (src/utils/forgeDriver.ts); for natural-language input from Rovo, the guard accepts only a single validated SELECT on an allowlisted table. Broken access control and missing authorization (CWE-862/639): the Rovo guard supports row-level security, so a user can only read their own rows. Excessive privilege and data exposure: the guard rejects JOINs, subqueries and window functions that could bypass the table and column restrictions. Vulnerable dependencies (CWE-1395): dependencies are updated daily, audited with npm audit, and scanned by CodeQL, SonarCloud, Codacy and DeepScan on every pull request.

The project does not implement cryptographic protocols. The only cryptography it performs itself is SHA-256 from Node.js node:crypto to derive cache keys (src/utils/cacheUtils.ts), a publicly published and reviewed algorithm. The optional helpers in src/core/functions/EncryptTiDB.ts only generate calls to the TiDB/MySQL SQL encryption functions (AES_ENCRYPT, SHA2 and others), which are executed by the database.

The project does not re-implement any cryptographic function.

All functionality that depends on cryptography uses FLOSS: Node.js node:crypto for the cache key hash, and TiDB / MySQL-compatible SQL functions for the optional encryption helpers.

he project does not implement security mechanisms with configurable key lengths. The only cryptographic use is a SHA-256 hash for cache keys;

The default behaviour of the library does not depend on any cryptographic algorithm for security: SHA-256 is used only to build cache keys.

No default security mechanism of the project depends on weak algorithms.

The project does not implement key agreement protocols or network encryption; connections to the database are handled by the Atlassian Forge platform.

The project does not store passwords of external users. The CLI only reads a database password from a prompt, the --password option or the FORGE_SQL_ORM_PASSWORD environment variable and does not store it.

The project does not generate cryptographic keys or nonces.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Neither the build nor the release process retrieves cryptographic hashes over HTTP: dependencies are installed from the npm registry over HTTPS and the package-lock.json files contain integrity hashes (SHA-512) that npm verifies on install. All download URLs used by the build and the CI workflows use HTTPS.

There are no unpatched publicly known vulnerabilities of medium or higher severity. The repository has no open Dependabot alerts, npm audit reports 0 vulnerabilities in every package-lock.json, and dependencies are updated daily by an automated workflow (.github/workflows/autoupdate.yml), so fixes in dependencies are picked up well within 60 days.

Critical vulnerabilities are fixed as soon as possible: dependency updates are automated and merged daily, and SECURITY.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md) commits me to acknowledge reports within 48 hours and release a patch quickly. No critical vulnerabilities have been reported so far.

The repository does not contain valid private credentials. CI tokens are stored in GitHub Actions secrets and referenced as secrets.* in the workflows. GitHub secret scanning and push protection are enabled for the repository.

Several static analysis tools are applied to every change before it is merged into master, and releases are cut from master: CodeQL (GitHub code scanning, JavaScript/TypeScript and GitHub Actions), SonarCloud, Codacy Static Code Analysis, DeepScan, Snyk and Qlty. ESLint with typescript-eslint (npm run lint) and Knip (npm run knip, which reports unused and unlisted dependencies and unresolved imports) also run in CI for every package. Dependency licenses are checked with license-checker (npm run license:check, which fails on GPL, LGPL, AGPL and similar licenses), and license headers are checked with the REUSE action. The same checks (lint-staged, build, Knip, lint, tests) run locally in a husky pre-commit hook before each commit.

CodeQL and SonarCloud include rules for common vulnerabilities (for example injection, unsafe regular expressions and insecure workflow patterns), Snyk and npm audit check dependencies for known vulnerabilities, and Codacy and DeepScan add security and defect checks for JavaScript/TypeScript.

Findings from static analysis are fixed before merging. GitHub code scanning (CodeQL) currently has no open alerts about the project's code, and more than 100 alerts have already been fixed, including high and medium severity ones. Codacy and DeepScan are required checks for merging, and SonarCloud findings are fixed in the same pull request (for example rule S8234 in PR #2810).

Static analysis runs on every pull request and every push to master, and CodeQL additionally runs on a weekly schedule. and a husky pre-commit hook runs the checks before each local commit.

The automated test suite is run on every pull request before changes reach master, and its branch coverage is above the 80% required by the criterion: the core package currently has 85% branch coverage (statements 94%, functions 97%), and coverage thresholds of 80% for statements, branches, functions and lines are enforced in CI for each of the three packages (vitest.config.mjs and the vitest.config.mts files). Coverage is also reported to SonarCloud, Codacy and Qlty.

The project is written in TypeScript, a memory-safe language, and contains no memory-unsafe code.

The automated tests contain many assertions (about 1,900 Vitest expect() calls across 52 test files in the three packages) and run on every pull request, so faults are detected before deployment. TypeScript strict mode is enabled in the build that runs in the same CI job.

The automated tests run with many assertions enabled (Vitest expect assertions across 52 test files in the three packages), and TypeScript strict mode is enabled during the build and test runs, so faults are detected before deployment