moose-inventory 1.0.9 → 2.1

data/docs/release/release-readiness.md

@@ -2,6 +2,10 @@
 
 This project now has a small release-readiness gate intended to catch the regressions found during the modernization and security-audit passes.
 
+Reusable QA, documentation-QA, release, security, accepted-risk, rollback, and post-release templates live in `docs/qa/qa-documentation-and-release-gates.md`.
+
+Routine package maintenance and AI-agent operation boundaries live in `docs/maintenance/package-maintenance-and-agent-boundaries.md`.
+
 ## Local gate
 
 Run:
@@ -13,10 +17,19 @@ Run:
 The gate currently runs:
 
 1. RSpec with coverage via the existing spec helper.
-2. `git diff --check` for whitespace/conflict-marker issues in the working tree.
-3. `scripts/ci/check_permissions.sh` to ensure only intentional tracked repository entrypoints are executable.
-4. `scripts/ci/check_security.sh` to query OSV for locked RubyGems dependency advisories.
-5. `scripts/ci/package_sanity.sh` to build the gem, inspect the packaged payload, and smoke-test the CLI version command.
+2. `scripts/ci/check_rubocop.sh` for targeted Ruby style/lint checks.
+3. `git diff --check` for whitespace/conflict-marker issues in the working tree.
+4. `scripts/ci/check_permissions.sh` to ensure only intentional tracked repository entrypoints are executable.
+5. `scripts/ci/check_generated_artifacts.sh` to ensure generated/local artifact paths remain ignored and untracked.
+6. `scripts/ci/check_security.sh` to query OSV, run `bundler-audit`, and run `osv-scanner` when available or required.
+7. `scripts/ci/check_secrets.sh` to run the dedicated `gitleaks` secret scan when available or required.
+8. `scripts/ci/package_sanity.sh` to build the gem, inspect the packaged payload, and smoke-test the CLI version command.
+
+For release evidence, prefer:
+
+```bash
+MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1 ./scripts/check.sh
+```
 
 ## CI gate
 
@@ -24,6 +37,26 @@ GitHub Actions workflow: `.github/workflows/ci.yml`.
 
 It installs native headers needed by the DB gems, runs the same `./scripts/check.sh` gate used locally, and tests the maintained Ruby version range through the GitHub Actions matrix.
 
+## Trusted publishing gate
+
+GitHub Actions workflow: `.github/workflows/release.yml`.
+
+The release workflow runs when a `v*` tag is pushed. It:
+
+1. Checks out the repository using `actions/checkout@v5`.
+2. Installs Ruby and native database build dependencies.
+3. Fails if the tag version does not match `Moose::Inventory::VERSION`.
+4. Runs the full local `./scripts/check.sh` gate.
+5. Publishes the gem with `rubygems/release-gem@v1` using RubyGems trusted publishing/OIDC.
+
+RubyGems has a trusted publisher configured for repository `RusDavies/moose-inventory`, workflow `release.yml`, and environment `release`, so the workflow can request a short-lived publish token when a real release tag is pushed.
+
+Current GitHub `release` environment protection evidence is recorded in `docs/release/release-environment-protection.md`. As of 2026-05-29, the environment requires review by `RusDavies`, has self-review prevention disabled, disables admin bypass, and has a custom deployment policy named `v*`. Self-review prevention is disabled because OpenClaw/automation pushes use Russ's GitHub account, and `RusDavies` is currently the only required reviewer. Because GitHub reports the custom deployment policy object as `type: branch`, verify tag-deployment behavior on the next real release and adjust the environment policy if needed.
+
+This path was verified with release `v2.0` / gem `2.0`: RubyGems trusted publishing succeeded and the published gem was installable afterward. The release workflow now disables `rubygems/release-gem`'s post-publish await step (`await-release: false`) because RubyGems full-index propagation lag produced false-negative workflow failures even after successful publishes.
+
+Package provenance hardening beyond trusted publishing is evaluated in `docs/release/package-provenance-hardening.md`. The current release-readiness gate does not require additional checksums, GitHub artifact attestations, detached signatures, RubyGems certificate signing, or SBOM publication unless a future consumer or policy requirement explicitly adds that work.
+
 ## Package sanity expectations
 
 `package_sanity.sh` validates that the built gem includes at least:

data/docs/security/accepted-risk-register.md

