landerox.github.io

The repository is publicly readable at https://github.com/landerox/landerox.github.io and version-controlled with Git.

Git tracks every change with author, date, and a unique commit SHA. History is preserved on GitHub. Every commit follows Conventional Commits format validated by commitizen.

Every commit on main is an interim version — there are no hidden working branches. Releases are tagged in addition (v0.1.0 published 2026-05-27).

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

Releases use unique SemVer identifiers managed by commitizen (tool.commitizen.version in pyproject.toml; tag_format "v$version"). Git commit SHA is a unique secondary identifier per commit.

Releases are tagged using annotated Git tags (e.g. v0.1.0). Each tag corresponds to a GitHub Release with full notes.

CHANGELOG.md follows Keep a Changelog 1.1.0 with manual entries (intentionally NOT auto-generated from commits — see docs/decisions.md (Changelog Policy)). GitHub Releases publish the same content per tag. The first release v0.1.0 (2026-05-27) is published at https://github.com/landerox/landerox.github.io/releases/tag/v0.1.0. https://github.com/landerox/landerox.github.io/blob/main/CHANGELOG.md

The v0.1.0 release notes already cite a publicly-known CVE fix in the Fixed section: urllib3 was upgraded from 2.6.3 to 2.7.0 to patch CVE-2026-44431 and CVE-2026-44432. Future releases will continue to surface CVE fixes in the same section per the Keep a Changelog convention.

Bug reports are submitted through GitHub Issues using the templates under.github/ISSUE_TEMPLATE/ (bug_report.yml and feature_request.yml). The "/issues/new/choose" page lets reporters pick the appropriate template. https://github.com/landerox/landerox.github.io/issues/new/choose

GitHub Issues is the issue tracker. Templates under.github/ISSUE_TEMPLATE/ structure incoming reports.

The maintainer commits to acknowledge bug reports on a best-effort basis (single maintainer, 1-3 commits/week cadence). Security reports follow the stricter SLA documented in SECURITY.md (48-hour acknowledgement). At the time of badge submission the repository has no outstanding unacknowledged reports.

Enhancement requests submitted via feature_request.yml are reviewed on a best-effort basis by the single maintainer. At the time of badge submission there are no outstanding unanswered enhancement requests.

GitHub Issues provides a public, full-text-searchable archive of all reports (open and closed) with per-issue and per-comment stable URLs. https://github.com/landerox/landerox.github.io/issues?q=is%3Aissue

.github/SECURITY.md documents the vulnerability reporting workflow: use GitHub Private Vulnerability Reporting (Security tab > Advisories > Report a vulnerability). It also defines a disclosure policy: 48-hour acknowledgement, 7-day fix-ETA estimate, notification on resolution. https://github.com/landerox/landerox.github.io/blob/main/.github/SECURITY.md

Private vulnerability reporting is enabled via GitHub Security Advisories. Reporters can open a private advisory at /security/advisories/new and the maintainer is notified privately. Documented as the primary channel in SECURITY.md. https://github.com/landerox/landerox.github.io/security/advisories/new

SECURITY.md commits to a 48-hour initial response on vulnerability reports — well within the 14-day threshold required by the criterion. A 7-day fix-ETA is provided in the same window.

A working build system is provided. just build (Justfile) invokes uv run zensical build for both the English and Spanish configurations, producing the static site under site/. Fully reproducible inside the devcontainer or on a host with Python 3.13 + uv + just installed.

The build chain uses common tools: uv (Astral, standard Python package manager 2025+), just (widely adopted task runner), and zensical (the static site generator itself). All are well-known and actively maintained.

All build tools are FLOSS: uv is MIT-licensed, just is CC0, zensical is MIT, Python is PSF-licensed. The devcontainer base image is from Microsoft's MIT-licensed devcontainers/python.

