Mycorrhizal CRM

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Development happens as individual commits/PRs merged to main between tagged releases; the repo is not release-only.

Repository on GitHub, which uses git. git is distributed.

Each release has a tag marked with Semantic Versioning (vZ.Y.X) and commits also carry unique Git SHAs.

Every release is a Git tag; tagging is automated by .github/workflows/release.yml. https://github.com/DrewBrunning/mycorrhizal-crm/tags

https://github.com/DrewBrunning/mycorrhizal-crm/releases

Each tagged release publishes a GitHub Release with generated notes (created automatically by .github/workflows/docker-publish.yml on the release tag). Upgrade impact and breaking changes are covered by docs/upgrade-compatibility.md and docs/breaking-change-policy.md, and the supported-upgrade range is enforced in CI. (Optional improvement: add a one-paragraph human summary per release.)

The project is pre-1.0 and has had no publicly known run-time vulnerabilities (no CVE assigned against Mycorrhizal CRM's own code). This criterion applies only to the project's results, not dependencies, so there is nothing to enumerate.

https://github.com/DrewBrunning/mycorrhizal-crm/issues/new/choose — bug reports are submitted through GitHub Issues using the "Bug report" template (.github/ISSUE_TEMPLATE/bug_report.md), which asks for reproduction steps, expected vs. actual behavior, and the affected version/component. The issue tracker is public and is the project's single source of truth for the backlog; SECURITY.md directs suspected vulnerabilities to a private channel instead.

GitHub Issues is the issue tracker; it is the project's single source of truth for the backlog (per CLAUDE.md).

Bug reports are filed as GitHub Issues (public, actively triaged — the issue tracker is the project's working plan). Every issue opened to date has been triaged and responded to. External bug-report volume is currently low (pre-1.0, small user base); there have been no unacknowledged reports in the 2–12 month window.

Enhancement requests use the feature_request issue template and are triaged into the GitHub Issues backlog. All feature requests received have been responded to. (SHOULD — an unmet SHOULD with a note wouldn't block the badge, but this is cleanly met.)

https://github.com/DrewBrunning/mycorrhizal-crm/issues?q=is%3Aissue

https://github.com/DrewBrunning/mycorrhizal-crm/blob/main/SECURITY.md

SECURITY.md publishes the process: report privately via GitHub Security Advisories, what to include, a 5-business-day acknowledgement target, and coordinated-disclosure handling. Also links the operator incident-response runbook.

https://github.com/DrewBrunning/mycorrhizal-crm/security/advisories/new

Private reporting is via GitHub's private Security Advisory flow (HTTPS), as directed by SECURITY.md.

No vulnerability reports have been received via the private channel (GitHub Security Advisories, per SECURITY.md) — 0 advisories filed. The internal two-agent security assessment findings (issues #860 / #871) were each triaged and fixed within days (e.g. PR #886), well inside the 14-day target.

Backend: cd backend && go build ./.... Frontend: cd frontend && yarn build. Combined production image: Dockerfile (docker compose up -d --build). Makefile targets wrap common tasks. Source changes regenerate the artifacts.

make, the Go toolchain, yarn, and Docker — all standard.

Go, Node.js/yarn, and Docker/BuildKit are all FLOSS; no proprietary tool is required to build.

Multiple FLOSS test suites: Go go test ./... (backend), Vitest + Playwright (frontend), Android instrumented tests (androidTest), plus schemathesis API fuzzing, migration tests, chaos/fault-injection, and CardDAV reference-server E2E. How to run them is documented in CLAUDE.md, README-developer.md, and docs/development/testing.md, and wired into .github/workflows/ (unit-tests.yml, e2e-tests.yml, etc.).

Standard invocations: go test ./... (backend), npx vitest run / npx playwright test (frontend), ./gradlew connectedDebugAndroidTest (Android).

codecov/patch is a hard 100%-of-changed-lines gate on every PR (Go coverprofile, Vitest lcov, JaCoCo — issue #267). Coverage is complemented by Stryker mutation testing, Go native fuzz targets, schemathesis, and the E2E suites.

GitHub Actions runs the full test + analysis matrix on every push and PR to main, plus nightly. ~25 workflows under .github/workflows/.

Stated policy: new/changed code must ship with tests, enforced by the codecov/patch gate (issue #267) and the CLAUDE.md "hand-verify your tests — break the code, confirm the new test fails, restore" rule. docs/development/contributing.md: "Make your changes with tests."

Recent feature PRs each landed with their test suites — e.g. CAP-01 capacity testing (#781), PERF-02 core-operation benchmark suite (#778), INT-03/04 retry-safe outbound operations (#779). The patch-coverage gate makes a test-free feature PR fail CI.

Documented in docs/development/contributing.md ("changes with tests") and CLAUDE.md ("Hand-verify your tests"); enforced by the coverage gate described in docs/development/coverage.md.

Backend: gofmt -l, go vet ./..., and golangci-lint (security set: gosec + bodyclose) gate CI (unit-tests.yml). Frontend: TypeScript strict mode + tsc --noEmit, Biome (recommended preset), ESLint typed linting. Workflow linting: actionlint + shellcheck + zizmor.

These checks are required and block merge; gofmt/go vet/lint violations fail the build, so the tree is kept clean. Recent example: commit e1e75ed6 "chore: clear qs and x/crypto security scanner alerts".

TypeScript strict mode, semgrep --error, biome ci (fails on any lint/format issue), and the golangci-lint security set are all run at maximum strictness in CI.

The project has a written threat model (docs/security/threat-model.md) covering trust boundaries and deliberate trade-offs, an OWASP ASVS 4.0.3 L2 control checklist mapped to file:line (docs/security/asvs-l2.md) with a dated verification report (docs/security/asvs-l2-verification-report.md), and MASVS-L1 for Android. Fail-safe defaults (deny-by-default user_id scoping on every handler, sensitivity-filtered exports in the query), complete mediation (no IDOR holes — audited), least privilege, and economy of mechanism are explicitly applied.

A full security review (14 findings, all patched) is recorded in the repo. Countermeasures for the common error classes are in place and documented: parameterized SQL only (SQL injection), no os/exec (OS injection), templates from an embedded FS + React escaping (XSS), user_id scoping everywhere (missing authorization/IDOR), explicit field allowlists on updates (mass assignment), CSV formula-injection neutralization, and an SSRF guard enforced in the transport dialer. See docs/security/threat-model.md and docs/security/asvs-l2.md.

All crypto uses published, expert-reviewed primitives: bcrypt (password storage), AES-256-GCM (at-rest field encryption), HMAC-SHA-256 / JWT (sessions), TOTP RFC 6238 (2FA), P-256 ECDSA (VAPID web push), SHA-256 (token hashing). No custom crypto.

The project's purpose is not cryptography; it calls the Go standard library (crypto/*), golang.org/x/crypto/bcrypt, github.com/golang-jwt/jwt, and github.com/pquerna/otp. It does not reimplement primitives.

Every crypto-dependent feature is implemented with the FLOSS Go standard library and FLOSS modules; nothing requires a proprietary crypto implementation.

Defaults meet/exceed NIST 2030 minimums: AES-256, bcrypt, HMAC keys ≥256-bit, VAPID P-256 (EC 256 ≥ 224). There is no configuration option that weakens these below the minimum. See docs/security/asvs-l2.md.

Default security mechanisms do not depend on broken algorithms. Symmetric encryption is AES-256-GCM (authenticated); no ECB/unauthenticated-CTR, no MD5/SHA-1/DES/RC4 in any security mechanism.

No SHA-1 or weak modes in the project's own security mechanisms. The one SHA-1 use is the opt-in Have I Been Pwned range-query, where SHA-1 is mandated by the HIBP k-anonymity API protocol; it is off by default and documented in docs/security/asvs-l2.md / docs/security/threat-model.md.

TLS is terminated at the operator's reverse proxy per docs/security/deployment-baseline.md, which requires TLS 1.2+ with ECDHE (forward-secret) cipher suites. The application itself performs no long-term-key key-agreement.

Account passwords are stored with bcrypt (bcrypt.GenerateFromPassword, cost 10) — an iterated key-stretching hash with a per-hash salt. backend/services/user_service.go. Rationale for bcrypt cost 10 vs Argon2id is documented in docs/security/asvs-l2.md (P1).

All keys, tokens, nonces, 2FA secrets, recovery codes, OIDC state, and password-reset tokens use crypto/rand (see backend/services/credential_crypto.go, twofactor.go, oidc_service.go, api_token_controller.go, atrest/atrest.go). math/rand appears only in non-security retry/backoff jitter.

All delivery is over HTTPS: git clone https://…, curl -O https://raw.githubusercontent.com/… for compose files, and container images from ghcr.io over TLS. Published images are additionally Cosign-signed with SBOM + SLSA provenance (.github/workflows/docker-publish.yml).

No build or install step fetches a cryptographic hash over plain HTTP. Dependencies are pinned (go.sum, yarn.lock), GitHub Actions are pinned by commit SHA, and Docker base images by digest.

No known unpatched vulnerabilities of medium+ severity in the project's code. Dependency CVEs are gated continuously by govulncheck, Grype, Trivy, and Dependabot; alerts are cleared promptly (e.g. commit e1e75ed6).

Same tooling; there are no outstanding critical vulnerabilities, and the security review's 14 findings were all patched.

.gitignore + .gitleaks.toml + fail-closed .githooks/pre-commit + GitHub push protection + TruffleHog [osps_br_07_01]

Multiple FLOSS static analyzers run before every merge and release: CodeQL (Go + JavaScript/TypeScript, codeql.yml), golangci-lint security set incl. gosec (unit-tests.yml), Semgrep (sast.yml + custom trap rules), govulncheck, mobsfscan (Android), and hadolint (Dockerfile). Results upload as SARIF to GitHub code scanning.

CodeQL, gosec, mobsfscan, and Semgrep all carry security/vulnerability rule sets (injection, auth, crypto misuse, path traversal, SSRF, etc.).

Code-scanning alerts are triaged and fixed; the scanners are required checks, so a new medium+ finding blocks merge. No open medium+ static-analysis findings.

Runs on every push and pull request, plus a nightly scheduled scan.

Dynamic tools run against release candidates and on schedule: OWASP ZAP DAST (zap-dast.yml), Schemathesis API fuzzing (schemathesis.yml), Go native fuzz targets (.github/scripts/run-fuzz-targets.sh, nightly -fuzztime), and chaos/fault-injection tests. The automated test suites also run under the Go race detector.

The project produces no code in a memory-unsafe language. Backend is Go, frontend is TypeScript, Android is Kotlin — all memory-safe/GC languages.

CI runs go test with -race (data-race detector) and -covermode=atomic, and the chaos/fault-injection suite exercises failure assertions. These are enabled for testing, not production builds.

ZAP and schemathesis findings are triaged; no outstanding medium+ exploitable finding from dynamic analysis. (Choose N/A instead only if you consider no such findings have ever been produced.)