security: scan the supply chain, publish an SBOM, and type-check the build (Phase 2)

[cevheri]

Phase 2 of the security maturity programme: the supply chain.

Stacked after Phase 0 (#320) and Phase 1 (#321), both merged. Phase 3 — credential encryption at rest and a published security posture — follows on its own branch and carries the version bump to 0.10.0.

What this adds

Secret scanning	.gitleaks.toml and a fingerprint allowlist, plus an incremental scan that fails a pull request, and a full-history sweep on main and a schedule
Dependency scanning	Reports on pull requests; gates on main only, and only on a CRITICAL advisory that has a fix and is not suppressed
Image scanning	Reports daily. Never gates — see below
Release SBOM	CycloneDX 1.7, attested, required by name before a draft release is published
Type-checked builds	typescript.ignoreBuildErrors removed, with a guard test

The secret-scanning result

The sweep was run against this repository's real history before any configuration was written: 753 commits, 24 matches, every one read and classified as fabricated — jwt.io's published sample token, hex filler, StrongPass123 documentation examples, PEM bodies whose content literally reads fake, and $$COUCHBASE_USER:$$COUCHBASE_PASSWORD compose interpolation.

No credential has ever been committed to this repository, and no rotation is required.

Each of those 24 is suppressed by its fingerprint — the exact commit:file:rule:startline gitleaks reports — in .gitleaksignore. A fingerprint suppresses one already-classified historical occurrence and nothing else: a real secret added later in the same file, or one matching the same fabricated literal in a new commit, produces a different fingerprint and is still reported. .gitleaks.toml carries no allowlist entries at all, and a paths-based one is now rejected outright by its test.

This is the second design. The first used four rule-scoped paths = ^tests/ allowlists, and review caught what that costs: it would have covered every future generic-credential, JWT and private-key finding anywhere under tests/, not only the fabricated fixtures it was written for. That gap was not argued about but reproduced — a real-shaped secret planted in a brand-new file under tests/ was silently swallowed by the old configuration, and is reported by the new one. The sweep still scans clean across the full history, now 774 commits.

Worth recording plainly, because this pull request's own text asserted the principle and the implementation then broke it: a broad path exclusion that happens to cover today's findings will cover tomorrow's real one. Stating a rule is not the same as enforcing it, which is why the test now rejects the shape rather than trusting the comment.

What gates and what does not

Only one thing in this pull request can fail a merge that could not before: the production build now type-checks, because typescript.ignoreBuildErrors is gone.

Of the scanners:

• Secret scan fails loudly on every pull request including from forks, and needs no secrets and no registry credentials to do it. It is not yet a required check in branch protection — promoting it is tracked as BACKLOG C1 — so today a failed run is visible on the pull request but does not by itself stop a maintainer from merging.
• Dependency scan reports on pull requests and never fails them. It gates only outside pull requests, and only on a CRITICAL finding that has a fixed version and is not suppressed.
• Image scan never gates, and that is deliberate. The runtime base image carries 172 findings of which exactly one is fixable — the rest are Debian base-layer advisories with no patched version. Gating on findings nobody can act on produces a permanently red check, and a permanently red check is how a gate becomes a continue-on-error line. The scan exists for trend and evidence, not enforcement.

Suppressions live in .trivyignore.yaml and must carry a written statement and an expiry no more than 90 days out. An expired entry is re-reported — verified, not assumed — and a policy test enforces both requirements.

The SBOM, and what it does not cover

Every release from the next tag onward carries libredb-studio-<version>.cdx.json: CycloneDX 1.7, 755 components, attested, built from the three ecosystem inputs — bun.lock, desktop/src-tauri/Cargo.lock and the launcher's go.mod.

It describes the dependency closure of the npm package, the tarballs, the Windows zip, the deb and rpm, the snap, the AppImage and the desktop package. It does not describe the pinned Node runtime those artefacts bundle, which appears in no lockfile, and it is not the container image's SBOM.

The image cannot have a release asset: release-artifacts.yml publishes the release before it dispatches the image build, and releases here are immutable. The image SBOM is regenerable from any immutable digest with the command documented in SECURITY.md.

publish-release now requires the SBOM asset by name before flipping the draft to published. That is deliberate: a release without its bill of materials should not exist.

The Next.js advisories this branch deferred, and no longer defers

This section originally deferred the next advisories to a separate pull request, on the grounds that a Next minor can change middleware and CSP behaviour — exactly the surface Phase 1 verified in a real browser. That happened: #323 landed the bump to next 16.3.0 and this branch is rebased onto it, so the deferral is resolved rather than outstanding, and BACKLOG C7 has been deleted (the later entries renumbered).

Two claims in the original wording were also wrong, and are corrected here rather than quietly deleted.

The middleware bypasses were counted as three. Resolved against the GitHub advisory database, five high-severity Middleware/Proxy bypass advisories affect next@16.1.6, all published before this branch existed — so the count was wrong when written, not overtaken by a later disclosure. Of the five, CVE-2026-44573 (GHSA-36qx-fr4f-26g5) is scoped to the Pages Router with i18n and does not apply here: this application has no pages/ directory. The four that do apply are CVE-2026-44574, CVE-2026-44575, CVE-2026-45109 and CVE-2026-64642.

CVE-2026-45109 is the one worth naming, because the original text did not have it: it is the incomplete-fix follow-up scoped to middleware, and src/proxy.ts is Next 16's middleware — the single file Phase 1 put RBAC, the Origin check, rate limiting, security-header delivery and audit emission into.

next@16.3.0 carries zero advisories, so the bump closes all of them regardless of how they were counted.

For contributors

• The secret scan can fail your pull request. It reads only the commits your branch adds; the one-line local reproduction is in CONTRIBUTING.md.
• A real match is an incident: rotate first, never rewrite history. A fabricated match gets a fingerprint in .gitleaksignore — the exact commit:file:rule:startline gitleaks reports — which suppresses that one classified occurrence and nothing else. .gitleaks.toml carries no allowlist entries at all today, and paths-based ones are rejected outright by tests/unit/gitleaks-config.test.ts.
• The dependency scan reports and will not fail your pull request. bun audit is the local zero-container view, but it carries no fixed-version data, so it cannot tell you whether a fix exists.
• SARIF upload is skipped on fork pull requests by design — a token limitation, not a rejection. Your findings are in the job summary rather than the Security tab.

Verification

CI is green at 2c90972, the head of this branch after the rebase onto main: 18 checks pass and one is skipped. Among the 18 are Unit & Integration Tests, which is where the 100 percent line-coverage gate lives, and Lint, Typecheck and Build. The skipped one is Image Scan, which does not run on a pull request by design.

The ten local gates were run in the foreground before each push and were green: format, lint (0 errors, 76 pre-existing warnings), typecheck, knip, test (23/23 groups), build, test:coverage + coverage:check (100.00 percent), build:lib + attw, readme:check, and chart:check (chart 0.1.30, appVersion 0.9.67, in sync).

And the phase's own claims were re-run rather than restated: the full-history sweep found zero findings over 694 commits; the CRITICAL gate exited 0 while the same scan one severity lower exited 1 with 17 findings, proving the scanner is live rather than silently vacuous; and the SBOM regenerated at 755 components across three ecosystems.

A note on how this phase was reviewed

The branch review's structural finding was that three of the four things it could break were guards, not scanners — the mechanisms protecting the scanners' configuration rather than the scanners themselves. The secret scan exited 0 when a commit range failed to resolve. The container-tag guard stayed green when every image was switched to a mutable tag. The suppression policy's statement-and-expiry rules had no mechanical backing at all.

All three are fixed, and each fix was proved by sabotage: reverting it turns a specific test red. That habit is now the phase's standard — a control is not delivered until something fails when it is broken.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[Copilot]

Pull request overview

Adds Phase 2 supply-chain security controls, release SBOM generation, and production build type-checking.

Changes:

• Adds secret, dependency, and container-image scanning workflows.
• Generates, attests, and requires a CycloneDX release SBOM.
• Enables Next.js build type-checking with policy tests and documentation.

Reviewed changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
.github/workflows/security-scan.yml	Adds supply-chain scanning jobs.
.github/workflows/release-artifacts.yml	Adds the release SBOM gate.
.gitleaks.toml	Configures secret-scan allowlists.
.trivyignore.yaml	Defines vulnerability-suppression policy.
.gitignore	Ignores local scanner outputs.
next.config.ts	Enables build-time type-checking.
SECURITY.md	Documents supply-chain controls and SBOMs.
CONTRIBUTING.md	Documents local scanner usage.
docs/BACKLOG.md	Records deferred security work.
tests/unit/gitleaks-config.test.ts	Tests Gitleaks policy invariants.
tests/unit/trivyignore-policy.test.ts	Tests suppression requirements.
tests/unit/security-scan-workflow.test.ts	Tests scan-workflow invariants.
tests/unit/release-sbom.test.ts	Tests SBOM release wiring.
tests/unit/release-provenance.test.ts	Requires SBOM attestation.
tests/unit/next-config-typecheck.test.ts	Guards build type-checking.

Suppressed comments (3)

.gitleaks.toml:44

• This regex allows every future StrongPass value followed by digits anywhere in the repository, rather than only the documented examples that produced the historical findings. Enumerate the exact known literals so a newly committed credential such as StrongPass999 is still reported.

regexes = ['''^StrongPass\d+$''']

.gitleaks.toml:53

• Scoping by file still hides any real private key later committed to ConnectionModal.tsx; it does not limit the suppression to the two placeholder strings. Remove the PEM-shaped placeholder match or suppress the exact extracted placeholder values instead.

paths = ['''^src/components/ConnectionModal\.tsx$''']

.gitleaks.toml:62

• This path exemption hides any future real curl -u credential in the compose file, not only the intended Compose-variable placeholder. Narrow the suppression to the exact known finding (for example with a match-level regex or fingerprint) so other basic-auth credentials remain reportable.

paths = ['''^database-compose\.yml$''']

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 15 changed files in this pull request and generated no new comments.

Suppressed comments (9)

.gitleaks.toml:34

• This path allowlist suppresses the generic-api-key, jwt, and private-key rules for every future file under tests/. A real non-provider JWT, private key, or generic credential accidentally committed as a fixture would therefore pass the new blocking scan. Scope these exceptions to the exact 13 historical fabricated values/locations rather than the entire test tree, and regression-test with a generic secret as well as a provider-specific token.

targetRules = ["generic-api-key", "jwt", "private-key"]
paths = ['''^tests/''']

.gitleaks.toml:53

• Allowlisting this whole source file for private-key means a real key later pasted into ConnectionModal.tsx is invisible to the blocking scan. Match only the two placeholder findings (by exact value/line) so unrelated private-key findings in this file remain actionable.

targetRules = ["private-key"]
paths = ['''^src/components/ConnectionModal\.tsx$''']

.gitleaks.toml:62

• This exempts every future curl-auth-user finding in database-compose.yml, not only the Compose interpolation described above it. A newly hard-coded curl -u user:password credential in this file would pass. Allowlist the exact interpolation value instead of the whole file.

targetRules = ["curl-auth-user"]
paths = ['''^database-compose\.yml$''']

.github/workflows/security-scan.yml:108

• --no-merges drops conflict-resolution additions made in a merge commit. Such content can exist in neither parent, so this removes the only patch containing it while commit_count can remain nonzero from other commits; Gitleaks then reports clean. Preserve combined merge diffs (or add a current-tree scan) while avoiding the duplicated parent-side changes this comment is concerned about, and update the workflow guard test accordingly.

            range="--no-merges $BASE_SHA..$HEAD_SHA"

SECURITY.md:209

• The text promises regeneration from an immutable digest, but the command uses a mutable tag. Retagging can make this produce an SBOM for different bytes than the intended release. Show a digest-qualified reference (ghcr.io/libredb/libredb-studio@sha256:…) instead.

trivy image --format cyclonedx --scanners license \
  --output libredb-studio-image.cdx.json \
  ghcr.io/libredb/libredb-studio:0.9.67

.gitleaks.toml:45

• ^StrongPass\d+$ is a pattern family, not an allowlist of the historical examples: it silently suppresses any future StrongPass plus digits credential in any file. Enumerate the exact fabricated literals found by the sweep so a new value still fails the scan.

targetRules = ["generic-api-key"]
regexes = ['''^StrongPass\d+$''']
regexTarget = "secret"

.github/workflows/security-scan.yml:445

• The vulnerability report and image SBOM resolve mutable :latest in separate Trivy invocations. If a release retags latest between them, this run uploads a report and SBOM for different images and records neither shared identity. Resolve latest to one digest once, then pass that digest-qualified reference to both scans (and include it in the summary/artifact metadata).

            "$TRIVY_IMAGE" image \
              --scanners vuln \
              --format json \
              --output /out/image.json \
              ghcr.io/libredb/libredb-studio:latest

.github/workflows/release-artifacts.yml:616

• Only changing the root component's name leaves its version empty. CycloneDX consumers such as Dependency-Track key projects by name/version, so successive release SBOMs can collapse into the same unversioned libredb-studio project. Set metadata.component.version from VERSION and verify both root fields before attesting.

            if (doc.metadata && doc.metadata.component) {
              doc.metadata.component.name = "libredb-studio";
            }

tests/unit/trivyignore-policy.test.ts:47

• This assertion enforces that suppressions remain empty even though the comment and .trivyignore.yaml explicitly permit a justified, expiring suppression. The first legitimate entry will fail here before the policy checks below can validate it. Remove this current-state assertion and leave the per-entry policy tests as the durable contract.

  test("is empty today - the CRITICAL/fixable threshold covers everything else", () => {
    // Not a requirement that this file must stay empty forever. A record of
    // the current, expected state, so a reader knows the loops below are
    // vacuous by design rather than by accident.
    expect(vulnerabilities.length).toBe(0);

[cevheri]

Follow-up round covering findings not tied to a postable review thread, plus a few items surfaced independently.

Fixed, from Copilot's second review (suppressed comments, no thread to reply on):

• security-scan.yml image-scan job: the vulnerability scan and the SBOM generation each resolved the mutable :latest tag independently, in separate docker run invocations minutes apart. A release retagging :latest between them could make the two describe different images with no shared identity. Now resolves the digest once (docker buildx imagetools inspect) and reuses it for both.
• release-artifacts.yml's SBOM root-component patch set metadata.component.name but left metadata.component.version empty. A CycloneDX consumer that keys a project by name+version would collapse every release's SBOM into the same unversioned project. Now sets both from the release version.

Declined, with reasons:

• tests/unit/trivyignore-policy.test.ts:47 ("is empty today"). This is not a permanent constraint on the file - the test's own comment says so ("Not a requirement that this file must stay empty forever. A record of the current, expected state..."). It is a deliberate trip-wire: the first legitimate suppression is expected to touch this specific assertion in the same PR that adds it, so a reviewer sees that the vacuous-by-design premise changed rather than trusting it silently. Removing it would weaken that signal for a hypothetical inconvenience. Left as is; the per-entry policy tests below it are already the durable contract, as intended.
• Scanner digest versus its version comment (# gitleaks v8.30.1. above a pinned digest, no test that the comment matches). The digest is what actually runs; the comment is a human hint. A desync misleads a reader but cannot weaken the pin itself. Verifying it mechanically needs a registry call at test time, which is exactly the kind of external trust this digest-pinning approach exists to avoid.
• SBOM could be "partially corrupt" and still pass verification. The verify step already asserts five properties: valid JSON, bomFormat is CycloneDX, at least 100 components, all three lockfiles present by name, and licence data non-empty. Declining absent a concrete corruption shape that survives all five.
• imageArgument() needs a comment warning future editors about its one-flag-per-line assumption. It already has one, directly above the function.
• image-scan not running on pull requests, and the --all full-history scan choice for the recurring job: both already documented with their reasoning in the workflow's own header comment. No change.
• SECURITY.md documents unencrypted credentials at rest. Correct and deliberate - that is Phase 3's scope. An accurate disclosure of a real, current exposure is the document doing its job, not a defect in this one.

Also fixed this round:

• Added a direct git rev-parse --is-shallow-repository guard before the --all full-history scan. That path skips the pull-request range's non-zero-commit assertion because there is no equivalent range to miscount, but a shallow checkout would make --all scan a truncated slice of history and report "no leaks found" indistinguishable from a real clean scan. Sabotage-verified: removing the guard makes its test fail.
• CodeQL (js/redos, high): the new .gitleaksignore fingerprint-shape regex had a redundant, ambiguous slash-delimited group. Fixed - replied on the code-scanning thread with detail.
• docs/BACKLOG.md C7: resolved every "Middleware / Proxy bypass" GHSA affecting next@16.1.6 against the GitHub advisory database directly. The entry had cited CVE-2026-44573 as one of three that apply here; it does not (Pages Router + i18n only, and this app has no pages/ directory) - the one actually missing was CVE-2026-45109. Also confirmed CVE-2026-64642 does not apply (requires a single-entry i18n.locales config; this app has none). Since the rebase onto main pulled in fix(deps): raise the next floor past the three middleware-bypass advisories #323's next 16.1.6 → 16.3.0 bump - the exact work C7 was tracking - the entry is now resolved and has been deleted per this file's own convention, rather than left as a corrected-but-already-done decision record.

All of the above is on top of the rebase onto main (post-#323), fingerprint-based .gitleaks.toml/.gitleaksignore split, and --diff-merges=first-parent fix from the earlier round.

[Copilot]

Pull request overview

Copilot reviewed 16 out of 17 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

SECURITY.md:173

• The historical classifications now live as exact fingerprints in .gitleaksignore; .gitleaks.toml only enables the default rules and contains no classifications. Pointing readers to the TOML file sends them to the wrong audit record.

  reason. The classification is `.gitleaks.toml`, and the full sweep runs again on

.github/workflows/security-scan.yml:122

• For a branch-update merge (feature merges current main), the feature branch is the first parent, so this emits the merge result versus the old feature tip—including every newly merged main change. Those base changes are therefore rescanned under the merge commit and can produce new fingerprints for already-classified findings, failing an unrelated pull request. Use a combined merge diff (--cc/--diff-merges=combined) that exposes conflict-resolution-only additions, and cover the branch-update case while keeping the local command and guard test synchronized.

            range="--diff-merges=first-parent $BASE_SHA..$HEAD_SHA"

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Copilot reviewed 16 out of 17 changed files in this pull request and generated no new comments.

Suppressed comments (5)

SECURITY.md:173

• This points readers to the wrong file: .gitleaks.toml contains no classifications; the 24 classified findings are the exact fingerprints and explanations in .gitleaksignore. Name that file so the security documentation matches the implemented suppression mechanism.

  reason. The classification is `.gitleaks.toml`, and the full sweep runs again on

.github/workflows/release-artifacts.yml:27

• go.mod is a Go module manifest, not a lockfile. Calling all three inputs lockfiles repeats the terminology error already corrected in CONTRIBUTING.md and SECURITY.md; describe them as ecosystem/dependency inputs instead.

# The sbom job (security programme control 2.2) generates one CycloneDX
# document from the repository's three lockfiles (bun.lock,
# packaging/windows/launcher/go.mod, desktop/src-tauri/Cargo.lock) and

.github/workflows/release-artifacts.yml:503

• This second comment again calls go.mod a lockfile and says the inputs themselves "are the closure." They are manifests/lockfiles from which Trivy derives an inventory. Reword this to avoid documenting the same inaccurate model beside the release-critical implementation.

    # One SBOM covers everything this release ships: Trivy finds bun.lock,
    # packaging/windows/launcher/go.mod and desktop/src-tauri/Cargo.lock, which
    # between them are the closure of the npm package, the four standalone
    # tarballs, the win32 zip, the .deb and .rpm packages, the snap, the AppImage
    # and the desktop .deb - all built from these lockfiles at this commit.

tests/unit/trivyignore-policy.test.ts:16

• “non-empty” contradicts both this paragraph and gitleaks-config.test.ts, which assert that the allowlist is empty today.

 * same argument tests/unit/gitleaks-config.test.ts already makes for its own
 * allowlists staying non-empty. Vacuous is fine: the point is that the FIRST

SECURITY.md:185

• This is not a production-only dependency closure. The scanned bun.lock explicitly contains devDependencies (including @types/node, which this document later acknowledges is present), and the workflow performs a full bun install before scanning. Describe it as the repository's resolved dependency inventory, or generate a production-only SBOM, so consumers do not mistake build/test packages for shipped runtime dependencies; update the wording quoted in docs/BACKLOG.md at the same time.

Every release carries `libredb-studio-<version>.cdx.json`, a CycloneDX 1.7 SBOM
of the production dependency closure, attached as a release asset and signed with
a GitHub build-provenance attestation. It covers all three ecosystems the release
is built from — npm, Go and Rust — and therefore describes **the dependency
closure of** the npm package, the standalone tarballs, the Windows zip, the