Security
Software Bill of Materials
DBCode publishes a CycloneDX SBOM with every release, so you can run our component list against your own vulnerability feeds instead of taking our word that we patch things.
Where to get it
Section titled “Where to get it”| What you want | URL |
|---|---|
| The current release | github.com/dbcodeio/public/releases/latest/download/sbom.cdx.json |
| A specific version | github.com/dbcodeio/public/releases/download/v{version}/sbom.cdx.json |
| Browsable in the repo | github.com/dbcodeio/public/blob/main/sbom.cdx.json |
It is CycloneDX 1.6 JSON, which Dependency-Track, Grype, Trivy and most commercial scanners read directly.
What it covers
Section titled “What it covers”The production dependency closure of the extension: currently about 1,340
packages, each with a name, exact version,
purl and resolved licence. It is
derived from pnpm-lock.yaml, so it matches the dependency graph we actually
build from.
Every platform we ship to, not just the one that built it. DBCode ships a
single extension to macOS, Linux and Windows, and a handful of native
dependencies differ per platform. The SBOM lists all of them, so what you scan
covers what you could actually run, whichever machine you are on. Platform
specific components are marked scope: optional and carry dbcode:os,
dbcode:cpu and dbcode:libc properties saying which platform each one is for.
It is the closure, not the contents of the bundle. We build with esbuild and
package with vsce package --no-dependencies, so what ships is a tree-shaken
subset of this list. Reporting the closure is standard practice and errs toward
telling you about more than you receive, never less.
What it does not cover, and why
Section titled “What it does not cover, and why”Build and test tooling. The closure is walked from the extension’s production dependencies only, so the several hundred packages that exist purely to build and test DBCode never appear. You do not receive them, so they are not yours to scan.
Drivers fetched at first use. A few engines need a driver or CLI we are not licensed to redistribute, so DBCode downloads it the first time you use that engine. These are not dependencies of the package and cannot appear in a dependency SBOM, so they are recorded in the SBOM’s metadata properties and listed here:
| Component | Source | Trigger |
|---|---|---|
teradatasql | registry.npmjs.org | First Teradata connection |
dmdb | registry.npmjs.org | First Dameng connection |
jtds | repo1.maven.org | First JDBC (SAP ASE) connection |
mongodb-database-tools | fastdl.mongodb.org | First MongoDB import, export, backup or restore |
See Network Egress for how to block or pre-install these.
How it is produced
Section titled “How it is produced”Generated in CI from pnpm-lock.yaml, committed to the repository in the same
pull request as any dependency change, then copied to the public repository and
attached to the release. The document carries no timestamp and its serial number
is derived from the component set, so an unchanged dependency tree produces a
byte-identical file no matter which machine generated it. Diffing two releases
shows real changes only.
The rest of the release pipeline (public build, AV gates, Sigstore attestation) is on Build & Release Integrity.
Spotted a production dependency that isn’t listed? That’s a bug: security@dbcode.io.