Skip to content

Make Cmdr enterprise-ready #118

Open

Description

@vdavid

Done items (54 so far, with their dated notes) are in this comment. This description lists only what's open.

Some hardening tasks that are better not public live in a private sister issue: vdavid/cmdr-reports#24. Cyber Essentials moved to #436 (Someday/maybe): where we already comply, for UK prospects; we certify only if a sale needs it.

Data leaving the EU

  • Replace Resend (US) for license and notification emails, for example with SMTP through mailcow or an EU provider
  • Lock Cloudflare D1 and R2 to the EU jurisdiction (today they're only placed in Eastern Europe)
  • Update downloads come from GitHub Releases (US): consider serving them from the EU (our own server, or R2 with the EU jurisdiction)
  • EU-specific changes (D1/R2 jurisdiction, Resend, update downloads) are on hold until we've thought through serving US customers too (decided 2026-10-05)
  • Then update the "Does data leave the EU?" answer on /trust and in the privacy policy

Later: stamps with a real issuing body

These come from the plan in the first comment, steps 5–7. Each one gets cheaper once the tasks above are done.

  • EU Cyber Resilience Act (CRA): the reporting duty for actively exploited vulnerabilities and severe incidents started on 2026-09-11. Set up the reporting path through ENISA's Single Reporting Platform now, and confirm Cmdr is in scope (a self-review, no lawyer). The technical file, EU declaration of conformity, and CE mark are due by 2027-12-11. (drafts: vdavid/cmdr-reports#45, private. 2026-10-08: David registered as Primary AR on the SRP; CERT-SE rejected the association on 2026-10-09 without a reason (likely: he's styrelsesuppleant, not a signatory). 2026-10-14: David emailed cert@cert.se with the board's signed fullmakt, asking for the reason and whether to re-request. 2026-10-15: CERT-SE said the reason was the gmail address (only company-domain accounts are accepted); David re-requested from a company-domain EU Login, and CERT-SE accepted it the same day: David is the verified Primary AR. A backup contact has an urgent@getcmdr.com alert path; the fullmakt is signed and filed with the company papers. The backup contact accepted the Secondary AR invite the same day, so the reporting path is set up with a backup. 2026-10-16: the scope self-review is done: Cmdr is in scope, in the default category (self-assessment, no notified body), and its backend services count as part of the product. Next: the 2027-12-11 conformity work (support period, technical file, declaration, CE mark), a walkthrough with the backup contact, and a yearly dry run every October. Kit in the vault, projects/Cmdr/business/2026-10-08 Cmdr CRA …)
  • On the v0.54.0 release (the first with the Keychain move, "Delete all Cmdr data", Say so in the app when an update fixes a security issue, and what to do #455–Let people turn the operation log off (no undo while it's off), for the CRA #458, and Settings files survive a crash mid-save, and Cmdr tells you when it had to recover a corrupt state file or couldn't confirm a copy is on disk #461): flip the CRA checklist points (2)(d), (2)(f), and (2)(l) to Met in the vault technical file, and Part II (8) too except its lapsed-license test, which waits for the feature lock. Then resubmit CSA STAR with caiqfill: GRC-08.1 is now Yes, and check whether LOG-05.1 and LOG-05.2 honestly flip with the new digest alerts.

Activity

  1. vdavid commented on Sep 22, 2026

    @vdavid
    OwnerAuthor

    Here is the advice of an agent that:

    • dug into this issue
    • read docs/security.md
    • read the privacy policy
    • checked which of the badges at a random company Littlebird (SOC 2, CCPA, GDPR, and HIPAA) actually have an issuing body.

    It's verbatim as the agent gave me:

    First, the reframe

    On that Little Bird page, exactly one of the four badges was issued by anyone: SOC 2. The GDPR, CCPA, and HIPAA ones are clip-art. There's no GDPR certification body, no CCPA registry, and no such thing as HIPAA-certified software. Anyone can paste those, and plenty of companies do. So the question isn't really "which stamps can I afford", it's "which stamps survive a reviewer clicking them", and on that axis a tiny solo shop can look better than a Series A startup, because the free-but-real ones are mostly about having your house in order.

    Free, with a real issuing body or public registry

    1. CE marking under the EU Cyber Resilience Act. This is the big one, and it's not optional. Cmdr is commercial software with a network connection sold by an EU company, so your AB is a "manufacturer" under the CRA. A file manager isn't in Annex III, so you're in the default class: self-assessment (Module A), technical documentation, an EU declaration of conformity, and you affix the CE mark yourself. Zero cost, real legal weight, and a CE mark on a trust page is a stamp a European enterprise reviewer recognizes instantly. Two dates: vulnerability and incident reporting obligations started 2026-09-11 (11 days ago, via the ENISA Single Reporting Platform), and full application is 2027-12-11. Worth confirming scope with an actual lawyer once, but on a plain reading you're in.
    2. CSA STAR Level 1. Free to submit, free to keep listed, publicly listed in the STAR Registry with a badge. You fill in the CAIQ v4 questionnaire against the Cloud Controls Matrix. This is the highest-leverage one for issue Make Cmdr enterprise-ready #118 specifically, because the deliverable is a completed vendor security questionnaire: when a reviewer sends you their 200-row spreadsheet, you send back a registry link. Caveat: it's cloud-service framed, so some controls map awkwardly to a desktop app. Your api-server, D1, R2, and dashboard make it defensible.
    3. GitHub artifact attestations. Free on public repos (yours is public), gets you SLSA Build Level 2 out of the box, Level 3 if the release build goes through a reusable workflow. Cryptographic proof the DMG came from that commit on that workflow. Pairs beautifully with the notarization story you already have.
    4. OpenChain ISO/IEC 5230 self-certification. Free online questionnaire, real ISO standard number, downloadable conformance badge. It's about open-source license compliance in your supply chain, which given cargo deny and Renovate you're most of the way to already. There's a sibling, ISO/IEC 18974 (security assurance), same free self-certification route.
    5. Apple notarization. You already have this and docs/security.md proves it end to end (empty entitlements, hardened runtime, source=Notarized Developer ID). You're just not displaying it. "Signed and notarized by Apple, ships zero entitlements" is a stronger claim than most of what's on that Little Bird page, and almost nobody makes it.
    6. OpenSSF Scorecard badge. Runs on any public repo, gives you a numeric score badge. Modest value, and BSL will cost you points on the license check. The related OpenSSF Best Practices badge is out entirely: it requires an OSI- or FSF-approved license, and BSL 1.1 is neither. Revisit in 2029 when the AGPL conversion kicks in.

    Free, self-declared, but expected (and where the real process wins are)

    These have no badge, but they're what a reviewer actually reads after clicking your badge:

    • SECURITY.md and /.well-known/security.txt (RFC 9116). You have neither. Both are 20 minutes of work, and automated vendor scanners check for them. Turn on GitHub private vulnerability reporting while you're there, which also feeds your CRA reporting duty.
    • An SBOM per release (CycloneDX from cargo-cyclonedx plus the npm side, attached to the GitHub release). Issue Make Cmdr enterprise-ready #118 doesn't mention it, but enterprise procurement asks, and the CRA mandates it from 2027.
    • A secure development lifecycle page. Issue Make Cmdr enterprise-ready #118 literally lists "Do you have an SDL?" as a question you need an answer to. You have a genuinely good answer already and it's scattered: the check runner, TDD, cargo deny, Renovate with a release-age window, hardened runtime with no entitlements, signed and notarized builds, a self-hosted updater, hostile-case test suites on every data-writing path. Writing that up honestly is a day's work and is more convincing than any badge.
    • GDPR, done properly rather than badged. Your privacy policy is already better than most: named subprocessors, a transfers section, retention enforced by a daily job. What's missing for enterprise is a signable DPA and a subprocessor change-notification commitment. Both are template work.
    • EU data residency, which is the Make Cmdr enterprise-ready #118 question "does any data leave the EU?" Today the honest answer is yes: PostHog, Cloudflare's global network, and GitHub for downloads. Three of those are fixable for free: R2 supports an eu jurisdiction restriction, D1 lets you pin the primary region to weur/eeur, and PostHog has an EU Cloud. That turns a squishy answer into "no, apart from your IP hitting GitHub when you download the DMG." Migration isn't free in effort, but it's free in money, and it's the single answer most likely to matter to a European IT department.
    • A VPAT / accessibility conformance report against WCAG 2.2 AA. Self-produced, free template from ITI, and you already build to AA+ contrast as a principle. Public sector and large enterprise procurement asks for this by name.

    Don't

    • HIPAA. Meaningless for a file manager with no BAA, and claiming it is a liability, not a stamp.
    • CCPA. You're almost certainly under every threshold. "We don't sell personal data" as a sentence is more honest and more useful than the badge.
    • Anything SOC 2-shaped until someone pays for an audit. A SOC 2 badge without a report is the one lie enterprise reviewers are trained to catch, and it poisons everything else on the page.
    • If you ever want one real third-party audit cheaply, UK Cyber Essentials is the floor at roughly £300 to £500 for a micro org. Not free, but two orders of magnitude under SOC 2.

    What I'd do, in order

    1. SECURITY.md, security.txt, GitHub private vulnerability reporting. An afternoon.
    2. A /trust page on getcmdr.com that pulls together what's already true: notarized, zero entitlements, self-hosted EU analytics, no cloud AI without your own key, subprocessor list, data-safety page. This is the thing a reviewer actually lands on, and the badges are decoration on it.
    3. The SDL write-up, which answers Make Cmdr enterprise-ready #118's hardest question and feeds everything below.
    4. SLSA attestations in the release workflow. Small diff, real badge.
    5. CSA STAR Level 1 submission. Biggest badge-per-hour, and it doubles as your questionnaire answer.
    6. CRA: figure out your reporting path now (it's already live), then the technical file and CE mark on a 2027 timeline.
    7. OpenChain 5230, once the SBOM and cargo deny story is written down anyway.

    One note on sequencing: 1 through 4 are all things you can do without deciding anything, and each one makes 5 and 6 cheaper, because STAR and the CRA technical file both ask you to point at exactly those artifacts.

    Want me to start on 1 and 2? I'd draft the /trust page as a v0 for you to review, since it's human-facing copy.

    Sources: CRA explained, CRA reporting obligations, CSA STAR, STAR registry submissions, GitHub artifact attestations, SLSA Build Level 3 with reusable workflows, OpenChain self-certification, OpenSSF Best Practices criteria

  2. vdavid commented on Oct 14, 2026

    @vdavid
    OwnerAuthor

    Done items, moved from the description on 2026-10-14 so it lists only what's open. Same structure as the description.

    Security review answers

    • A DPA ready to sign, plus a commitment to notify customers before changing subprocessors (drafts in the vault, projects/Cmdr/business/2026-10-05 …; finish them through the self-review above, the same way as the policy: open questions marked ❓ for David) 2026-10-15: done. Self-reviewed with every open question answered: a 48-hour breach notice, liability capped at the license price, the GitHub DPA gap stated openly, and a refund for any license holder who objects to a subprocessor change within their update year. Ready to sign on request (sales@getcmdr.com).
    • A continuity clause in the terms (what happens to customers if the company stops) (draft in the vault; finish it the same way) 2026-10-15: published as terms section 12 (17e95d2): licenses keep working without us, 90 days' notice, a final server-free release, a pro rata refund, takeover terms, and data deletion. /trust dropped it from "Not in place yet".
    • Self-review the safe-harbor paragraph in SECURITY.md (no lawyer, by choice, decided 2026-10-14). 2026-10-16: published (216c43e): research in good faith counts as authorized, with no legal action, no police report, and a confirmation of permission if someone else acts; it says what our permission can't cover; Discord is gone from the scope list.
    • Maybe: narrow the no-second-reviewer gap with an automated review pass per merge (An automated review pass on every merge, to narrow the no-second-reviewer gap #380). Decided 2026-10-16: not doing it. David reviews what agents do, agents peer-review each other through subagents, every flagged follow-up is opted into, and about 160 automated checks cover the codebase; /trust/development#review describes that.

    The first draft is on branch worktree-trust-page (not merged yet): SECURITY.md, a fixed security.txt, /trust, /trust/development (the SDL answer), release provenance and SBOMs, and privacy policy fixes. In dev, the pages show a ⚠️ callout on every open item below.

    • Review and merge the worktree-trust-page branch (merged; ships in v0.47.0)
    • Turn on GitHub private vulnerability reporting (also on mtp-rs and smb2), then mention it in SECURITY.md and on /trust
    • Decide on a PGP key for security reports: publish one, or keep "no PGP" (decided 2026-09-23: no PGP, by choice; GitHub private reporting covers sensitive details)
    • Decide whether to commit to publishing security advisories and CVEs (decided 2026-09-23: yes, for flaws exploitable without prior code on the Mac, or that expose credentials or user data; the rule is in SECURITY.md)
    • Pricing page: reword "Passes a security review" (pricing.astro, around line 173). Now "Ready for your security review", with a link to /trust.
    • features.astro says Cmdr "ships with a 3B language model", but it's downloaded on demand (the homepage too)
    • Add a 90-day expiry rule to the R2 bucket cmdr-error-reports, scoped to the error-reports/ folder only (the license backup lives in the same bucket). The privacy policy promises 90 days, and zips from 2026-04 still exist. (Live since 2026-10-05: expire-error-reports-90-days. 159 of 360 zips were past 90 days. setup-cf-infra.sh fixed too: it would have added an unscoped rule that deleted the license backups.)
    • Set PostHog's data retention and state it (recordings 30 days; events at least one year on the free plan, which has no shorter setting)
    • Check whether anything enforces Umami's retention ("typically two years"). (Checked 2026-10-05: nothing does. No cron, timer, or setting; data goes back to 2026-02-15, so the promise isn't broken yet.)
    • Enforce Umami's two-year retention: a monthly job on the Hetzner box deletes everything older than 23 months (infra hetzner/services/umami/, live 2026-10-06); the privacy policy and /trust say "deleted after two years"
    • Error reports: stop logging natural-language search queries (commands/search.rs, ai/translate.rs, the MCP ai_search handler now log lengths only)
    • Error reports: close the redactor gap for file names in free text. The search engine's debug line still logs every search's name pattern and scope (summarize_query / summarize_scope in search/engine.rs). Then simplify the privacy policy and /trust wording. (2026-10-05: the search query and scope, the select-by-description prompt, and raw AI replies no longer reach the log. Only file names in free text remain, and the pages now say exactly that.) (2026-10-06: the redactor now scrubs any absolute path and a file name repeated next to its path. One known gap remains and the pages name it: a name logged alone, with no path on its line.)
    • AI: decide whether folder name suggestions, select-by-description, and natural-language search should go through the same consent step as Ask Cmdr (decided: yes. One versioned "Allow cloud AI" consent now gates every cloud call, MCP ai_search included, enforced in the backend: 7b7f3cc; ships in v0.47.0)
    • Test a release build behind a TLS-inspecting proxy and with a PAC file, then update /trust (2026-10-06: docs/notes/proxy-and-tls-inspection-2026-10.md. Manual proxy, env-var proxy, and company root CAs work. Since then, a shared cmdr-http client honors PAC files, auto-discovery (WPAD), the bypass list, and NO_PROXY, and never proxies loopback; ships in the release after 0.50.0. Not supported: proxy sign-in beyond URL credentials, SOCKS)
    • After the next release:
      • Check the entitlements are empty (codesign -d --entitlements -) and bump verifiedAgainst in trust.ts (v0.47.0: empty; verifiedAgainst is 0.47.0)
      • Run gh attestation verify on the DMG and drop the "from the next release on" wording (v0.47.0: provenance verifies; wording dropped for provenance)
    • After the release after v0.47.0: verify an SBOM attestation (gh attestation verify … --predicate-type https://cyclonedx.org/bom) and drop "from the next release on" from the SBOM wording. v0.47.0's SBOM attestations failed on a missing serialNumber, fixed in release.yml (61e50e8f3). (v0.50.0 verifies; wording dropped. verifiedAgainst is 0.50.0.)
    • After the next release (the first through the new reusable workflow and release environment). (2026-10-08, v0.51.0: ci-gate and the CodeQL gate passed; provenance and SBOM verify with --signer-workflow …/release-pipeline.yml, so /trust claims SLSA Build Level 3; the signed, notarized, stapled .pkg and Cmdr_0.51.0.intoto.jsonl are attached; the eight repo-level signing secrets are deleted, only the release env holds them; /trust is verified against 0.51.0, 604ce45ff. Local update signing stays optional, in cmdr-reports#39.)
      • Confirm the ci-gate job passed on the real tag
      • Run gh attestation verify … --signer-workflow vdavid/cmdr/.github/workflows/release-pipeline.yml (steps in docs/guides/releasing.md), then move the /trust claim to SLSA Build Level 3
      • Delete the repo-level copies of the eight signing secrets (cmdr-reports#24)
      • Deploy the api-server first (done 2026-10-06; it also deploys on push now, with D1 migrations first)
      • Optionally switch update signing to the laptop (RELEASE_UPDATE_SIGNING=local; tracked privately in cmdr-reports#39)
      • Confirm the release attached the signed .pkg and Cmdr_<version>.intoto.jsonl (Scorecard Signed-Releases then reads 10), and that the CodeQL release gate passed
    • Test an MDM PPPC profile (Full Disk Access) with the code requirement published on /trust (the profile is published since 2026-10-07; testing needs a real MDM, since macOS refuses a hand-installed PPPC profile) (2026-10-14: done on a real MDM, a self-hosted Fleet on the NAS pushing both published profiles to the enrolled M1, macOS 27.0.1, Cmdr 0.52.0 from its .pkg. Managed preferences read back exactly; TCC granted Full Disk Access from the profile and Cmdr's probe flipped to granted. Gap line dropped from /trust, plan removed, recipe in managed_policy/DETAILS.md, 40e7515)
    • A threat model for the whole app (today it exists per area, in docs/security.md) (docs/threat-model.md, linked from /trust. New gaps it found are tracked privately in cmdr-reports#38, all but one fixed.)
    • Fuzzing for the parsers that take untrusted input: SMB, SFTP, WebDAV, and ADB protocols, archives, PDFs, and images (eight targets in fuzz/, pnpm check fuzz, plus a slow-checks CI job. They found and fixed three bugs. SMB fuzzing lives in smb2. Not covered yet: SFTP, MTP (mtp-rs has no targets), thumbnails.)
    • A daily dependency advisory scan that only reads Cargo.lock (advisories.yml; runs once the branch is on main)
    • Turn on Dependabot alerts, so Renovate's security-update PRs can trigger (also on mtp-rs and smb2)
    • Clear the Dependabot backlog (2026-10-06: 113 open alerts, 2 critical and 48 high, down to 1 high. Patched npm and Rust deps; dismissed 47 as tolerable risk with reasons: the pinned offline convert-clip-model pip deps, dev-only packages with no fix, and Linux-only glib. The last one, http-cache-semantics, gets its override once the fix is three days old)
    • CI health: make the release wait for green CI (scripts/release-ci-gate.sh, run by release.sh before tagging: a full run_all CI run on the exact commit must be green, 71e857c; first used for v0.47.0)
    • Enforce the release gate in release.yml too (a ci-gate job requires a green full run_all CI run on the tagged commit, or its parent for the chore(release) bump)
    • CI health: 192 of 416 runs on main failed in three months. Consider a macOS CI lane (2026-10-06: October is down to 6 of 40 red; docs/notes/ci-health-2026-10.md. Added the desktop-rust-macos lane, rustdoc in clippy-linux, and pre-push notices and size checks. Making the macOS job required: Make the desktop-rust-macos CI job required after two weeks of green runs (counting from its first push, 2026-10-XX) #368. Keeping main itself green: Decrease red CI runs on main #369, someday)
    • An offline license file for air-gapped commercial installs (today a license falls back to Personal after 30 days without reaching the server) (2026-10-05: perpetual licenses now verify offline forever and drop to Personal only on a server-signed revocation; dated keys expire by their signed date; the license email carries the full key, so an air-gapped Mac activates by pasting it. Fleet rollout of a key through MDM isn't covered yet.)
    • Deploy the api-server BEFORE the next app release: the app now trusts only nonce-signed /validate answers, and against the old server it keeps its cached status
    • Refunds of one-time purchases are invisible to /validate, so a refunded perpetual license stays active (2026-10-06: approved full refunds and chargebacks revoke via adjustment.* webhooks; David still needs to subscribe both Paddle destinations to adjustment.created and adjustment.updated)
    • Keep Cmdr's index out of Time Machine backups (2026-10-06: no setting; the drive index moved to ~/Library/Caches/…/drive-index/, migrating on first launch. Importance and media stay backed up)
    • The frontend SBOM includes dev dependencies, marked "excluded", because svelte and @sveltejs/kit are dev dependencies whose code ships in the app. Decide whether to move them or filter the SBOM. (Now built from the bundle itself with rollup-plugin-sbom: it lists exactly the 48 packages that ship.)
    • Maybe: reach SLSA Build Level 3 by moving the release build into a reusable workflow. The pages claim Level 2 today. (Done: release-pipeline.yml. The claim moves to Level 3 once the next release verifies, see above.)

    Data leaving the EU

    • Move all @getcmdr.com mail (including security@ and legal@) from the Gmail forward to the self-hosted mailcow. Required before the enterprise rollout: no Google dependency. DMARC reports go to Gmail too. (Done 2026-10-06: MX points to self-hosted mailcow (Helsinki), SPF mx -all, DMARC reports to dmarc@getcmdr.com; Cloudflare Email Routing is off. All addresses and the catch-all tested from outside. Left for David: remove the Gmail "Send mail as" entry and the SMTP2Go user david.getcmdr.)
    • Discord (US) gets report notifications with email addresses: move to an EU channel, or strip the emails (stripped, beta signups included; live once the api-server deploys)
    • Error reports and feedback become issues in a GitHub (US) repo: decide whether that's acceptable (decided 2026-10-05: acceptable for now, may move later)
    • smtp2go's DNS records still exist for getcmdr.com. Check whether anything still sends through it, then remove the records or add it to the subprocessor list. (Checked 2026-10-05: still in use. Mail from david@getcmdr.com went out through it on 2026-09-30. Nothing in the code sends through it.) Decided: SMTP2Go stays as mailcow's outbound relay (Hetzner blocks port 25), so add it to the subprocessor list with the mail cutover.
    • Check which region Cloudflare Analytics Engine keeps its data in (no region and no regional control; Cloudflare may store it in its core data centers globally; retention is three months)

    MDM deployment

    • A managed-preferences (configuration profile) setting IT can push to turn off usage stats and crash reports for every user. This matters most, because "on by default" is fine once IT can turn it off.
    • Managed-preferences settings for updates: turn off automatic updates, or pin a version (a version ceiling: the updater can't fetch older releases)
    • Managed-preferences settings for AI: turn off AI, turn off cloud AI, or allow only certain providers (by host)
    • After the release that ships it: test a real profile on a Mac (sudo recipe plus the published .mobileconfig, see docs/specs/mdm-managed-preferences-plan.md § Testing without an MDM), then wipe the plan (2026-10-14: done on a real MDM, a self-hosted Fleet on the NAS pushing both published profiles to the enrolled M1, macOS 27.0.1, Cmdr 0.52.0 from its .pkg. Managed preferences read back exactly; TCC granted Full Disk Access from the profile and Cmdr's probe flipped to granted. Gap line dropped from /trust, plan removed, recipe in managed_policy/DETAILS.md, 40e7515)
    • A .pkg installer (2026-10-08: the release pipeline builds, signs, notarizes, and staples Cmdr_<v>_universal.pkg from the next release on; Developer ID Installer certificate (G2, expires 2031-09-17) in the release environment; renewal steps in docs/guides/releasing.md. A pkg-installed app is root-owned, so the self-updater asks for an admin password; the deploy docs recommend DisableUpdates via MDM there)
    • A published PPPC profile for granting Full Disk Access through MDM (2026-10-07: /mdm/cmdr-full-disk-access.mobileconfig, plus the narrower folder permissions; a test pins it to the signing identity)
    • Document all of it on /trust, and remove the matching lines from "Not in place yet" (the managed-preferences part: a "Central management (MDM)" section, sample profile and plist under /mdm/. The .pkg and PPPC lines stay.)

    No Apple, no Google dependencies

    • No Apple or Google dependency beyond what macOS itself requires or what the user turns on (confirmed acceptable 2026-10-14)
      • Apple: Developer ID signing, notarization, Gatekeeper, and Apple's on-device frameworks (Vision for text recognition). These come with shipping on macOS.
      • Google: nothing by default. Gemini is an optional AI provider the user picks, and Google Drive links are built only when the user clicks one.
      • The website self-hosts its fonts and uses no Google Analytics.
    • Gmail: see the mailcow task above

    Later: stamps with a real issuing body

    • CSA STAR Level 1: fill in the CAIQ v4 questionnaire and submit it to the STAR Registry. Afterwards, a vendor questionnaire can be answered with a registry link. (drafts: vdavid/cmdr-reports#45, private. 2026-10-14: the prerequisites are in place. 2026-10-15: the policy is adopted, and the CAIQ stands at 226 Yes, 46 No, 11 N/A. The first submission bounced on a star.watch export bug; resubmitted with our own file.) 2026-10-16: listed at https://cloudsecurityalliance.org/star/registry/rymdskottkarra-ab, linked from /trust (028a219). It needs a yearly update, with the policy review.

    • OpenChain ISO/IEC 5230 (license compliance) and ISO/IEC 18974 (security assurance) self-certification (drafts: vdavid/cmdr-reports#45, private. 2026-10-14: every policy question answered, docs/open-source-policy.md published. 2026-10-15: the policy is adopted as v1.0 and the affirmation signed.) 2026-10-16: both checklists answered yes in full and submitted to OpenChain's Community of Conformance, one application per standard; /trust claims both (84b2961). Renewal every 18 months, next by 2028-04-15 (in the calendar).

    • An accessibility conformance report (VPAT) against WCAG 2.2 AA (2026-10-14: the INT edition, which covers WCAG 2.2, Section 508, and EN 301 549 in one report. Audit done: docs/notes/accessibility-audit-2026-10.md, gaps in Make the file list speak to VoiceOver: cursor, marked files, position, and file kind #437–Document Cmdr's accessibility features and how to get accessibility help #443 and Check that Cmdr's in-app menus speak under VoiceOver #267. The report page /trust/accessibility is merged on main (6be271d; live on the next push). Next: David's VoiceOver run fills the 12 pending rows; guide in the vault, projects/Cmdr/2026-10-14 Cmdr VoiceOver test guide.md) 2026-10-15: David's VoiceOver run passed V1–V12, so every pending row is now Supports (86f5aeb), and each partial row links its open issue (848cf21).

    • an OpenSSF Scorecard badge. The OpenSSF Best Practices badge needs an OSI-approved license, which BSL isn't. (2026-10-06: scorecard.yml publishes, README badge, read-only default tokens. 2026-10-08: score 7.8 after CodeQL (workflows, JS/TS, Rust; release-blocking on high/critical), Docker digest pins, Gradle wrapper validation, osv-scanner.toml ignores with reasons (0 advisories), and a main ruleset blocking force-push and deletion. ~8 after the next release adds the provenance file. Code-Review, CII, License, and Branch-Protection stay low by choice)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions