budgetpilot

Public git repository with a stable URL: https://github.com/NonoHM/budgetpilot

git records the content, author and timestamp of every change, and the full history is publicly readable at https://github.com/NonoHM/budgetpilot/commits/main

Every change is developed on a branch and merged into main through a pull request; main carries the full development history between releases, not only tagged releases. Branch protection requires a pull request and a green CI run before any merge, with no bypass.

git, a distributed version control system. Every clone of https://github.com/NonoHM/budgetpilot carries the complete history, so the project does not depend on a single central server to preserve it.

Each release is a unique semantic version, tagged and published as a GitHub release with a matching container image tag. Versions are computed by release-please from Conventional Commit types rather than assigned by hand.

Semantic Versioning, computed by release-please from Conventional Commit types rather than chosen by hand. Configured in release-please-config.json. https://github.com/NonoHM/budgetpilot/blob/main/release-please-config.json

Each release is tagged in git as budgetpilot-v<version>, created by release-please when the release pull request merges. The publish workflow runs only from that tag and refuses to run from any other ref.

Non-trivial release notes file in repository: https://github.com/NonoHM/budgetpilot/blob/main/CHANGELOG.md.

No CVE has ever been assigned to BudgetPilot's own code, and this criterion covers the project results rather than its dependencies, so there is nothing this criterion requires to be listed. The project discloses dependency advisories anyway: the 0.8.0 release notes name CVE-2026-67213, CVE-2026-18446 and CVE-2026-66062 in a table with advisory links, severities and fixed versions, including one that had shipped without appearing in the generated changelog. https://github.com/NonoHM/budgetpilot/releases/tag/budgetpilot-v0.8.0

Non-trivial SECURITY[.md] file found file in repository: https://github.com/NonoHM/budgetpilot/blob/main/SECURITY.md. [osps_do_02_01]

GitHub issues, 54 to date, organised into six milestones that each carry a written done-definition rather than being open buckets. https://github.com/NonoHM/budgetpilot/issues

Stated plainly rather than claimed: all 54 issues to date are maintainer-filed or opened by automation (52 by the maintainer, 2 by github-actions), so no externally-submitted bug report has ever been received and there is no response record to point at. The tracker is actively worked: 183 pull requests merged and six milestones, each carrying a written done-definition rather than being an open bucket. https://github.com/NonoHM/budgetpilot/issues

Same measurement as report_responses: no externally-submitted enhancement request has been received. Feature ideas are tracked as issues and triaged into milestones, and three were explicitly declined with written reasoning and sources rather than left open, in docs/explanation/what-this-does-not-do.md. https://github.com/NonoHM/budgetpilot/blob/main/docs/explanation/what-this-does-not-do.md

GitHub issues are public, permanently archived and full-text searchable, closed ones included. https://github.com/NonoHM/budgetpilot/issues%3Fq=is:issue

SECURITY.md 'Reporting a vulnerability' tells reporters not to open a public issue and directs them to GitHub private security advisories, listing what to include. Private vulnerability reporting is enabled on the repository, verified from an unauthenticated view rather than the owner view: the public API returns enabled true, and the signed-out advisories page carries a 'Report a vulnerability' button linking to /security/advisories/new. https://github.com/NonoHM/budgetpilot/blob/main/SECURITY.md

GitHub private security advisories, which keep the report between the reporter and the maintainer until an advisory is published. Enabled on the repository and confirmed reachable from a signed-out view at the exact URL SECURITY.md names. https://github.com/NonoHM/budgetpilot/security/advisories/new

No vulnerability report has been received, so there is no initial response time to report. The private channel is open and was verified working on 2026-08-13.

npm run build (vite build) rebuilds the application from source, and the multi-stage Dockerfile builds the shipped container image. Both run in CI on every push and pull request. https://github.com/NonoHM/budgetpilot/blob/main/Dockerfile

npm and vite for the application, Docker for the image, Prisma for the database layer. All invoked through package.json scripts.

Node.js, npm, vite, TypeScript, Prisma and Docker Engine are all FLOSS. No proprietary tool is required at any point in the build.

