SitePing

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.

All development happens in the open on GitHub. Every change lands on main as a squash-merged pull request with its full review history, and the intermediate commits are visible on the branch before merge, so the state between releases is always publicly reviewable rather than only tagged releases.

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

This is a monorepo of independently versioned packages. Each release gets a unique identifier managed by release-please and published to npm, tagged in git with a package-scoped tag (for example widget-v0.10.5, dashboard-v0.2.3, cli-v0.5.2). See https://github.com/NeosiaNexus/SitePing/releases

Semantic Versioning, derived automatically from Conventional Commits by release-please. All packages are currently pre-1.0, so per SemVer the project uses the documented pre-1.0 convention (feat bumps patch, breaking changes bump minor); this is spelled out in https://github.com/NeosiaNexus/SitePing/blob/main/CONTRIBUTING.md#releases--versioning

Every release is tagged in git, automatically by release-please, using package-scoped tags such as widget-v0.10.5. See https://github.com/NeosiaNexus/SitePing/tags

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

No vulnerability in SitePing's own code has ever been publicly known or assigned a CVE, so there is nothing of this kind to identify in the release notes. Vulnerabilities in dependencies are handled separately via Dependabot and a dependency-review gate on every pull request.

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

GitHub Issues is used to track every individual issue, with structured bug-report and feature-request templates and a labelling scheme applied automatically. See https://github.com/NeosiaNexus/SitePing/issues

Every bug report submitted by a user in this period was acknowledged and resolved. Externally reported issues: #157 (widget identity inputs rendering white-on-white) answered and closed, and #190 (right-click annotation entry point) answered and shipped. The remaining open issues in the tracker are the maintainer's own planning and tracking items, not user-submitted reports.

Enhancement requests receive a substantive reply. The externally submitted enhancement #190 was discussed across several comments, accepted, implemented with the reporter, and released in @siteping/widget 0.10.1, with the contributor credited.

The full archive of reports and responses is public and searchable via the GitHub issue tracker, including closed issues: https://github.com/NeosiaNexus/SitePing/issues?q=is%3Aissue

The process is published in SECURITY.md: https://github.com/NeosiaNexus/SitePing/blob/main/SECURITY.md — it asks reporters not to open a public issue and gives two channels, GitHub private security advisories (preferred) and a security email address, together with the information to include and the disclosure policy.

Private reporting is supported through two channels documented in https://github.com/NeosiaNexus/SitePing/blob/main/SECURITY.md : GitHub's private vulnerability reporting at https://github.com/NeosiaNexus/SitePing/security/advisories/new (preferred), and email to security@neosianexus.dev . SECURITY.md explicitly tells reporters not to use public issues.

No vulnerability report has been received to date. SECURITY.md commits to acknowledging a report within 48 hours and completing an initial assessment within one week, both well inside the 14-day requirement.

The project builds from source with a single command, bun install && bun run build, orchestrated by Turborepo across the workspace and compiled with tsup/TypeScript. The same command is what CI runs on every pull request. Documented in https://github.com/NeosiaNexus/SitePing/blob/main/CONTRIBUTING.md#setup

Standard JavaScript ecosystem tooling: Bun as package manager and runner, Turborepo for build orchestration, tsup (esbuild) for bundling, and the TypeScript compiler for type declarations. Node.js 20, 22 and 24 are exercised in CI.

Every build tool is FLOSS: Bun (MIT), Turborepo (MIT), tsup (MIT), esbuild (MIT), TypeScript (Apache-2.0), Biome (MIT/Apache-2.0). No proprietary tool is required to build the project.

Two FLOSS automated suites: Vitest for unit tests (2016 tests across 72 files) and Playwright for end-to-end tests on Chromium, Firefox and WebKit. How to run them is documented in https://github.com/NeosiaNexus/SitePing/blob/main/CONTRIBUTING.md#testing (bun run test:run, bun run test:e2e) and both run on every pull request in https://github.com/NeosiaNexus/SitePing/blob/main/.github/workflows/ci.yml

The suites are invoked through the standard npm-script convention for this ecosystem: bun run test (watch), bun run test:run (single run) and bun run test:e2e, declared in the root package.json.

