Build and Release Integrity

DBCode’s source is closed. The process that turns it into the package you install is not: every release is built by a public GitHub Actions workflow you can read and watch run. This page walks the pipeline and shows how to verify a release yourself. Every release from v1.36.6 onward is built and attested through this pipeline; earlier releases were built by the previous, private release process.

The pipeline, in public

Releases are built by build-and-publish.yml in the public repository, and every run is visible in the Actions history with full logs. The workflow:

1. Checks out the private source at an exact commit with a read-only deploy key, then verifies that commit matches the release tag and the version in package.json. A dispatch that does not match the tag fails the run.
2. Stamps provenance into the package. The source repository, source commit, version, and a link to the workflow run are written into build-provenance.json inside the package, so the artifact records what produced it.
3. Builds and packages from a committed lockfile. Nothing resolves at release time.
4. Scans the package with two antivirus engines before anything ships: ClamAV with heuristics and PUA detection, and Windows Defender configured with cloud-delivered protection, sample submission, and PUA blocking. Any detection blocks the release for investigation. There is no allowlist step.
5. Attests the package with Sigstore, via GitHub artifact attestations. This runs only after both scans pass, so only clean artifacts are signed. Sigstore log entries are public and permanent.
6. Publishes the same bytes everywhere: the GitHub release (with the SBOM attached), the VS Code Marketplace, and Open VSX.

Verify a release yourself

You need the GitHub CLI. Download any release’s .vsix and run:

gh attestation verify dbcode-<version>.vsix --repo dbcodeio/public

Verification succeeds for every release from v1.36.6 onward and reports the workflow that built the file: dbcodeio/public/.github/workflows/build-and-publish.yml. Run it against an older release and it fails, because GitHub has no attestation on record for a file the previous, private process built. That failure is expected, not an incident.

The verification proves the exact file you hold was produced by this repository’s workflow, at a recorded commit, on GitHub’s runners, and has not been altered since. If verification fails for a release that should carry an attestation, treat it as an incident and tell us: security@dbcode.io.

Static analysis

DBCode’s extension source is closed, so you cannot watch these runs the way you can watch the build pipeline above. Static analysis still runs on every change: CodeQL, configured through GitHub’s advanced setup (a workflow we own, not GitHub’s default), scans the actions, javascript-typescript, and python languages present in the private source repository, using the standard CodeQL query suite. Nothing is excluded from the scan.

Every pull request into main is analysed, and CodeQL is a required check in the branch ruleset, so no code reaches main unanalysed. (A docs-only change can legitimately have nothing for CodeQL to analyse, but the required check still has to report before the pull request can merge.) A scheduled run repeats the analysis daily, which keeps the baseline and the repository’s official alert state current even on days with no pull requests. The scanning action itself is pinned to a commit SHA and kept current by Dependabot.

Supply chain hygiene

• Dependencies are pinned by a committed lockfile and installed with --frozen-lockfile everywhere, including the release build.
• New dependency versions must age for 7 days before they can be installed, which blunts compromised-package releases.
• Every GitHub Actions step is pinned to a full commit SHA, not a mutable tag.
• Secret scanning (gitleaks) runs on every pull request across the full history, with a pre-commit hook scanning staged content locally.
• A weekly scheduled scan checks the full dependency tree against the OSV vulnerability database, which catches CVEs disclosed against dependencies nobody has touched recently. Exceptions are tracked with expiry dates instead of being silenced permanently.

What this does and does not prove

Attestation proves where the bytes came from and that they were not modified. It does not prove the source is defect-free, and closed source means you cannot read it. The rest of the security story is built for that gap: the egress table tells you what the extension can do on the wire and how to check it, and the SBOM tells you what is inside.