facet

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 change is committed to main as it is made, not only at release time. main's history contains the full sequence of interim commits between releases, each landed through a reviewable pull request, so work is available for collaborative review well before it is released.

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

Every release has a unique version identifier following Semantic Versioning, recorded in the package.json of each released package, tagged in git as vX.Y.Z, and released to npm under that exact version.

The project uses Semantic Versioning (SemVer), currently in the 0.x pre-1.0 series.

Each release is tagged in git as vX.Y.Z, and the tags are pushed to the public repository.

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

There have been no publicly known run-time vulnerabilities with a CVE assignment or similar in Facet itself, so there are none to identify in any release notes. The criterion's own guidance directs choosing N/A where there have been no publicly known vulnerabilities. Dependency vulnerabilities are handled separately via Dependabot and are out of scope for this criterion, which applies to project results rather than dependencies.

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

GitHub Issues at https://github.com/writerslogic/facet/issues is used as the issue tracker for individual issues, with labels (bug, enhancement, help wanted, good first issue) used to categorise them.

No externally submitted bug reports have been received in the last 2-12 months. All issues currently in the tracker were opened by the maintainer as enhancement and roadmap items rather than user-submitted bug reports, so there is no backlog of unacknowledged bug reports. The maintainer monitors the tracker and responds to incoming reports.

No externally submitted enhancement requests have been received in the last 2-12 months. All open issues are maintainer-authored roadmap and enhancement items, several deliberately labelled 'help wanted' and 'good first issue' to invite outside contribution. The maintainer monitors the tracker and responds to incoming requests.

https://github.com/writerslogic/facet/issues?q=is%3Aissue - all issues and their full comment threads, both open and closed, remain publicly readable and searchable indefinitely through GitHub Issues, without authentication.

https://github.com/writerslogic/facet/blob/main/SECURITY.md documents the vulnerability reporting process, states that vulnerabilities must not be reported through public GitHub issues, and gives two private channels. It also distinguishes defects in Facet itself from problems with a particular deployed instance, directing the latter to that instance's operator via their /.well-known/security.txt contact.

Private reporting is supported through two channels documented in https://github.com/writerslogic/facet/blob/main/SECURITY.md : GitHub private security advisories at https://github.com/writerslogic/facet/security/advisories/new, and email to admin@writerslogic.com. SECURITY.md also asks reporters not to include real API keys, admin tokens or .dev.vars contents.

No vulnerability reports have been received in the last 6 months, so there is no response time exceeding 14 days. SECURITY.md commits to an initial response within a few days, well inside the 14-day requirement.

The project builds with pnpm workspaces. A single 'pnpm build' at the repository root rebuilds every workspace (dashboard, server, client, CLI, shared, trust) from source. The build runs in CI on every pull request, so it is continuously verified to work from a clean checkout.

The build uses widely adopted, standard tooling for the TypeScript ecosystem: pnpm for workspace and dependency management, TypeScript for compilation, tsup/esbuild for bundling, Vite for the dashboard, and Wrangler for the Cloudflare Workers target.

Every build dependency is FLOSS: pnpm (MIT), TypeScript (Apache-2.0), tsup (MIT), esbuild (MIT), Vite (MIT), Biome (MIT/Apache-2.0), Vitest (MIT) and Wrangler (MIT/Apache-2.0). The project can be built end to end on a FLOSS operating system with no proprietary tooling. Deploying to Cloudflare requires a Cloudflare account, but building the software does not.

The project uses Vitest (MIT), via @cloudflare/vitest-pool-workers so tests execute in the real workerd runtime rather than a mock. The whole suite is run with 'pnpm test' from the repository root. This is documented in CONTRIBUTING.md and is the exact command run by .github/workflows/ci.yml on every pull request.

The suite is invoked with 'pnpm test', the standard npm-script convention for JavaScript and TypeScript projects. Individual workspaces are testable with 'pnpm --filter <package> test'.

The suite contains over 1700 tests spanning every workspace: the Worker's HTTP routes and request validation, the D1 data layer and schema migrations, the privacy and identity core (visitor hashing, consent, retention, differential privacy), the trust and signing package (Ed25519/ECDSA, JWS/COSE, Merkle mountain range transparency log), the CLI, and the dashboard. Coverage includes negative and boundary cases for request-derived input, since query parameters and other untrusted values are validated at the Worker boundary.