@@ -0,0 +1,84 @@
+# Moose Inventory Accepted-Risk Register
+
+## Approval status
+
+Status: **Approved register - no accepted risks currently approved here**
+
+Russ / Rusty Frink Desiato approved this register's structure and use as part of the Moose Inventory security/privacy process baseline on 2026-05-29. Approval reference: `GOV-SEC-001`.
+
+Russ / Rusty Frink Desiato separately approved this accepted-risk register as the maintained accepted-risk register baseline for Moose Inventory on 2026-05-29. Approval reference: `GOV-RISK-REG-001`.
+
+This register records security, privacy, release, and supply-chain risks that are intentionally accepted rather than fixed before a defined milestone. A proposed risk is not accepted until an approver records an explicit approval decision.
+
+Approved references:
+
+- `GOV-TAILOR-001`: Moose Inventory is approved as Class 4 with target profile Software Library / Package.
+- `GOV-PRODUCT-001`: `docs/product/product-brief.md` is approved as the product-framing baseline.
+- `GOV-REQ-001`: `docs/product/requirements-baseline.md` is approved as the requirements and acceptance criteria baseline.
+- `GOV-UX-001`: `docs/ux/cli-workflow-notes.md` is approved as the CLI UX/workflow baseline.
+- `GOV-ARCH-001`: `docs/architecture/architecture-and-trust-boundaries.md` is approved as the architecture and trust-boundary baseline.
+- `GOV-SEC-001`: this register's structure and use are approved as part of the security/privacy process baseline.
+- `GOV-RISK-REG-001`: this register is approved as the maintained accepted-risk register baseline.
+
+Scope limit: this register records accepted-risk decisions only. It does not approve a release, compliance claim, public advisory, RubyGems publishing, future architecture/security changes, or acceptance of any proposed/monitored risk listed below. Approval of the register baseline does not convert proposed or monitored risks into accepted risks.
+
+## Acceptance rules
+
+Each accepted risk must include:
+
+- risk ID;
+- decision and scope;
+- severity;
+- affected assets/workflows;
+- rationale for acceptance;
+- compensating controls;
+- owner;
+- review date or trigger;
+- approver and approval date;
+- related issue/commit/document evidence where applicable.
+
+Evidence is not approval. A finding listed under proposed or monitored risks remains unaccepted until explicitly approved.
+
+## Accepted risks
+
+_No accepted risks are currently recorded._
+
+## Proposed or monitored risks
+
+| ID | Status | Severity | Risk | Current controls | Required decision / next action |
+| --- | --- | --- | --- | --- | --- |
+| RISK-SEC-001 | Monitored, not accepted as permanent | Medium | GitHub secret scanning is unavailable/disabled in current repository evidence, so GitHub-native secret scanning cannot be relied on as a control. | Local/CI `gitleaks` gate, `MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1 ./scripts/check.sh`, docs warning against committing secrets. | Revisit if GitHub secret scanning becomes available. If releases rely on this limitation long-term, record an explicit accepted-risk decision or enable equivalent control. |
+| RISK-SEC-002 | Evaluated, not accepted as release blocker | Low | Additional signed provenance/artifact attestations beyond RubyGems trusted publishing are not a current requirement. | RubyGems trusted publishing/OIDC, package sanity check, release workflow gate, package provenance hardening evaluation. | Revisit if security-sensitive consumers, release policy, or supply-chain requirements justify checksums, GitHub artifact attestations, signatures, or SBOM publication. |
+| RISK-SEC-003 | Open process gap, not accepted | Medium | Public vulnerability intake is informal without a repo-local `SECURITY.md` or private advisory workflow documented for users. | GitHub issues for non-sensitive reports, maintainer/private coordination where available, security audit docs. | Decide whether to add public `SECURITY.md` as part of security/privacy baseline approval or maintenance runbook work. |
+| RISK-SEC-004 | Open UX gap, not accepted | Medium | Destructive CLI commands do not yet have a consistent explicit confirmation / `--yes` pattern. | Explicit command names, dry-run support, tests, UX implementation backlog. | Complete UX implementation backlog item before expanding destructive behavior. |
+| RISK-SEC-005 | Mitigated release-governance gap, monitor next release | Low | GitHub `release` environment protection rules were absent when first documented on 2026-05-29. They are now configured with required reviewer `RusDavies`, self-review prevention disabled, admin bypass disabled, and a custom `v*` deployment policy. Self-review prevention is disabled because OpenClaw/automation pushes use Russ's GitHub account, and `RusDavies` is currently the only required reviewer. GitHub reports the custom policy object as `type: branch`, so tag-deployment behavior still needs verification on the next real release. | Release workflow only runs on `v*` tags, verifies tag/version alignment, runs full security-required check gate, uses RubyGems trusted publishing/OIDC, and now requires environment review before the release job proceeds. | Verify next real `v*` tag release can deploy after approval. If the custom policy blocks tags, adjust the environment policy or document the GitHub limitation. |
+
+## Accepted-risk template
+
+```markdown
+### RISK-SEC-XXX: Short risk name
+
+- Status: Proposed | Accepted | Retired
+- Severity: Critical | High | Medium | Low
+- Affected assets/workflows:
+- Decision scope:
+- Risk statement:
+- Rationale for acceptance:
+- Compensating controls:
+- Owner:
+- Review trigger/date:
+- Approver:
+- Approval date:
+- Evidence:
+```
+
+## Review cadence
+
+Review this register:
+
+- before each material public release;
+- when `scripts/check.sh` or security tooling changes;
+- when a security audit finds a new issue;
+- when a dependency advisory affects the supported dependency set;
+- when release infrastructure, RubyGems trusted publishing, or GitHub environment protection changes;
+- when a proposed risk is accepted, retired, or no longer accurate.

