# Adopting runward in a regulated organisation

For a TPRM, security or procurement team vetting runward-the-CLI as a dependency: what standard vendor due-diligence does not apply, and the supply-chain integrity that does.

## Who this page is for

> **This page answers a different question, for a different audience, than the [Compliance evidence](https://runward.dev/docs/en/compliance/evidence/) page.** It is for a **TPRM / security / procurement team** evaluating whether to adopt **runward-the-CLI** as a vendor or a dependency in your supply chain. It does *not* explain how runward produces compliance evidence for a system *you* build.
>
> **If you are producing evidence for your own delivered agentic system** (ISO/IEC 42001, NIST AI RMF, EU AI Act) — the readiness drafts, the OSCAL export, `runward compliance <regime>` — you want the **[Compliance evidence](https://runward.dev/docs/en/compliance/evidence/)** page instead. This one is only about vetting runward as a supplier.

The posture in one line: runward is a **local, open-source CLI**. It runs inside your repository, emits no data, hosts nothing, and makes no network call. So the object of a normal vendor review — a third party that *holds your data* — does not exist here. Hand this page to your reviewer. The reasoning is captured in [ADR-0031](../adr/ADR-0031-sovereign-engineering-evidence-for-regulated-environments.md).

## 1. Why most vendor due-diligence does not apply

Standard vendor due-diligence is built to assess a third party that sits **in your data flow** and processes or hosts your data. runward is not in the data flow: it runs on your infrastructure, in your repo, with no runtime, no endpoint, and no transmission. That makes the following controls **moot** — and it is worth writing "not applicable, and here is why" on the questionnaire rather than leaving them blank, because a form built for SaaS assumes a hosted service that does not exist here.

| Control usually demanded of a vendor | Why it is moot here |
|---|---|
| SOC 2 / ISO 27001 of a hosting provider | No host. runward runs in your repo, on your infrastructure. There is no service to audit. |
| DPA / GDPR art. 28 (processor agreement) | No third party in the data flow, so no processor relationship to govern. Your repo may contain personal data, but it stays with you under your existing controls. |
| Data residency / sovereign hosting | Nothing is hosted or transmitted. Your repo, your region. |
| Penetration test of the service | No service is exposed: no runtime, no endpoint to test. |
| Sub-processors list | None. |
| Encryption in transit / at rest (vendor side) | No vendor side. Your existing repo controls apply. |
| Vendor business-continuity / exit plan | MIT-licensed and forkable; no hosted dependency to lose. |

Pursuing a publisher SOC 2 was explicitly rejected as moot: there is no service to audit. For a no-data-flow tool, **artifact integrity and forkability** are the recognised open-source substitutes for those SaaS controls.

## 2. What DOES apply: supply-chain integrity and project health

The real object of review for a local open-source dependency is **supply-chain integrity** (can you trust the artifact you install) and **project health** (is the project maintained and governed). runward is strong on both.

### Supply-chain integrity

- **Provenance** — npm **OIDC Trusted Publishing** plus a **SLSA provenance** attestation. Verify with `npm audit signatures`.
- **SBOM** — a **CycloneDX SBOM**, attested (SLSA build-provenance) and attached to each GitHub Release.
- **Dependency pinning** — committed lockfile; every CI action pinned by commit **SHA**.
- **Reproducibility** — deterministic build; anyone can re-verify the published artifact.
- **CI hardening** — core tests run **network-isolated** (`unshare -n`): a structural zero-network guarantee, not a claim.
- **Continuous posture** — an **OpenSSF Scorecard** workflow.
- **No long-lived Actions secrets** — publishing uses OIDC trusted publishing, so there is no `NPM_TOKEN` or PAT to leak.

### Project health and governance

- **Coordinated disclosure** — `SECURITY.md` (private channel, response window).
- **Ownership and cadence** — `CODEOWNERS`, SemVer, `CHANGELOG.md`, `GOVERNANCE.md`.
- **Bus factor** — single maintainer, mitigated by **MIT (right to fork)** plus a reproducible build. For open-source, forkability is the recognised continuity answer, and it is stronger than a single-vendor SaaS you cannot rebuild.

This maps onto the load-bearing **OpenSSF OSPS Baseline** controls a regulated buyer looks for: signed provenance, SBOM, SHA-pinned actions, coordinated disclosure, review-by-default, no committed secrets, and a deterministic test suite.

## 3. Licence framing

- **Tooling — MIT.** Freely reusable, no copyleft, no viral obligation. The favourable case in a regulated review.
- **Doctrine / method — CC BY-ND 4.0.** You may **use and apply** it internally: since CC 4.0, a *private* adaptation that is not shared is permitted. What the ND clause forbids is **redistributing a modified version** of the canon. Internal use therefore creates no distributed derivative and raises no obligation; only re-publishing an altered doctrine would.

## 4. The honest limits, named not hidden

- **Not a compliance validator.** runward produces *audit-ready supporting evidence*; it does not confer compliance, certification, or a conformity assessment. Acceptance is always the auditor's call.
- **Not a runtime.** No runtime logs. EU AI Act art. 12 record-keeping and the post-market / declaration-of-conformity items stay the **operator's** to supply. runward feeds only the *design-time* technical documentation (art. 11 / Annex IV).
- **Point-in-time.** Evidence is derived from repository content, so rerun it in CI. `runward check --freeze` seals it by SHA-256; later drift reddens the gate until re-verified.
- **No SLA, no warranty.** MIT "AS IS", best-effort, single maintainer, with forkability as the continuity answer.

## 5. This posture is itself drift-guarded, and runward never wires itself

**Enforced in CI, not just asserted.** Every verifiable claim on this page is enforced by a **drift guard** in CI ([ADR-0031](../adr/ADR-0031-sovereign-engineering-evidence-for-regulated-environments.md)). If a control here stops being true — a workflow action un-pinned, a long-lived secret introduced, the SBOM or provenance step removed, the licence changed — the gate reddens **before** this document can silently go stale. The maintainer keeps the sheet; the gate keeps the maintainer honest.

**The authorization boundary.** runward never installs git hooks and never writes to `.git/` ([ADR-0012](../adr/ADR-0012-runward-never-installs-git-hooks.md)). The [CI adapters](https://runward.dev/docs/en/operating/wire-the-gate/) are inert samples the operator wires deliberately. "Agent-operable" means an agent can drive the CLI end-to-end, including performing the wiring on the operator's say-so, not that runward silently modifies your repository. That is a deliberate authorization choice, not a missing capability, and it is exactly what a regulated buyer wants from a tool it installs.

## See also

- [Compliance evidence for the system you deliver](https://runward.dev/docs/en/compliance/evidence/)
- [ADRs / decisions](https://runward.dev/docs/en/reference/adr/)
- [The boundary: runward never wires itself](https://runward.dev/docs/en/operating/from-an-agent/the-wiring-boundary/)
- [Evidence & integrity](https://runward.dev/docs/en/concepts/evidence/)