caribbean-countdowns

The project is a website, not a versioned software library — end users access it via a URL and always receive the current version automatically. There is no installation to upgrade and no older version to maintain. CHANGELOG.md documents changes between versions for contributors and transparency. No upgrade path documentation is needed as there is nothing to install or update on the user side.

GitHub Issues is our issue tracker. Same URL: https://github.com/countdowns-co/caribbean-countdowns/issues

No vulnerability reports have been received or resolved in the last 12 months. The project launched in 2026 and has had no confirmed security vulnerabilities to date.

SECURITY.md documents the full response process: reports are acknowledged within 48 hours of receipt, and a fix is targeted within 14 days for confirmed vulnerabilities. The preferred channel is GitHub Security Advisories (private disclosure). Public issue reports for security vulnerabilities are explicitly discouraged.

URL: https://github.com/countdowns-co/caribbean-countdowns/blob/main/SECURITY.md

CONTRIBUTING.md identifies the style guides for the project's primary languages and requires contributions to comply. JavaScript follows the MDN JavaScript guidelines, with key rules (strict equality, no undefined variables, no unused variables) automatically enforced by ESLint on every PR. Astro components follow the Astro documentation syntax guidelines. Compliance is enforced automatically — PRs that fail the lint step cannot be merged.

URL: https://github.com/countdowns-co/caribbean-countdowns/blob/main/CONTRIBUTING.md

ESLint enforces the project's JavaScript coding standards automatically on every PR via the CI pipeline. The configuration is committed to the repository (eslint.config.js). PRs that produce ESLint errors cannot be merged. No style exceptions currently exist in the codebase.

The project produces a static website, not native binaries. No compiler or linker is involved in the build process.

The project produces a static website with no compiled binaries. There is no build or installation system that handles debugging symbols or stripping.

The project produces a static website built. There is no custom build system with recursive subdirectory compilation or cross-dependencies between build units.

The build is fully deterministic. Given the same source files and the same input data, Astro always produces identical output. The CI pipeline uses locked dependencies (npm ci) to ensure the same versions are resolved on every run. No timestamps or random seeds are embedded in the build output. The same commit built twice produces the same static files.

The project produces a static website accessed via a URL. There is nothing to install or uninstall — users simply visit the site in a browser.

The project produces a static website with no installation system for end-users. There are no built artifacts written to a local filesystem.

The full development environment is set up with two commands using the standard Node.js convention. This is documented in the Quick start section of README.md.

URL: https://github.com/countdowns-co/caribbean-countdowns/blob/main/README.md

All external dependencies are listed in package.json in standard npm format, which is machine-readable and processed automatically by the Node.js package manager. Both runtime and development dependencies are declared with pinned version ranges.

URL: https://github.com/countdowns-co/caribbean-countdowns/blob/main/package.json

External dependencies are monitored through two automated mechanisms: Dependabot checks for known vulnerabilities daily and opens pull requests for updates, and npm audit runs on every CI build blocking merges when high-severity vulnerabilities are detected. Both are active on the repository.

All reused components are managed through npm and declared in package.json. Updating any dependency is a single command (npm update) or handled automatically by Dependabot pull requests. No vendored or forked copies of libraries exist in the repository — all dependencies are fetched from the npm registry.

The project uses modern, current APIs throughout. ESLint's no-deprecated checking and astro check flag deprecated usage at the TypeScript level. All dependencies are kept current via Dependabot. No deprecated browser APIs, Node.js APIs, or Astro APIs are knowingly used in the codebase.

The CI pipeline runs automatically on every push and pull request to main. It executes npm test (type checker) and npm run lint (linter) and reports pass/failure as a required status check on every pull request. Results are visible in the GitHub Actions tab and block merging on failure.

All code bugs fixed in the last six months were linting or type errors — caught by the automated test suite and permanently prevented from regression. The six ESLint issues fixed in ngo.js (unused variables, loose equality) are now caught by ESLint on every PR. The TypeScript error in CountdownTimer.ts is permanently caught by astro check. Both tools run on every check-in, making the fixes themselves act as regression tests. No fixed bug can be silently reintroduced without CI failing.

The software produced is a static website (HTML output), not a library. The JS files are small browser utility scripts without complex business logic. No FLOSS tool can measure coverage of classic browser scripts without module refactoring.