data/docs/security/security-privacy-process.md

@@ -0,0 +1,287 @@
+# Moose Inventory Security and Privacy Process
+
+## Approval status
+
+Status: **Approved**
+
+Russ / Rusty Frink Desiato approved this document as the Moose Inventory security and privacy process baseline on 2026-05-29. Approval reference: `GOV-SEC-001`.
+
+This document captures the maintained security and privacy process baseline for Moose Inventory. It is prepared from the approved product, requirements, CLI UX, and architecture baselines, plus current security-audit evidence and verification scripts.
+
+Approved references:
+
+- `GOV-TAILOR-001`: Moose Inventory is approved as Class 4 with target profile Software Library / Package.
+- `GOV-PRODUCT-001`: `docs/product/product-brief.md` is approved as the product-framing baseline.
+- `GOV-REQ-001`: `docs/product/requirements-baseline.md` is approved as the requirements and acceptance criteria baseline.
+- `GOV-UX-001`: `docs/ux/cli-workflow-notes.md` is approved as the CLI UX/workflow baseline.
+- `GOV-ARCH-001`: `docs/architecture/architecture-and-trust-boundaries.md` is approved as the architecture and trust-boundary baseline.
+- `GOV-SEC-001`: this document is approved as the security and privacy process baseline.
+
+Scope limit: this document covers security and privacy process expectations for a Ruby CLI/RubyGem package. It is not release approval, accepted-risk approval, public/compliance-claim approval, RubyGems publishing approval, or approval to operate Moose Inventory as a hosted service. Approval of this baseline does not approve any proposed or monitored risk in the accepted-risk register.
+
+## Security posture summary
+
+Moose Inventory is a local/automation-run CLI and RubyGem. It is not a hosted service and does not provide authentication, multi-user authorization, network listeners, or a managed SaaS control plane.
+
+The main security responsibilities are:
+
+- avoid leaking inventory, environment, and credential data;
+- avoid unsafe mutation of inventory state;
+- preserve package and release integrity;
+- keep dependencies and CI/release tooling scanned;
+- give maintainers a clear vulnerability intake and patch process;
+- record accepted risks explicitly instead of smuggling them through vibes, the least trustworthy transport layer.
+
+## Assets and data classification
+
+| Asset / data | Classification | Location / flow | Handling expectation |
+| --- | --- | --- | --- |
+| Inventory host and group names | Internal / environment-sensitive | User database, CLI output, snapshot exports, Ansible integration | Treat as potentially sensitive infrastructure metadata. Avoid publishing real inventories in examples, issues, logs, or screenshots. |
+| Host/group variables | Internal to confidential depending on user content | User database, CLI output, snapshot exports, Ansible integration | Values may contain endpoints, usernames, tokens, or operational details. Users should not store secrets as inventory variables unless their environment explicitly protects them. |
+| Database configuration | Confidential when credentials are present | YAML config files and selected environment sections | Prefer `password_env`; discourage committed plaintext passwords. Doctor should flag plaintext DB password configuration. |
+| Environment variables containing DB passwords | Secret | User shell, CI environment, process environment | Do not log. Do not print in diagnostics. Rotate outside Moose Inventory if exposed. |
+| SQLite database file | Internal to confidential | User-selected local filesystem path | User controls filesystem permissions, backups, and deletion. Backup copies inherit sensitivity of source data. |
+| MySQL/MariaDB/PostgreSQL database state | Internal to confidential | User-managed database server | User controls database users, network access, server backup, restore, and encryption posture. |
+| Audit/change records | Internal / environment-sensitive | User database audit tables and CLI audit output | Preserve append-only intent. Treat as operational history; avoid leaking in public bug reports. |
+| Snapshot import/export files | Internal to confidential | Files passed to `import`/`export`, CI artifacts | Treat as inventory data. Review before sharing. Avoid storing secrets in exported snapshots. |
+| CI/release artifacts and built gem | Public once released | GitHub Actions, RubyGems, local `tmp/pkg` | Verify package sanity and release workflow integrity before publishing. |
+| Security-audit and release evidence | Internal to public depending on repo visibility | `docs/`, CI logs, release records | Avoid secrets. Make limitations explicit. Evidence is not approval by itself. |
+
+## Data flows
+
+### Local CLI mutation flow
+
+```text
+Human / automation caller
+        |
+        v
+moose-inventory CLI arguments/options
+        |
+        v
+config discovery + selected environment
+        |
+        v
+operation object validation
+        |
+        v
+transactional database write
+        |
+        v
+CLI output + audit/change record where applicable
+```
+
+Security expectations:
+
+- Validate arguments before mutation where practical.
+- Keep dry-run non-mutating.
+- Use transactions for write operations where practical.
+- Do not print configured database passwords or environment-variable values.
+- Keep destructive or high-risk changes explicit and reviewable.
+
+### Snapshot import/export flow
+
+```text
+inventory.yml / inventory.json
+        |
+        v
+parser + snapshot validator
+        |
+        v
+transactional import apply OR validation failure
+        |
+        v
+exported snapshot / CLI report / audit evidence
+```
+
+Security expectations:
+
+- Validate before write.
+- Treat snapshot files as potentially confidential.
+- Do not make import a destructive sync unless separately designed, documented, tested, and approved.
+- Future preview/diff behavior should remain non-mutating.
+
+### Release and dependency flow
+
+```text
+source + Gemfile.lock + workflows
+        |
+        v
+scripts/check.sh
+        |
+        +--> RSpec / coverage
+        +--> RuboCop
+        +--> git diff --check
+        +--> permissions check
+        +--> OSV / bundler-audit
+        +--> gitleaks
+        +--> package sanity
+        |
+        v
+reviewed tag + GitHub release workflow
+        |
+        v
+RubyGems trusted publishing / OIDC
+```
+
+Security expectations:
+
+- Release jobs must require the same security-tool coverage expected by CI.
+- A passing check is evidence, not release approval.
+- Trusted publishing is the current package provenance baseline.
+- Additional signed provenance or artifact attestations are future hardening, not a current blocker unless separately approved.
+
+## Threat and abuse-case model
+
+| ID | Threat / abuse case | Impact | Current controls | Follow-up posture |
+| --- | --- | --- | --- | --- |
+| T-001 | User commits plaintext DB passwords in config | Credential disclosure | README guidance, `password_env`, doctor finding for plaintext password config, local `gitleaks` gate | Keep plaintext password support for compatibility; prefer `password_env`; track secret-scanning limits in risk register. |
+| T-002 | Inventory snapshots or audit output are shared publicly | Infrastructure metadata disclosure | Documentation guidance, export is explicit, audit output is user-invoked | Treat snapshots/audit as sensitive; future docs should repeat sharing guidance near examples. |
+| T-003 | Wrong config/environment is selected | Accidental mutation of wrong inventory DB | Explicit `--config`, `--env`, config validation, dry-run support | Future destructive confirmation should show environment/config context. |
+| T-004 | Destructive commands remove intended inventory state without enough friction | Operational disruption | Explicit command names, dry-run coverage, backlog item for destructive confirmation | Implement confirmation/`--yes` behavior before expanding destructive workflows. |
+| T-005 | Malformed import file causes partial or inconsistent writes | Data corruption | Snapshot validation before apply, transactional import | Keep import validation coverage with schema changes. |
+| T-006 | Duplicate/conflicting DB records bypass application logic | Corrupt inventory behavior | Schema uniqueness/index migrations, duplicate cleanup/refusal | Keep migration tests and future-schema refusal. |
+| T-007 | CLI input reaches shell execution | Command injection | Application uses Ruby/Sequel operations, not shell execution for inventory mutations | Security reviews should re-check new integrations for shell invocation. |
+| T-008 | Dependency vulnerability ships in a release | User environment compromise | OSV query, `osv-scanner`, `bundler-audit`, release parity enforcement | Patch according to vulnerability policy below; accept residual risk only through risk register. |
+| T-009 | Secret scanner is unavailable in GitHub repository settings | Missed committed secrets | Local/CI `gitleaks` gate | Track as accepted/monitored residual risk until GitHub secret scanning is available/enabled. |
+| T-010 | Release workflow publishes unreviewed or tampered package | Supply-chain compromise | GitHub Actions release workflow, trusted publishing/OIDC, package sanity, tag/version checks | Document confirmed release environment protections after maintainers verify settings. |
+| T-011 | Database server backups/restores are assumed to be handled by Moose Inventory | Data loss or false assurance | Architecture says server-backed DB operations remain user-managed; `docs/maintenance/database-backup-restore-guidance.md` documents native-tool backup/restore boundaries for SQLite, MySQL/MariaDB, and PostgreSQL | Keep backup/restore guidance current when database lifecycle commands change. |
+| T-012 | AI-assisted maintenance performs external or irreversible actions without approval | Governance/security failure | Workspace process and approval register | Repo-local AI-agent boundaries remain a separate process item. |
+
+## Authentication and authorization model
+
+Moose Inventory does not authenticate users itself. It relies on the caller's local operating-system account, shell environment, filesystem permissions, and configured database credentials.
+
+Authorization boundaries:
+
+- CLI execution authority is inherited from the local user or automation account running the command.
+- SQLite access is controlled by filesystem permissions.
+- MySQL/MariaDB/PostgreSQL access is controlled by the configured database account and server policy.
+- GitHub/RubyGems release authority is controlled outside the gem by repository, workflow, environment, and trusted-publishing configuration.
+
+Security expectations:
+
+- Use least-privilege database accounts where practical.
+- Avoid sharing config files that contain credentials.
+- Keep release and package-publishing authority human-owned and separately approved.
+- Do not imply Moose Inventory provides RBAC or tenant isolation.
+
+## Secrets handling model
+
+Preferred posture:
+
+- Use `password_env` for DB passwords.
+- Store secrets in the caller's environment, shell secret manager, CI secret store, or database/platform secret mechanism.
+- Keep plaintext `password` only as a compatibility option.
+
+Rules:
+
+- Do not print DB passwords in normal output, errors, doctor reports, or audit records.
+- Do not add examples that contain real secrets, tokens, host inventories, or live infrastructure details.
+- Do not commit `.env`, real config files, live inventory exports, database files, or secret-containing logs.
+- If a secret is committed, rotate it outside Moose Inventory and record the incident/cleanup evidence.
+
+## Logging and audit expectations
+
+Moose Inventory has an append-only audit/change-history feature for inventory mutations. That audit log is product evidence and operational history, not a rollback system and not a tamper-proof security ledger.
+
+Expectations:
+
+- Mutating commands should record meaningful audit/change evidence where supported.
+- Dry-runs should not mutate inventory state or audit history.
+- Audit output may contain host/group names and variable names; treat it as environment-sensitive.
+- Audit records should not include database passwords or environment-variable secret values.
+- Any future richer audit export should document confidentiality and retention expectations.
+
+## Privacy posture
+
+Moose Inventory does not intentionally collect personal data, telemetry, analytics, or hosted-service user behavior.
+
+Privacy expectations:
+
+- No built-in telemetry without separate product approval.
+- No external network calls during normal inventory operations except database connections explicitly configured by the user.
+- Dependency/security checks in maintainer workflows may contact external advisory services such as OSV and Ruby advisory sources; this is release/maintenance evidence, not runtime telemetry.
+- User inventories may include personal data if users put it there. Treat exported snapshots, audit records, and DB backups according to the sensitivity of user-provided content.
+
+## Vulnerability intake and security patch policy
+
+### Intake channels
+
+Current maintained intake channels:
+
+- GitHub issues for non-sensitive bugs and security-hardening requests.
+- Direct maintainer contact or private coordination for sensitive vulnerability details when available.
+- Security audit findings recorded under `docs/security-audit-*.md`.
+
+Future improvement:
+
+- Add a `SECURITY.md` file if maintainers want a public vulnerability-reporting policy on GitHub.
+
+### Triage severity
+
+Use the highest applicable severity:
+
+- Critical: credible package compromise, credential disclosure in release tooling, arbitrary code execution reachable through normal CLI use, or destructive data corruption with no workaround.
+- High: dependency vulnerability reachable in supported use, unsafe secret exposure, release workflow bypass, or destructive mutation bug likely to affect real inventory.
+- Medium: validation bypass, denial-of-service condition, confusing security-sensitive UX, or hardening gap with plausible user impact.
+- Low: documentation clarity, defense-in-depth, non-reachable dependency advisory, or scanner/process improvement.
+
+### Patch targets
+
+Targets are guidance, not an SLA promise:
+
+- Critical: stop release activity, prepare fix or mitigation immediately, and require human approval before publishing.
+- High: prioritize before feature work and target the next patch release.
+- Medium: add to backlog with owner/evidence and fix in an upcoming maintenance slice.
+- Low: handle opportunistically or with related docs/process work.
+
+### Release and disclosure
+
+- Do not publish a release that knowingly ships an unresolved critical/high security issue unless a human approver records accepted risk.
+- Release notes should describe security fixes at an appropriate level without handing attackers a nicely gift-wrapped exploit manual.
+- If a published gem is compromised or materially unsafe, a human maintainer must decide whether to yank, deprecate, patch, or publish an advisory.
+
+## Security acceptance criteria
+
+Security-ready for a release candidate means:
+
+- `MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1 ./scripts/check.sh` passes or exceptions are explicitly recorded.
+- No known unresolved critical/high findings remain unless accepted through the risk register.
+- Dependency/advisory scans are current enough for the release decision.
+- Secret scan passes or any finding is triaged, cleaned, and rotated where needed.
+- Package sanity passes for the gem artifact.
+- Release docs and checklist identify any accepted risks, limitations, and non-goals.
+- Approval records distinguish evidence from human approval.
+
+## Accepted-risk register relationship
+
+Accepted risks live in `docs/security/accepted-risk-register.md`.
+
+Rules:
+
+- A risk entry may be proposed by an agent or maintainer, but acceptance requires explicit human approval.
+- Each accepted risk must include scope, reason, compensating controls, owner, review trigger/date, and approval reference.
+- Empty or pending risk tables are useful evidence; they do not mean all risk is approved.
+
+## Current known limitations and compensating controls
+
+| Limitation | Current posture | Compensating control / next action |
+| --- | --- | --- |
+| GitHub secret scanning is unavailable/disabled for this repository in current evidence | Not accepted as a permanent claim; tracked as residual posture | Local/CI `gitleaks` gate remains required. Revisit if GitHub secret scanning becomes available. |
+| MySQL/MariaDB/PostgreSQL backups/restores are user-managed | Architecture scope boundary | Expanded guidance lives in `docs/maintenance/database-backup-restore-guidance.md`; update it when database lifecycle commands change. |
+| Public vulnerability intake is informal | Draft process only | Consider adding `SECURITY.md` or GitHub private vulnerability reporting if maintainers want public intake clarity. |
+| Destructive CLI confirmation is not fully implemented | UX follow-up backlog | Implement explicit confirmation / `--yes` behavior before expanding destructive workflows. |
+| Additional package provenance is not required beyond trusted publishing | Architecture decision | Evaluate signed provenance/artifact attestations as future hardening if justified. |
+
+## Review cadence
+
+Review this document when any of the following changes:
+
+- supported database adapters or schema migration behavior;
+- import/export or audit data handling;
+- release workflow, trusted publishing, or security scanning tools;
+- vulnerability intake expectations;
+- public security/compliance claims;
+- a security incident, secret exposure, or accepted-risk decision.
+
+At minimum, revisit before each material public release.

