CRA security package: per-release SBOMs, 10.512-aligned threat model, disclosure policy

[w1ne]

What

The stack-supplier CRA conformance package, public half (design spec + plan committed in-repo under docs/superpowers/):

• SBOM per release — tools/generate_sbom.py (stdlib-only, 9 unit tests, ruff-clean) emits CycloneDX 1.6 + SPDX 2.3; release.yml attaches iolinki-<version>.cdx.json/.spdx.json to every tagged release (reproducible via SOURCE_DATE_EPOCH pinned to the release commit). New lightweight sbom-tools CI job runs the tests.
• Threat model — docs/security/THREAT_MODEL.md, STRIDE analysis aligned to IO-Link Security Design and Development Guideline 10.512 (D1.0.0-01) + Secure Deployment 10.502. Every stack claim carries a verified code/test anchor; protocol gaps (no crypto, no BLOB FW-update profile, physical protection at SL-C 1) are stated as integrator duties, not glossed.
• SECURITY.md — coordinated disclosure (ack ≤72h, triage ≤14d), supported-versions tied to the commercial stance, CRA-readiness statement (ENISA 24h/72h process).
• CRA overview — docs/security/CRA.md: manufacturer-stays-responsible framing, free vs commercial deliverables table. README gains a Security section.

The commercial half (compliance-statement + security-update-terms templates, both DRAFT — pending legal review) landed in the new private repo w1ne/iolinki-private.

Decisions taken as defaults (flag if you disagree)

1. Scope pass 1 = device stack only; master stack + udslib reuse the template.
2. Threat model is public (credibility play); compliance statement + update terms are commercial.
3. Support period default 5 years (CRA "at least five years").
4. Both SBOM formats shipped.
5. 10.512 is a draft under review until 2026-02-03 — mapping cites D1.0.0-01 and needs a re-check at final release.

Verification

• python3 tools/test_generate_sbom.py → 9/9 OK; ruff check clean on new files.
• Both SBOM formats dry-run + json.tool validated.
• Workflow YAML parse-checked; note pre-existing ruff F541 in tools/virtual_master/nucleo_master.py (untouched, not from this PR).
• All threat-model anchors re-verified against source at writing time.

Follow-ups

• Tag a release to exercise the SBOM release path end-to-end.
• Enable GitHub private vulnerability reporting in repo settings (Security tab) — SECURITY.md names it as the primary channel.
• Legal review of the two private-repo templates before first customer delivery.
• Same package for iolinki-master (once it has releases) and udslib.

🤖 Generated with Claude Code

[w1ne]

Note: zephyr-validation was already red on develop (ddcca4d) — 7db98d5 removed src/iolink_core.c without updating zephyr/CMakeLists.txt, and the job isn't branch-protection-required so the run still showed green. Fixed here (one line, ../src/iolink_core.c → ../src/device.c). Consider making zephyr-validation a required check so this class can't slip through again.