Coverage is measured with istanbul and enforced as a CI gate with thresholds of 95% for lines, functions and statements and 92% for branches, configured in vitest.config.ts. The suite currently reports 97.9% statements and 99.0% lines. Property-based tests additionally cover generated inputs rather than only hand-picked examples.

GitHub Actions runs the full pipeline on every pull request and every push to main: build, type-check, lint, unit tests with coverage, Playwright E2E, bundle-size gates, package-publish checks, and compatibility matrices for Node 20/22/24 and React 18. See https://github.com/NeosiaNexus/SitePing/blob/main/.github/workflows/ci.yml

CONTRIBUTING.md states the policy explicitly: new features must be covered by unit tests, and user-facing flows by E2E tests where relevant. The pull-request guidelines repeat it as a requirement: "Include tests for any new behavior or bug fix." See https://github.com/NeosiaNexus/SitePing/blob/main/CONTRIBUTING.md#testing

The policy is followed in practice. Recent examples: the right-click annotation feature shipped with its own unit tests; a pagination defect in the feedback filter was fixed together with the property-based suite that found it; the widget re-entry fix added regression tests. Coverage thresholds are enforced in CI, so a change that adds untested code fails the build.

The requirement is documented in the instructions for change proposals, in both the Testing section and the Pull Request Guidelines of https://github.com/NeosiaNexus/SitePing/blob/main/CONTRIBUTING.md

TypeScript runs in strict mode with additional strictness beyond the defaults (exactOptionalPropertyTypes, noUncheckedIndexedAccess), and Biome is used as the linter and formatter across the whole repository. Both are CI gates (bun run check, bun run lint). Workflows are additionally linted with actionlint and audited with zizmor.

Warnings are treated as build failures rather than advisory output: bun run check (tsc --noEmit) and bun run lint (biome check) are required status checks on every pull request, so main cannot contain an unaddressed type error or lint finding.

The project is deliberately stricter than the language defaults: strict, exactOptionalPropertyTypes and noUncheckedIndexedAccess are all enabled in tsconfig.base.json, and the published packages are additionally verified with publint and are-the-types-wrong under every module-resolution mode.

The maintainer applies secure-design principles in the codebase and CI: least privilege (every GitHub Actions token is scoped per job, workflows default to read-only), input validation at the trust boundary (all HTTP inputs validated with Zod schemas before reaching the store), limited attack surface (the widget renders inside a closed Shadow DOM), fail-safe defaults (screenshot capture and diagnostics are opt-in), and defence in depth (CodeQL, zizmor, dependency review, secret-scanning push protection).