data/docs/security-audit-2026-05-26-rerun.md

@@ -0,0 +1,75 @@
+# Security Audit Rerun — 2026-05-26
+
+Repository: `RusDavies/moose-inventory`  
+Local path: `/home/skippy/.openclaw/workspace/projects/moose-inventory`  
+Audited commit at start: `a07b5c89214a3cee66170217c5b38e9ad2ae093a`  
+Audit branch: `security-audit-2026-05-26-rerun`  
+Evidence store: `.openclaw-security-audit/audit.sqlite`, audit run `2`
+
+## Executive summary
+
+The rerun found no exploitable application vulnerabilities in the Ruby CLI/config/database code reviewed, and all deterministic dependency, advisory, package, and secret-scanning gates passed.
+
+One release-supply-chain hardening gap was identified and fixed during the audit: the release workflow ran `./scripts/check.sh` without installing or requiring the dedicated security tools, so a tag-based release could publish even if `gitleaks`, `osv-scanner`, or `bundler-audit` coverage was absent from that release job. CI already enforced those tools; release now does too.
+
+## Scope
+
+Reviewed security-relevant surfaces and changes since the prior audit:
+
+- GitHub Actions CI and release workflows.
+- Security-tool installation and enforcement scripts.
+- Ruby CLI entrypoints and Thor command surfaces.
+- YAML configuration loading.
+- SQLite/MySQL/PostgreSQL connection setup and password handling.
+- Recursive group deletion behavior touched by recent issue work.
+- Gem packaging/release path.
+
+## Deterministic results
+
+- Full local required-tool gate: passed.
+  - RSpec: 268 examples, 0 failures.
+  - Coverage: 96.52% line coverage.
+  - Custom OSV dependency check: 45 dependencies queried, 0 vulnerable.
+  - `bundler-audit`: no vulnerabilities found.
+  - `osv-scanner`: no issues found in `Gemfile.lock`.
+  - `gitleaks`: dedicated secret scan passed.
+  - Package sanity: built and inspected `tmp/pkg/moose-inventory.gem` successfully.
+- Semgrep Ruby registry scan: 62 tracked Ruby files scanned with 44 Ruby rules, 0 findings.
+- GitHub Dependabot open alerts: 0.
+- GitHub code scanning alerts: unavailable / no analysis found (`404`).
+- GitHub secret scanning alerts: unavailable because secret scanning is disabled for this repository.
+- Workflow YAML parse check: `ci.yml` and `release.yml` parsed successfully with Ruby Psych.
+- Current GitHub CI before audit branch: latest `master` CI run succeeded for Ruby 3.2, 3.3, and 3.4.
+
+## Finding fixed during audit
+
+### SEC-RERUN-2026-05-26-01 — Release workflow did not require dedicated security tools
+
+- Priority before fix: P2 medium, release supply-chain hardening.
+- Exposure: tag-triggered release workflow.
+- Affected file: `.github/workflows/release.yml`.
+- Evidence: CI installed `gitleaks`/`osv-scanner` and set `MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1`, but the release workflow only ran `./scripts/check.sh`. In local mode, `scripts/ci/check_security.sh` and `scripts/ci/check_secrets.sh` intentionally skip missing optional security tools unless `MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1` is set.
+- Impact: a release tag created from an unexpected commit or during a tooling/path issue could publish without the same dedicated SCA/secret-scan enforcement as CI.
+- Fix applied: release workflow now sets up Go with cache disabled, installs the pinned security CLIs via `scripts/ci/install_security_tools.sh`, runs native dependency installation with a 5-minute timeout, and runs `./scripts/check.sh` with `MOOSE_INVENTORY_REQUIRE_SECURITY_TOOLS=1`.
+- Verification: full local required-tool gate passed after the workflow change.
+- Residual risk after later verification: trusted publishing was proven on release tag `v2.0`, but the workflow still has a false-negative path where post-publish waiting can fail if the RubyGems full index lags even after a successful publish.
+
+## Reviewed areas with no actionable finding
+
+- YAML config loading uses `YAML.safe_load_file` with aliases disabled and no permitted classes/symbols.
+- SQLite database path handling creates parent directories with `FileUtils.mkdir_p`; this is local config-driven CLI behavior, not a remotely reachable path traversal surface.
+- MySQL/PostgreSQL password handling supports `password_env`; plaintext `password` remains for compatibility but README guidance discourages committing it.
+- CLI input reaches Sequel model operations rather than shell execution; no shell/eval sink was identified in application code.
+- Recent recursive group deletion is explicit opt-in and keeps host fallback behavior covered by regression tests.
+- GitHub Actions release job uses OIDC/trusted publishing and does not store a RubyGems API key in the workflow.
+
+## Limitations
+
+- This was a local/source and CI/release workflow audit, not an active test against live external databases or RubyGems publishing.
+- GitHub code scanning is not configured, so there were no CodeQL/code-scanning results to review.
+- GitHub secret scanning is disabled for the repository; local `gitleaks` coverage was used instead.
+- The release trusted-publishing path was later verified on `v2.0`; the remaining limitation is that workflow success/failure still depends on RubyGems full-index propagation timing.
+
+## Conclusion
+
+No open exploitable vulnerabilities remain from this rerun. The only identified security gap was release-pipeline parity with CI security tooling, and it was fixed in this audit branch.