Two FLOSS suites. Vitest: 3022 tests across 193 files, covering server logic, browser-mode component behaviour, and db-smoke suites run against SQLite, PostgreSQL and MySQL. Playwright: 37 end-to-end specs. How to run them is documented in CONTRIBUTING.md 'Before opening a PR' and encoded in .github/workflows/ci.yml. https://github.com/NonoHM/budgetpilot/blob/main/CONTRIBUTING.md

npm test runs the unit suite then the end-to-end suite. npm run test:unit, npm run test:e2e and npm run test:db run them individually. Standard npm script convention for this ecosystem; see package.json.

.github/workflows/ci.yml runs on every push and every pull request with nine parallel jobs: lint, typecheck, unit plus build plus end-to-end, db-matrix against PostgreSQL and against MySQL, sqlite-migrations, compose-combinations, docker-smoke and image-cve. A red run blocks the merge. https://github.com/NonoHM/budgetpilot/blob/main/.github/workflows/ci.yml

CONTRIBUTING.md 'Code conventions' states that a change should come with a targeted end-to-end or component test. The working practice goes further: a fix ships with a test that reproduces the measured failure without the fix, and the test is verified by reverting the fix and watching it go red.

The five security fixes released in 0.10.0 (issues 215, 216, 219, 220 and 203) each shipped with tests written against the specific defect, and each test was verified by reverting its fix and confirming the test failed. The suite stands at 3022 tests across 193 files. https://github.com/NonoHM/budgetpilot/blob/main/CHANGELOG.md

Stated in CONTRIBUTING.md, which is this project's documented instruction set for change proposals. https://github.com/NonoHM/budgetpilot/blob/main/CONTRIBUTING.md%23code-conventions

Four tools, all enforced in CI: eslint.config.js (the recommended sets from @eslint/js, typescript-eslint and eslint-plugin-svelte, with no-unused-vars raised to error), TypeScript with strict true and checkJs true in tsconfig.json, svelte-check through npm run check, and prettier --check. https://github.com/NonoHM/budgetpilot/blob/main/eslint.config.js

The lint and typecheck jobs are green on main: npm run lint (prettier plus eslint) and npm run check (svelte-check over roughly 3300 files) both report zero findings, and either one failing blocks the pull request. https://github.com/NonoHM/budgetpilot/actions/workflows/ci.yml

The design principles are applied and visible in the shipped code. Fail-safe defaults: registration is admin_only by default and the session cookie is forced Secure whenever the instance declares itself public. Complete mediation: every sensitive query is scoped to the authenticated user. Least privilege: GITHUB_TOKEN permissions are scoped per job, and the runtime image is distroless, non-root and read-only. Separation of privilege: password plus TOTP re-authentication before irreversible actions. Input validation with allowlists: zod at the boundaries, and explicit host allowlists on both outbound clients with redirect targets re-validated against the same allowlist. An owner-authorised penetration test of a local instance was mapped against OWASP ASVS 4.0.3 level 1, and SECURITY.md documents which kinds of change require a new pass. https://github.com/NonoHM/budgetpilot/blob/main/SECURITY.md

The penetration test exercised injection, cross-site scripting, CSRF, horizontal and vertical access control, session handling, file upload, SSRF and backup-restore integrity, each with reproducible evidence, and its findings were fixed and released in 0.10.0. CodeQL runs on every commit with the remote threat model. SECURITY.md 'Penetration testing and retest policy' records the baseline and the retest rule. https://github.com/NonoHM/budgetpilot/blob/main/SECURITY.md

bcrypt for password hashing, AES-256-GCM for secrets at rest (src/lib/server/crypto.ts), SHA-256 for session token hashing, HMAC-SHA256 for rate-limit keys, RS256 for the bank connector JWT, and RFC 6238 TOTP for the second factor. Every one is publicly specified and expert-reviewed.

All cryptography is called from node:crypto, bcrypt, jose and otpauth. No cryptographic primitive is reimplemented in this project, and implementing cryptography is not its purpose.

node:crypto (OpenSSL), bcrypt, jose and otpauth are all FLOSS, so every cryptography-dependent feature is implementable with free software.

AES-256-GCM in src/lib/server/crypto.ts, SHA-256 throughout, session tokens from randomBytes(32), a bcrypt cost floor of 12 enforced in code in src/lib/server/auth.ts, and RS256 for the connector JWT. All exceed the NIST through-2030 minimums.

