norefs

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.

Every commit lands on the public main branch as it is made. Releases are tags on that history, not the only thing published.

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

Each release has a unique semantic version in package.json, published to npm as https://www.npmjs.com/package/norefs and tagged in git as vX.Y.Z.

Every release is a git tag. The release script runs npm version, which bumps package.json, commits, tags vX.Y.Z, and pushes the commit with its tag — so a release cannot exist without its tag. https://github.com/FranCanias/norefs/tags

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

No vulnerability has been publicly known or reported in this project, so no release notes identify one.

Bug reports go to the GitHub issue tracker: https://github.com/FranCanias/norefs/issues — linked from the README, from CONTRIBUTING.md, and from the "bugs" field in package.json.

GitHub Issues: https://github.com/FranCanias/norefs/issues

No bug reports have been submitted yet. The project is young and has had no external reporters so far; the only issues and pull requests to date are Dependabot's, and both were acted on within a day.

No enhancement requests have been submitted yet. Requests that arrive will be answered on the issue tracker, including when the answer is no.

GitHub keeps every issue and pull request, open and closed, publicly readable and searchable: https://github.com/FranCanias/norefs/issues?q=is%3Aissue

SECURITY.md publishes the process, asks reporters not to open a public issue, and promises a first reply within seven days: https://github.com/FranCanias/norefs/blob/main/SECURITY.md

Private reporting runs through GitHub security advisories, which SECURITY.md links directly: https://github.com/FranCanias/norefs/security/advisories/new

No vulnerability has been reported in the last six months, or ever. SECURITY.md commits to a first reply within seven days.

pnpm run build compiles src/ to dist/ with the TypeScript compiler and marks the entry point executable. prepublishOnly runs the same build, so the published tarball is always built from current source.

The TypeScript compiler, driven by npm-style scripts in package.json through pnpm. Both are standard tools in this ecosystem.

The whole toolchain is FLOSS: Node.js, TypeScript, pnpm, Biome, and Vitest.

A Vitest suite under tests/, released as FLOSS with the project under the ISC license. pnpm test runs it; CONTRIBUTING.md and the README both document that, and CI runs it on every push and pull request. https://github.com/FranCanias/norefs/tree/main/tests

pnpm test, the standard test script for a package in the npm ecosystem.

tests/fixtures holds one file per usage pattern the analysis must recognize, and every fixture is referenced by at least one test. The CLI is tested as a binary: cli.test.ts and smoke.test.ts spawn the built dist/index.js against fixture projects, so flags, reporters, and exit codes are exercised end to end. A coverage job runs on every push. Its line number understates the real coverage, because V8 instrumentation cannot see the spawned child processes that run much of the CLI — the number is reported to name uncovered files, never gated, so no test is ever written just to raise it.

GitHub Actions runs on every push and pull request: the linter, the type check, a build, and the full suite on Node 22.12 and 24; a separate job builds and runs the binary on Node 22.4, the floor that "engines" promises; a coverage job; and norefs over its own source, which has to stay at zero findings. https://github.com/FranCanias/norefs/blob/main/.github/workflows/ci.yml

CONTRIBUTING.md sets the policy: one behaviour per test with the assertion naming the behaviour, one fixture per usage pattern, and a new check needs both tests and a corpus note in docs/corpus.md before it ships.

The practice holds in the history: every release in CHANGELOG.md that adds a check or a flag lands with tests in the same change, and the suite grew with the tool through v0.9.0. https://github.com/FranCanias/norefs/blob/main/CHANGELOG.md

Written down in CONTRIBUTING.md, under "The test suite" and "Adding a check". https://github.com/FranCanias/norefs/blob/main/CONTRIBUTING.md

Two layers. Biome runs as a linter over the whole repository through pnpm check (biome ci), with the recommended preset plus unused variables, unused imports, empty blocks, and ts-ignore all escalated to errors. TypeScript compiles under strict, with noUncheckedIndexedAccess and exactOptionalPropertyTypes on top of it.

Both tools are errors, not warnings, and both run in CI on every push and pull request — a diagnostic fails the build, so main carries none.

TypeScript runs under strict with noUncheckedIndexedAccess and exactOptionalPropertyTypes, which are stricter than the strict preset alone, and the type check covers tests as well as src. Suppressions are constrained rather than free: the Biome rule against ts-ignore is an error.

The sole maintainer is familiar with the Saltzer and Schroeder principles, and the project's design shows where they apply. Attack surface is deliberately small: norefs makes no network request ever, and runs exactly two external commands — git status --porcelain and whatever the user passes to --verify-command — with both call sites named in SECURITY.md so a third is a reviewable bug. Least privilege and fail-safe defaults: the tool reads by default and writes only when a writing flag asks it to, and it refuses to fix a dirty working tree without consent. Open design: the whole analysis, its heuristics, and its limits are documented and public.

Yes. For a local static-analysis CLI the relevant classes are command injection, path traversal, unsafe file writes, and denial of service on hostile input. The mitigations are in the design: no shell string is built from analyzed content, the only user-supplied command is the explicit --verify-command, writes happen only under a writing flag and only inside the analyzed project, and the tool never reaches the network. SECURITY.md states these as promises, so a violation is reportable as a security bug rather than a surprise.

norefs reads and rewrites TypeScript and makes no network request

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Nothing in the build or release path fetches a hash over http. The package installs from npm over HTTPS and is published through OIDC trusted publishing with provenance attestation, so each release is signed and traceable to the workflow that built it.

No vulnerability in this project has ever been publicly known, so none is unpatched. Dependency advisories are watched by Dependabot and a weekly audit workflow.

None has been reported. SECURITY.md commits to shipping the fix and the advisory together, as a new release rather than a backport.

The repository holds no credentials. Publishing uses npm OIDC trusted publishing, so no npm token exists in the repository or in GitHub secrets, and the release workflow needs none.

CodeQL runs on every push to main and weekly on a schedule, and uploads its results to GitHub code scanning. Biome's linter runs on every push and pull request. norefs is also run over its own source in CI, where it has to stay at zero findings. https://github.com/FranCanias/norefs/blob/main/.github/workflows/security.yml

CodeQL's JavaScript and TypeScript queries look for common vulnerability patterns, not just style defects.

CodeQL currently reports zero results on main, so there is nothing outstanding to fix. Results go to GitHub code scanning, where new findings surface on the run that introduces them.

On every push to main, on every pull request for the linter, and weekly on a schedule for CodeQL and the dependency audit — because an advisory can land on a day nobody pushes.

The project is written in TypeScript and runs on Node.js. No part of it is written in a memory-unsafe language.

The suite is assertion-dense by policy: one behaviour per test, with the assertion naming the behaviour. Evidence strings, the Verified line, and the exit codes are pinned by tests word for word, so a refactor cannot quietly widen what the analysis claims to prove.

No dynamic analysis tool is in use, so none has found a vulnerability to fix.