data/docs/security-audit-2026-05-26.md

@@ -0,0 +1,63 @@
+# Security audit — 2026-05-26
+
+Scope: local static/security review of the `moose-inventory` Ruby CLI/gem at commit `8c3eaada5d70ef599961b8ca8b78e12ea4ce83c9` on branch `security-audit-2026-05-26`.
+
+## Executive summary
+
+No actionable security vulnerabilities were identified in this pass.
+
+The meaningful attack surface remains local CLI execution, configuration-file loading, database access through Sequel, package/release automation, and developer tooling. There is no HTTP server, RPC endpoint, webhook handler, queue consumer, file upload parser, shell-command execution path, or plugin system in this repository.
+
+The areas remediated in the prior 2026-05-21 audit remain in good shape: YAML config loading uses `YAML.safe_load_file`, DB credentials can be supplied through environment variables, OSV reports no known vulnerable locked RubyGems dependencies, CI/package sanity gates are present, and GitHub Dependabot has no open alerts.
+
+## Surfaces reviewed
+
+- CLI entrypoint: `bin/moose-inventory`
+- Global option parsing and config loading: `lib/moose_inventory/config/config.rb`
+- DB connection/schema/transaction code: `lib/moose_inventory/db/db.rb`
+- Sequel models and associations: `lib/moose_inventory/db/models.rb`
+- CLI command handlers under `lib/moose_inventory/cli/`
+- Formatter/output serialization: `lib/moose_inventory/cli/formatter.rb`
+- Packaging and release metadata: `moose-inventory.gemspec`, `Gemfile`, `Gemfile.lock`, `.github/workflows/ci.yml`, `.github/workflows/release.yml`
+- Helper scripts under `scripts/`
+- Test config/spec fixtures under `spec/`
+
+## Findings
+
+No P0/P1/P2/P3 actionable findings were identified.
+
+## Notable negative findings
+
+- Config deserialization uses `YAML.safe_load_file` with aliases disabled and no permitted classes/symbols.
+- No runtime shell execution sinks were identified.
+- Database access uses Sequel model/dataset/hash APIs for user-controlled names, groups, hosts, and variables; no raw SQL interpolation was identified in reviewed runtime paths.
+- MySQL/PostgreSQL passwords can be supplied via `password_env`, and README guidance prefers environment-backed passwords over plaintext config values.
+- No committed secrets were identified outside expected example/test placeholders.
+- GitHub Actions release publishing uses RubyGems trusted publishing/OIDC rather than a stored RubyGems API key.
+- Dependency advisory gate queried OSV for 41 locked RubyGems dependency records and reported zero known vulnerabilities.
+- GitHub Dependabot open-alert query returned zero open alerts.
+
+## Tooling evidence
+
+- Audit evidence store initialized at `.openclaw-security-audit/audit.sqlite` with `audit_run_id=1`.
+- Inventory: 187 files; Ruby manifests detected: `Gemfile`, `Gemfile.lock`, plus generated package-sanity manifests under `tmp/package-sanity`.
+- Symbol extractor scanned 156 files but did not extract Ruby symbols/surfaces with the current lightweight extractor.
+- Semgrep auto-config failed because metrics are disabled; reran explicit Ruby registry rules instead.
+- Semgrep: `semgrep --config p/ruby --json --metrics=off --exclude .openclaw-security-audit --exclude spec/reports --exclude tmp .` scanned 62 tracked Ruby files with 44 rules and returned 0 findings.
+- Dependency advisory gate: `./scripts/ci/check_security.sh` queried 41 RubyGems dependencies and returned 0 vulnerable dependencies.
+- Full local gate: `./scripts/check.sh` passed with 268 examples, 0 failures, 96.52% line coverage, OSV 0 vulnerabilities, and package sanity passed.
+- GitHub Dependabot: `gh api 'repos/RusDavies/moose-inventory/dependabot/alerts?state=open' --jq 'length'` returned `0`.
+- GitHub code-scanning alerts could not be queried because no code-scanning analysis exists for this repository; GitHub returned `404 no analysis found`.
+
+## Tooling limitations
+
+- `osv-scanner`, `bundler-audit`/`bundle-audit`, `gitleaks`, `trufflehog`, `brakeman`, `flog`, and `reek` were not installed in this environment.
+- `bundle exec rubocop` could not run because RuboCop is not part of the bundle. This is not a security gate failure, but it limits style/static-quality coverage.
+- Secret scanning was limited to tracked-file grep patterns because dedicated secret scanners were unavailable.
+- The audit did not perform active exploitation against external systems or live database servers.
+
+## Residual risks / recommendations
+
+- Consider adding a dedicated secret scanner such as `gitleaks` or `trufflehog` to local/CI security tooling if this project will accept outside contributions.
+- Consider adding `bundler-audit` or `osv-scanner` as an optional developer tool if broader advisory coverage is desired beyond the existing custom OSV gate.
+- Keep generated coverage and package-sanity artifacts excluded from security scans; they are noisy and not part of the runtime gem surface.