The project actively counters the common error classes for this kind of software. Injection and untrusted input: all HTTP query and body inputs are validated with Zod, and no user input is interpolated into shell steps in workflows (audited by zizmor and CodeQL's actions queries). Timing attacks on credential checks: API keys are compared with node:crypto timingSafeEqual rather than string equality. Cross-site scripting: the widget uses DOM construction inside a closed Shadow DOM rather than innerHTML with user content. Supply-chain compromise: all GitHub Actions and container images are pinned by hash, and Dependabot plus a dependency-review gate cover known vulnerable dependencies.

The project implements no cryptography of its own. Where cryptographic primitives are used they come from published, expert-reviewed standard libraries: the Web Crypto API (crypto.randomUUID) and Node.js node:crypto (timingSafeEqual). Transport security is delegated to HTTPS/TLS provided by the host.

No cryptographic function is re-implemented. The project calls only the platform's own implementations: node:crypto on the server side and the Web Crypto API in the browser.

All cryptographic functionality relied on is provided by FLOSS implementations: Node.js (MIT) and the Web Crypto API as implemented by open-source browser engines. Nothing requires a proprietary cryptographic library.

The project generates and configures no cryptographic keys. It stores no keys, negotiates no sessions and exposes no keylength setting; API credentials are supplied and managed entirely by the host application.

No broken algorithm is used. The project depends on no hash or cipher of its own; the only primitives called are crypto.randomUUID and timingSafeEqual. MD4, MD5, SHA-1, single DES, RC4 and Dual_EC_DRBG appear nowhere in the codebase.

No cryptographic algorithm or mode with known serious weaknesses is used, since the project implements no cryptographic mechanism of its own and relies on the host's TLS configuration for transport.

The project implements no key-agreement protocol. Transport security, including forward secrecy, is provided by the TLS configuration of the host application and of npm/GitHub for distribution.

The project never stores passwords. It authenticates optional server-side requests with a host-supplied API key that it only compares, never persists, and it holds no user credentials of any kind.

No cryptographic keys or nonces are generated by the project. The only random values are non-security identifiers used to correlate a browser with its own feedback, plus jitter on request retries. Identifiers prefer crypto.randomUUID (CSPRNG-backed) and fall back to a timestamp-plus-Math.random string only in non-secure browsing contexts where the Web Crypto API is unavailable; nothing security-relevant depends on their unpredictability.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Everything is retrieved over HTTPS with integrity verification. Dependencies resolve through bun.lock, which records an integrity hash for every package; all GitHub Actions are pinned to a full commit SHA rather than a mutable tag; container base images are pinned by digest; and packages are published to npm with build provenance attestations (npm publish --provenance).

There are currently no known unpatched vulnerabilities of any severity. The six advisories that osv-scanner reported in the dependency tree (affecting brace-expansion, esbuild, postcss and sharp) were remediated within days of being surfaced, and a rescan of the lockfile reports no issues. Dependabot with security updates enabled and a dependency-review gate that fails a pull request on any moderate-or-higher advisory keep it that way.

Critical and high-severity advisories are fixed promptly. The four high-severity dependency advisories most recently reported were resolved in a single change within a day of detection. Dependabot security updates bypass the ordinary seven-day cooldown so security bumps arrive immediately.

No valid credential is present in the repository. All secrets used by CI (npm publishing token, release token, Codecov token) are stored as GitHub Actions secrets and referenced by name only. GitHub secret scanning and push protection are enabled on the repository, and CodeQL runs on every pull request.

Several static analysis tools run beyond compiler warnings. CodeQL analyses both the TypeScript sources and the GitHub Actions workflows with the security-extended query suite; Biome lints the whole codebase; actionlint and zizmor audit the workflow definitions; publint and are-the-types-wrong validate the published package artifacts. See https://github.com/NeosiaNexus/SitePing/blob/main/.github/workflows/codeql.yml

CodeQL is run with the security-extended query suite, which targets common vulnerability classes for JavaScript/TypeScript such as injection, unsafe deserialization and path traversal. It is complemented by CodeQL's actions queries and by zizmor, which specifically looks for workflow security anti-patterns like script injection from untrusted event input and unpinned actions.

Findings are surfaced as GitHub code-scanning alerts and triaged as they appear; there are currently no open unresolved medium-or-higher severity findings. Because CodeQL and the linters run as required checks on every pull request, a change that introduces a finding is caught before it reaches main.

Static analysis runs on every commit, not periodically: CodeQL is triggered on every pull request and every push to main, with an additional weekly scheduled run; Biome, the TypeScript compiler, actionlint and zizmor run in the same per-pull-request pipeline.

Two kinds of dynamic analysis run on every pull request. Playwright drives the real widget in Chromium, Firefox and WebKit end to end. Property-based tests built on fast-check generate randomised inputs against the DOM re-anchoring matcher and the feedback filtering pipeline, checking invariants rather than fixed examples; this found and led to the fix of a real pagination defect.

The project produces no software written in a memory-unsafe language. It is written entirely in TypeScript, running on JavaScript engines and Node.js, both of which are memory-safe environments.

The test suites run assertion-heavy by design: unit and property tests assert invariants on every generated case, and the property suites are configured to shrink a failing case to its minimal reproduction. Builds and tests run with TypeScript strict checking rather than a stripped production configuration.

No medium-or-higher severity exploitable vulnerability has been discovered by dynamic analysis. The one defect it did surface, a pagination bug where a non-positive page index read records from the end of the result set, was fixed in the same change that introduced the test which found it.