This page exists so that a security, vendor-risk, or audit reviewer can answer standard due-diligence questions without emailing anyone. Every claim links to the artefact that proves it. Where no formal certification exists, the wording is "supports assessment against" — never "compliant with".
01. Security#
- Zero-trust XML processing — all parsing routes through
defusedxml(XXE and entity-expansion defence); nolxmlin the dependency tree; path-traversal validation on file inputs; non-root containers. Full detail with code-level references: Architecture & security. - Responsible disclosure — private vulnerability reporting via GitHub Security; machine-readable policy at /security.txt. Reports are acknowledged and credited.
- Static analysis in CI — CodeQL, Bandit, and pip-audit run on every change to the core.
02. Software supply chain#
- Independently scored — OpenSSF Scorecard runs weekly and on every push; the score is published by the OpenSSF, not self-asserted.
- SBOM — a CycloneDX software bill of materials is generated for core release builds (this site's own SBOM is also published).
- Provenance — a SLSA Build L3 attestation workflow is armed on the release pipeline; signed
*.intoto.jsonlattestations attach to releases published from v0.0.57 onward, verifiable withslsa-verifier. - Pinned CI — every GitHub Action in the build pipeline is pinned to a full commit SHA; workflow tokens follow least privilege.
- Kill switch — third-party plugin discovery can be disabled outright (
PAIN001_DISABLE_PLUGINS=1), and every discovered plugin is auditable before first use (pain001 plugins list).
03. Data and privacy#
- Product data flows — every component (CLI, library, REST service, MCP server, LSP server) executes on your infrastructure. There is no telemetry, no SaaS callback, no network dependency for generation or validation. Privacy position.
- Website — no cookies, no analytics scripts, no third-party requests beyond one logo CDN. The browser demo reads files locally via the FileReader API; the "Verify it yourself" panel on that page shows how to falsify this with DevTools open.
- Demo boundary — the demo's WASM validation engine is served from this origin and cached by a service worker; after first load the demo works offline, which is the strongest proof no data leaves the machine.
04. Accessibility#
WCAG 2.2 AAA as a build gate: the generator's WCAG audit plus independent pa11y scans at the AAA standard, both themes, enforced in CI — with a manual keyboard pass per release and honest limitations stated. Full method and known limits: Accessibility statement. Independent assistive-technology testing is the named next step; the procurement scope for that audit is published in the repository.
05. Governance and continuity#
Who maintains Pain001, how decisions are made, how the project is funded, and what mitigates single-maintainer risk — stated plainly, including the parts that are genuinely limitations: Governance & continuity.
06. Releases and support#
Versioning scheme, what "supported" means pre-1.0, security-fix policy, signing and provenance, and rollback guidance: Release & support policy.
07. Compliance mappings#
No certification is claimed. The controls above support assessment against:
| Framework | Relevant Pain001 controls |
|---|---|
| NIST SSDF (SP 800-218) | Protected build pipeline, SHA-pinned dependencies, static analysis, vulnerability response process, SBOM |
| SLSA | Build L3 provenance workflow on releases; source on GitHub with signed commits |
| OWASP (XML security) | defusedxml everywhere, no DTD/entity resolution, input path validation |
| WCAG 2.2 | AAA-targeted, gate-enforced, statement published per page scope |
| Bank third-party-risk questionnaires | This page, plus the linked artefacts, answers the standard data-locality, supply-chain, and continuity sections |
08. Contact#
Security: private disclosure · General: contact page · Corrections to anything on this site: open an issue — see the corrections policy.