GCM, an authenticated mode, rather than ECB or bare CTR. A sweep of src/ for sha1, MD5, RC4 and single DES returns zero matches outside test fixtures, so no broken algorithm sits in any default path.

The same sweep: no SHA-1, MD5, RC4, single DES or unauthenticated CBC anywhere in src/. Secrets at rest use AES-256-GCM and passwords use bcrypt.

The software implements no key agreement protocol of its own. TLS termination is the job of the documented reverse-proxy overlay (docs/reverse-proxy.md, Caddy with automatic HTTPS), and outbound calls inherit Node's TLS stack rather than negotiating their own parameters. There is no key agreement in this project's code for perfect forward secrecy to apply to.

bcrypt with a per-user salt generated by the library, at a cost floor of 12 enforced in src/lib/server/auth.ts rather than only documented. A dummy hash at the same cost is compared for unknown accounts so the login path does not leak account existence by timing.

randomBytes from node:crypto for session tokens (32 bytes), invitation tokens, AES-GCM initialisation vectors and TOTP recovery codes. The only Math.random in src/ outside tests is retry backoff jitter in src/lib/server/database/upsert.ts, which is not a security mechanism.

Published container images are cryptographically signed with cosign in keyless mode, using the publish workflow's OIDC identity, so an operator can verify provenance before trusting a pulled image. The signature covers the multi-arch index and both platform manifests, and the release carries a detached Sigstore bundle over the SBOM. The verify command is documented in docs/operations.md and is run by the publish workflow itself against the real published image. Distribution is over HTTPS: GHCR for images, GitHub for releases.

No cryptographic hash is retrieved over http anywhere. The only download in the documented install is over https from raw.githubusercontent.com, and release artefacts carry a cosign signature bundle rather than a bare checksum.

There is no publicly known vulnerability in BudgetPilot's own code. Dependency and image exposure is gated rather than assumed: the publish workflow refuses to release with a fixable CRITICAL or HIGH finding, every pull request builds and scans the runtime image under the same policy (image-cve in .github/workflows/ci.yml), and .github/workflows/trivy-scheduled.yml rescans the published image daily and opens a tracking issue on a finding.

0.8.0 shipped fixes for three advisories within days of their detection, two of them HIGH, and named all three in the release notes with severities and fixed versions. The publish gate refuses to release while a fixable CRITICAL or HIGH is present. https://github.com/NonoHM/budgetpilot/releases/tag/budgetpilot-v0.8.0

No real credential is tracked. .env is gitignored, and only .env.example (documentation with no values) and .env.test (fixed test-only fixtures) are in the repository. The placeholder keys in the Dockerfile are set in the builder stage only, never in the distroless runtime stage, and scripts/docker-smoke.sh asserts in CI that no build-time value reaches the final image. GitHub secret scanning is enabled on the repository.

CodeQL through GitHub code scanning default setup, covering javascript-typescript and actions with the remote threat model, running on every push and every pull request as well as weekly. The most recent analysis on main ran 87 rules and returned 0 results. Trivy additionally scans the built runtime image on every pull request and the published image daily. https://github.com/NonoHM/budgetpilot/security/code-scanning

CodeQL's security query suite with the remote threat model is designed to find injection, cross-site scripting and access-control flaws in TypeScript specifically. Trivy covers the operating system and dependency layers of the shipped image.

CodeQL reports 0 results on main. .trivyignore contains seven glibc LOW entries and nothing else, each admitted only after a recorded three-part test verified against the Debian security tracker, and the file states in its header that nothing merely unfixed-for-now belongs there.

On every push and every pull request, plus a weekly scheduled run. Analyses exist against refs/heads/main and against pull request heads.

The project produces TypeScript and JavaScript, both memory-safe. Native code exists only inside third-party dependencies (bcrypt, better-sqlite3), which are not software produced by this project.

No dynamic code analysis is run, so no vulnerability has been discovered by that route; the criterion offers N/A for exactly this case. Findings from the manual penetration test were fixed and shipped in 0.10.0, but they are accounted for under the vulnerability criteria rather than here.