https://github.com/writerslogic/facet/blob/main/.github/workflows/ci.yml runs on every push and pull request, performing Biome lint, strict TypeScript typecheck, a full build, a release-link check and the complete test suite. main is protected by a repository ruleset requiring a pull request and passing status checks, so nothing is integrated without CI passing.

CONTRIBUTING.md states the policy directly: 'Every change that adds logic adds/updates a colocated *.test.ts. Keep the suite green.' It further requires that CI (lint, typecheck, build, test) must pass before merge. main is protected, so every change lands through a pull request where this is enforced.

Recent feature work shipped with its tests in the same pull request. Examples on main: the per-job cron cadence, tiered rollups and refreshable bot ruleset work added scheduled, coarsen and bots test coverage; the retention purge cadence fix added a test pinning the hourly cron guarantee; and a build race fix was verified against the restored client size-budget test. Each module in apps/server/src has a corresponding <module>.test.ts in apps/server/test.

The policy is documented in CONTRIBUTING.md, which is the instruction document for change proposals: 'Every change that adds logic adds/updates a colocated *.test.ts. Keep the suite green.' The same file documents the commands for running the suite and the CI gate that enforces it.

Two mechanisms are enabled. TypeScript runs in strict mode (strict: true) across all six workspaces, which is the language's safe mode: no implicit any, strict null checks, and strict function types. Biome is used as the linter and formatter across the repository. Both run in CI via 'pnpm typecheck' and 'pnpm lint'.

Typecheck and lint both run in CI on every pull request and a failure blocks the merge, since passing status checks are required by the branch ruleset. The codebase typechecks clean under strict mode across all workspaces, and lint is clean apart from one deliberate, reviewed naming-convention warning on a required browser global, documented in a code comment explaining why the name must take that form.

TypeScript strict mode is enabled repository-wide rather than per-file, with no implicit any and no non-null assertions used to bypass genuine null paths. Biome runs in its checking mode ('biome ci .') in CI. Deprecation warnings are treated as work to schedule rather than noise: a deprecated test-runtime export was migrated across all 75 affected test files rather than suppressed.