CONTRIBUTING.md contains the explicit policy: "when major new functionality is added, tests for that functionality must be added to the automated test suite before the PR is merged." This is a formal written requirement enforced through the mandatory PR review process.

URL: https://github.com/countdowns-co/caribbean-countdowns/blob/main/CONTRIBUTING.md

in CONTRIBUTING.md under ## Tests and CI: "when major new functionality is added, tests for that functionality must be added to the automated test suite before the PR is merged."

URL: https://github.com/countdowns-co/caribbean-countdowns/blob/main/CONTRIBUTING.md#tests-and-ci

ESLint is configured with no-undef as error (strict) and eqeqeq as error (strict). All warnings are already fixed, leaving zero issues. That demonstrates the project enforces strictness where practical.

The project applies secure design principles throughout:

• Fail-safe defaults — CSP blocks all inline scripts and non-origin resources by default; the site serves no dynamic content without explicit configuration
• Economy of mechanism — fully static architecture with no server-side logic, no authentication system, no database; attack surface is minimal by design
• Least privilege — the community API endpoint is read-only by default; write operations are rate-limited; CI credentials are scoped to deployment only
• Complete mediation — all dependency changes go through automated audit before reaching production; all code changes require reviewed pull requests
• Separation of privilege — data is separated from code (private storage at build time); secrets never enter the repository

Static website, no cryptographic mechanisms in the project code.

The project does not implement cryptography. All TLS and transport security is handled entirely by the hosting and delivery infrastructure, outside the project's codebase. There are no cryptographic algorithms to select or switch between.

The project does not process authentication credentials or private cryptographic keys. The site is fully static with no login system, no password storage, and no key management in the codebase.

All network communications use HTTPS exclusively. Plain HTTP is rejected at the infrastructure level — requests are redirected to HTTPS automatically. TLS 1.2 or later is enforced; older SSL versions are disabled. No insecure protocols (FTP, HTTP, telnet) are supported or configurable.

TLS 1.2 is the minimum version enforced across all connections. TLS 1.3 is supported and preferred. Older versions (SSL, TLS 1.0, TLS 1.1) are disabled.

TLS certificate verification is handled by the browser for all connections, including subresources. The site makes no direct TLS connections in server-side code — there is no custom TLS implementation that could bypass certificate verification. The single API call (community stats endpoint) is a browser fetch() to an HTTPS URL, which enforces certificate verification by default with no option to disable it.

The site sets no authentication cookies and transmits no private HTTP headers. There is no private information sent over HTTP headers — the site is fully public and unauthenticated

The project produces a static website accessed via a URL — there are no downloadable releases, packages, executables, or artifacts intended for end-user installation. Users do not download or install the project results; they visit the live site in a browser. There is nothing to sign or verify from an end-user perspective.

The project's only server-side input point is the community stats API. It validates all untrusted input with an allowlist approach:

• The URL pathname is checked exactly (/api/ngo-stats) — all other paths return 404
• Only GET and POST methods are accepted — all others return 405
• The POST body is parsed as JSON; malformed JSON returns 400
• The contribution value is clamped to a valid numeric range (0–5) using Math.max/Math.min, with parseFloat defaulting to 0 for non-numeric input
• The cumulative progress is hard-capped at 94

The static site itself accepts no runtime user input. The suggest-event wizard is client-side only and generates no server-side request.

The site applies a comprehensive set of HTTP hardening headers on every response: Content Security Policy (script-src 'self' blocking all inline scripts and external script sources), HTTP Strict Transport Security (HSTS), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Referrer-Policy: strict-origin-when-cross-origin. The CSP is the primary hardening control — it makes XSS defects unexploitable by preventing inline script execution entirely. No native binaries are produced so compiler hardening flags are not applicable.

SECURITY.md contains a complete assurance case covering: threat model (web attacks, supply chain compromise, data tampering, denial of service), trust boundaries (five boundaries identified with descriptions), secure design principles applied (fail-safe defaults, economy of mechanism, least privilege, separation of privilege, complete mediation), and a countermeasure mapping against all ten OWASP Top 10 categories.

URL: https://github.com/countdowns-co/caribbean-countdowns/blob/main/SECURITY.md

ESLint's no-undef rule catches undefined variables (a common source of unintended global state and injection-adjacent bugs), and eqeqeq enforces strict equality to prevent type coercion vulnerabilities.

The project is written in JavaScript/TypeScript and Astro. No memory-unsafe languages are used.