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.
- OpenSSF Best Practices badge: the core repository holds the passing badge (100% of the criteria), covering documented contribution and vulnerability-reporting processes, enforced test coverage, static and dynamic analysis, and signed release delivery.
- SBOM: a CycloneDX software bill of materials is generated for core release builds (this site's own SBOM is also published).
- Provenance: SLSA Build L3 attestations are generated in the release pipeline itself; v0.0.57 onward carries a Sigstore-signed
multiple.intoto.jsonlon the GitHub release, verifiable withslsa-verifieragainst the published wheel and sdist digests. - Per-release artefacts: every core release on GitHub Releases carries its wheel, its SLSA provenance (
multiple.intoto.jsonl) and its SBOM; verify a wheel withslsa-verifier verify-artifact pain001-<version>-py3-none-any.whl --provenance-path multiple.intoto.jsonl --source-uri github.com/sebastienrousseau/pain001 --source-tag v<version>. The five packages share one version number; the governance page lists the current one. - 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 and no identifiers: every asset is served from this origin, and every script is served from this origin, and the one third-party request is the Cloudflare Web Analytics beacon's cookieless page-view count, which records without an IP address, fingerprint or identifier (see the privacy page). The demo page carries no beacon at all. 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 browser demo runs the pain001 library itself inside a Python runtime compiled to WebAssembly, served from this origin and cached by a service worker: records, generated XML and verdicts never leave the page, and after first load the demo works offline, which is the strongest proof no data leaves your machine.
04. Accessibility#
WCAG 2.2 AAA as a build gate: the generator's WCAG audit plus an axe scan of every page 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 and 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).