This is a static content site with no application code, so a traditional automated test suite does not apply. The equivalents are run automatically: lychee for outbound link validation (links.yml), Lighthouse CI for accessibility/performance/SEO/best-practices audits (quality.yml), the pre-commit suite for static checks (cspell, markdownlint, actionlint, zizmor, detect-secrets), and pip-audit for dependency CVEs (lint.yml). All invokable locally via the Justfile. https://github.com/landerox/landerox.github.io/blob/main/Justfile

Six GitHub Actions workflows implement continuous integration: lint.yml (pre-commit + pip-audit on push and daily), deploy.yml (build EN+ES and deploy to Pages), links.yml (weekly Lychee), scorecard.yml (weekly OpenSSF Scorecard), quality.yml (Lighthouse CI on PR + push), and uv-upgrade.yml (weekly transitive-deps refresh).

The repository ships content rather than application code, so the "automated test suite" is the audit suite that runs on every change. The policy is documented at docs/structure.md "Audit policy for content changes" (https://github.com/landerox/landerox.github.io/blob/main/docs/structure.md#audit-policy-for-content-changes). For any new page or content modification: (1) just build (or deploy.yml) must render without error; (2) lychee must validate all links in content/; (3) Lighthouse CI (quality.yml) audits home EN + home ES on every PR and push, with new top-level pages added to .lighthouserc.json; (4) the full pre-commit suite (cspell, markdownlint, actionlint, zizmor, detect-secrets, pip-audit) runs on every commit and on a daily 08:00 UTC cron. Enforcement is local (pre-commit hooks block bad commits, --no-verify forbidden per AGENTS.md) and in CI (workflows are blocking gates before merge to main).

The policy described under test_policy was followed for the most recent major change — the v0.1.0 release (2026-05-27), which is the first public-ready cut of the repository. The release landed through the full audit suite: lint.yml (pre-commit + pip-audit), deploy.yml (build EN + ES), links.yml (lychee), quality.yml (Lighthouse CI), scorecard.yml (OpenSSF Scorecard). Every per-check status is publicly visible in the Actions tab at https://github.com/landerox/landerox.github.io/actions and in the release commit history. New pages added after v0.1.0 will be added to .lighthouserc.json so Lighthouse audits them under the same policy.

Our documented audit policy in structure.md requires that whenever new pages or features are added, they must be added to the automated testing and validation suites (such as.lighthouserc.json). https://github.com/landerox/landerox.github.io/blob/main/docs/structure.md#audit-policy-for-content-changes

The pre-commit suite enables warnings via multiple linters: cspell (EN+ES dictionaries), markdownlint-cli, actionlint (workflow syntax + embedded shellcheck), zizmor (workflow security), detect-secrets, pip-audit, plus the pre-commit-hooks catalog (check-yaml, check-json, check-toml, mixed-line-ending, trailing-whitespace, check-merge-conflict, check-added-large-files, check-case-conflict).

Pre-commit hooks are blocking. AGENTS.md explicitly forbids --no-verify. The CI lint workflow (lint.yml) is also blocking — any warning surfaced by static analysis must be fixed before the change can land on main.

Configuration uses strict policies: zizmor is set to the hash-pin policy (any unpinned Action ref fails); pip-audit fails on any medium-or-higher severity CVE; markdownlint enforces MD013 line length and the full ruleset.

The maintainer's professional focus is data platforms and cloud architecture, with hands-on experience in production security posture. docs/decisions.md documents explicit threat-model choices: SHA-pinned Actions (), workflow security audit via zizmor (), supply-chain posture via OpenSSF Scorecard (), dual-license boundary (), and lockfile maintenance for transitive CVEs ().

Common vulnerability classes are mitigated by specific tools: zizmor for GitHub Actions vulnerabilities (script injection, mutable refs, pull_request_target, dangerous workflow patterns), pinact for the mutable-tag supply-chain class (tj-actions/changed-files 2025 incident), detect-secrets for credential leak class, pip-audit for Python CVEs.

N/A — the repository contains no cryptographic code. TLS for landerox.com is provided by GitHub Pages using industry-standard TLS 1.2+ with modern cipher suites (verified by SSL Labs).

N/A — no cryptographic code in the repository.

N/A — no cryptographic code.

N/A — no cryptographic key management in scope. TLS keys are managed by GitHub Pages.

N/A — no cryptographic algorithms in use within the repository.

N/A — no cryptographic code.

GitHub Pages supports perfect forward secrecy via ECDHE cipher suites in modern TLS. landerox.com inherits this configuration automatically.

N/A — no authentication, no user accounts, no passwords stored.

N/A — the site has no runtime randomness requirements.

All delivery paths use HTTPS or signed channels. The repository is served via github.com over HTTPS. The published site is served via GitHub Pages over HTTPS with enforcement. The devcontainer pulls dependencies over HTTPS from PyPI, ghcr.io, and registry.npmjs.org.

Cryptographic hashes are never retrieved over HTTP. All GitHub Action references in workflows are SHA-pinned and verified by zizmor's hash-pin policy. uv.lock pins each Python dependency by hash. The devcontainer Dockerfile pins lychee and pinact by exact version, fetched over HTTPS from GitHub Releases.

pip-audit runs on every push to main AND daily at 08:00 UTC via lint.yml, against the locked dependency tree. The uv-upgrade.yml workflow refreshes transitive dependencies weekly (Tuesdays 06:00 UTC) and opens an automatic PR. The most recent example is the urllib3 incident on 2026-05-13: CVE-2026-44431 and CVE-2026-44432 (medium severity) were patched within hours of CI detection, well inside the 60-day window.

The same detection pipeline (pip-audit daily cron + uv-upgrade weekly + OpenSSF Scorecard) applies to critical-severity vulnerabilities. Response cadence is hours-to-days, well within "rapid".

detect-secrets runs in pre-commit on every commit against the curated baseline at.config/.secrets.baseline. zizmor audits workflow files for secret-exposure anti-patterns. AGENTS.md hard rule prohibits committing secrets. There are no plausible secrets in scope (the site has no API integrations, no service tokens, no cloud credentials beyond the default GITHUB_TOKEN).

Static analysis is applied continuously. Pre-commit suite enforces analysis on every commit: zizmor (workflow security), actionlint (workflow syntax + embedded shellcheck), cspell (prose, EN+ES), markdownlint (Markdown rules), detect-secrets (credentials), check-yaml / check-json / check-toml. lint.yml CI runs the same suite on every push and daily at 08:00 UTC.

The static analysis stack targets common vulnerability classes: zizmor for the GitHub Actions vulnerability class (script injection, mutable refs, dangerous workflow patterns) that caused the tj-actions/changed-files 2025 incident; pip-audit for Python CVEs via OSV and PyPA advisories; detect-secrets for credential exposure.

Pre-commit hooks are blocking, and CI is a blocking gate for main. No --no-verify is permitted per AGENTS.md hard rule. Medium-or-higher findings from static analysis are fixed before the change can land.

Static analysis runs locally on every commit (pre-commit) and in CI on every push (lint.yml). It also runs on a daily 08:00 UTC cron in lint.yml and weekly Mondays 09:30 UTC via OpenSSF Scorecard (scorecard.yml).

Dynamic analysis is applied via Lighthouse CI (quality.yml) — it audits the built site for performance, accessibility, best-practices, and SEO on every PR and push to main. This is the appropriate form of dynamic analysis for a static content site without runtime application code.

N/A — the repository is Python (memory-safe) plus static Markdown. There is no memory-unsafe language in scope.

Lighthouse CI runs with warn-level assertions today (no findings block deploy). When budgets are tightened in the future (re-evaluation trigger documented in docs/decisions.md ), failures will be fixed promptly. No outstanding medium-or-higher dynamic-analysis findings at the time of badge submission.