Add security & compliance page for vendor due diligence

[tomcounsell]

Plan: docs/plans/security_compliance_page.md

Context: Institutional buyers — development banks like ADB, regulated telecoms, government agencies — conduct vendor due diligence before signing. Their checklists consistently ask for a publicly discoverable security and compliance statement. Yudame's site today has no such surface, which is a concrete blocker for vendor onboarding into systems like ADB's Consultant Management System and for most institutional engagements.

Problem

Current behavior: Site has no /security, /compliance, or /trust page. No mention anywhere on yuda.me of secure SDLC practice, OWASP MASVS alignment, data protection posture, or IP/handover policy. Vendor due diligence checklists ask for these; buyers who can't find them default to assuming the vendor is not mature enough.

Desired outcome: A dedicated page (e.g., /security or /trust) that states Yudame's security practices and compliance posture concisely and credibly. Goal is not audit-grade exhaustiveness — it is answering a due-diligence checklist quickly. Every claim on the page must be true-today; aspirational items go on an internal roadmap, not the public page.

Definitions

Term	Definition	Reference
OWASP MASVS	OWASP Mobile Application Security Verification Standard — the industry checklist of security requirements mobile apps should meet.	mas.owasp.org/MASVS
Secure SDLC	Software Development Life Cycle practices that integrate security review, threat modeling, and dependency scanning throughout development rather than only at the end.	—
Vendor due diligence	Pre-contract review a buyer conducts on a vendor — covers security, legal, financial, and reference checks.	—
IP transfer	Source code, documentation, and operational knowledge handed to the client at project end; no vendor lock-in.	—

Prior Context

Related work in flight:

• Homepage reposition (separate issue) — will link to this page from the footer.
• ADB 2026 research brief (separate issue) — may surface specific compliance themes ADB prioritizes that this page should speak to.

Solution Sketch

Single page, concise. Sections along these lines:

• Our posture — one-paragraph statement of security philosophy
• Secure SDLC practices — specific practices Yudame actually follows (dependency scanning, code review gates, threat modeling at design stage, etc.)
• Mobile security — OWASP MASVS alignment statement — include only if we actually align
• Data protection — how Yudame handles client data, PII, secrets in flight
• IP transfer policy — source code, documentation, ops knowledge handed over to client; no hidden dependencies
• Contact — email or form for security-related questions

Only include claims that are true today. A short honest page beats a long aspirational one by a large margin for due-diligence credibility.

Open question for /do-plan: Which practices does Yudame actually do today vs. aspire to? Plan stage should include a quick internal audit (interview Tom / review actual repos and workflows) and only include true-today items on the public page. Aspirational items should be captured in a private roadmap document.

Recon Summary

Confirmed:

• No existing /security, /trust, or /compliance surface in current site or git history.
• Single-page stance is recent and deliberate; adding a second page is an editorial shift that should be acknowledged in the plan.

Revised:

• Scope is the public-facing page only. An internal security documentation effort (runbooks, playbooks) is not in scope.

Pre-requisites:

• Plan stage should audit Yudame's actual-today security practices before drafting copy. Shipping aspirational claims on a security page is a credibility liability.

Dropped:

• Formal audits, SOC 2 pursuit, or similar certification work — out of scope for this issue.

Acceptance Criteria

• New page exists at a stable URL (e.g., /security or /trust)
• Linked from the homepage footer
• Page covers at minimum: secure SDLC practices, data protection, IP transfer policy, security-contact path
• Every claim on the page is verified true-today (no aspirational language)
• Visual aesthetic consistent with homepage — same typography, spacing, color palette, no new design language
• Renders cleanly in npm run dev on desktop and mobile
• Build (npm run build) copies the new page into dist/ and the GitHub Pages deploy workflow publishes it

Downstream

This issue feeds into /do-plan, which will produce a plan document at docs/plans/{slug}.md. Constraints:

• All claims must be verified true-today during plan stage.
• Visual consistency with src/index.html (Inter font, yellow accent #f5d563, minimal layout).
• No external JS dependencies.

[tomcounsell]

Related issues in this ADB-visibility workstream:

• Research ADB 2026 digital priorities and produce positioning brief #5 — ADB 2026 research brief (may surface compliance themes to speak to)
• Reposition homepage copy for ADB / DMC / Pacific audience #6 — Homepage reposition (will link to this page from footer)