The primary developer applies the secure design principles this criterion enumerates, with concrete evidence in the codebase: least privilege and limited attack surface (the D1 schema is deliberately closed and the API surface is kept minimal); input validation at the trust boundary (all query parameters and request-derived values are validated at the Worker boundary, with uniform error shapes so validity information is not leaked through error responses); fail-safe defaults (visitor hashing throws rather than silently downgrading when an identity tier's required input is absent); complete mediation (authorisation is checked on every privileged operation, not only at entry); and use of standard, reviewed cryptography rather than bespoke primitives. The threat model is documented in docs/privacy.md and docs/trust.md.

The project actively defends against the common error classes for a web analytics service. Injection: all D1 access goes through a parameterised data layer, with no ad hoc SQL in route handlers. XSS: the dashboard escapes untrusted values before rendering. Regular expression denial of service: remotely supplied bot-detection patterns are shape-checked and rejected before compilation, with a bounded pattern count and length. Cross-tenant data exposure: tenant isolation is enforced per request and cron failures are isolated per tenant. Privacy-specific failure modes are treated as security failures, since a persistent identifier or cross-session join key would break the product's core guarantee. CodeQL's extended query suite runs on every pull request as a backstop, and all findings are triaged and either fixed or dismissed with a recorded reason.

All cryptography uses reviewed, openly specified standards: Ed25519 (RFC 8032) and ECDSA P-256 for signatures, SHA-256 for hashing, JWS (RFC 7515) and COSE (RFC 9052) for signature envelopes, JSON Canonicalization Scheme (RFC 8785) for deterministic serialisation, and a Merkle mountain range for the transparency log. No proprietary or unreviewed algorithms are used. See docs/standards.md and docs/trust.md.

Facet's primary purpose is analytics, not cryptography. All primitives come from the Web Crypto API built into the Cloudflare Workers runtime, and from the jose library for JWS/JWT handling. The project does not implement its own hashes, ciphers or signature algorithms. The trust package composes these primitives into standards-defined structures (JWS, COSE, MMR) but does not implement primitives itself.

All cryptographic functionality is implementable with FLOSS. The Web Crypto API is a public web standard with multiple FLOSS implementations, and jose is MIT licensed. No proprietary cryptographic library is required to build, run or verify Facet's cryptographic output.

Defaults exceed the NIST minimums for 2030. Signatures use Ed25519 (256-bit curve, roughly 128-bit security) or ECDSA on P-256; hashing uses SHA-256. No algorithm or key size below these is offered or accepted anywhere in the codebase, so shorter keylengths are not merely disablable but entirely absent.

No broken algorithm is used anywhere. There is no MD4, MD5, single DES, RC4 or Dual_EC_DRBG in the codebase, and no interoperability requirement forces one. All hashing is SHA-256 and all signing is Ed25519 or ECDSA P-256.

No algorithm with known serious weaknesses is used. SHA-1 is not used anywhere. Only SHA-256, Ed25519 and ECDSA P-256 are used, none of which has a known serious weakness.

All network transport is TLS terminated by Cloudflare, which provides forward secrecy through ephemeral key agreement. Facet does not define its own key agreement protocol; its own cryptographic use is signing and hashing, where forward secrecy does not apply.

Facet does not store user passwords; there are no end-user password accounts. API keys are the credential, and they are never stored in recoverable form: only a SHA-256 hash of the key is persisted, and the plaintext key is displayed exactly once at issuance and never again. Because these are high-entropy machine-generated keys rather than human-chosen passwords, a key stretching algorithm is not the applicable control, so this criterion does not apply.

All key and nonce generation uses crypto.getRandomValues and crypto.subtle.generateKey from the Web Crypto API, which are cryptographically secure. Math.random is not used for any security-relevant value anywhere in the codebase; this is enforced in review and backstopped by CodeQL's js/insecure-randomness query, which currently reports no open findings.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

No hash is ever retrieved over plain HTTP. Dependency integrity hashes are committed in pnpm-lock.yaml in the repository itself rather than fetched, and all registry traffic is HTTPS. Released packages additionally carry npm provenance and SLSA build provenance attestations, which are cryptographically signed and verifiable.

There are no unpatched vulnerabilities of medium or higher severity. Facet itself has had no CVE assigned. Dependency vulnerabilities are tracked by Dependabot and GitHub's advisory database: 22 alerts have been raised over the project's lifetime and all 22 have been fixed, with zero currently open. CodeQL static analysis findings are likewise all either fixed or explicitly dismissed with a recorded justification.

Critical and high severity dependency alerts are fixed promptly, typically within days, through Dependabot pull requests that must pass the full CI gate before merging. All 22 lifetime alerts, including a series of 17 for a single transitive dependency, have been resolved; none remains open.

No valid private credential is present in the repository. Runtime secrets are held as Cloudflare Worker secrets and never committed. Local development secrets live in .dev.vars, which is gitignored. API keys are persisted only as SHA-256 hashes. The operator's deployment-specific configuration is deliberately kept out of the repository. GitHub secret scanning with push protection is enabled and reports no exposed secrets.

CodeQL is applied to every proposed change and to the default branch, using GitHub's default setup with the 'extended' query suite for JavaScript/TypeScript and for GitHub Actions workflows. This runs in addition to Biome lint and TypeScript strict mode. Analysis runs on every pull request and on a weekly schedule, so every release is analysed before it is cut.

CodeQL's 'extended' query suite for JavaScript/TypeScript includes the security query packs covering the common vulnerability classes for this language: injection, cross-site scripting, path traversal, insecure randomness, regular expression denial of service, and unsafe deserialisation. The GitHub Actions language pack additionally analyses the project's own CI workflows.

There are no open CodeQL security findings. Every finding raised has been either fixed in code or explicitly dismissed with a recorded reason where it is not exploitable. Examples of dismissals: a ReDoS query fires on a deliberately malicious regular expression used as a negative test fixture, which the code under test rejects before it ever reaches the regex compiler; and a file-access-to-network query flags the CLI reading the operator's own local Wrangler config and then contacting that operator's own deployment, which is the intended function rather than a vulnerability.

CodeQL runs on every pull request and on every push to the default branch, plus a weekly scheduled scan. Biome lint and strict TypeScript typechecking additionally run on every pull request through .github/workflows/ci.yml.

The project produces no software written in a memory-unsafe language. It is implemented entirely in TypeScript, which compiles to JavaScript and runs in a memory-safe runtime, so this criterion does not apply.

No dynamic analysis tooling is in use, so no vulnerabilities have been discovered by dynamic analysis and there are none outstanding.