ReaperCI Documentation

ReaperCI documentation

Independent security review packet

This packet defines the minimum scope and evidence for the independent review that blocks managed GA. It is not a self-attestation or certification. The reviewer must test the released source and production architecture, record findings independently, and verify closure of every critical and high issue.

Review baseline

  • Core source: the exact signed release tag under review.
  • Managed source: the matching private reaperci-cloud release tag supplied to the reviewer under NDA.
  • Deployment: isolated rootless BuildKit tenant stacks, dedicated managed compute, outbound mTLS server connectors, production object storage, and the reviewed edge configuration.
  • Supported runtime: Linux amd64/arm64, Docker/Compose, native or connected Git.
  • Excluded claims: Kubernetes, Windows production runners, arbitrary managed shell, issues/PR review, multi-region HA, and formal compliance certification.

Record commit and image digests, tool versions, dates, reviewer identity, and test environment before testing. Do not review an uncommitted worktree or a mutable image tag.

Required technical scope

Boundary Required attacks and evidence Product evidence starting points
Authentication and sessions password/TOTP recovery, invitation replay, OIDC state/nonce/PKCE, expiry, revocation, role changes internal/auth, internal/api/teams_test.go, internal/api/oidc_test.go
Agent authorization scope escalation, protected approval bypass, identity attribution, token rotation internal/api/teams_test.go, internal/api/environments_test.go, cmd/reaperci
Secrets database/backup disclosure, context swapping, log/artifact masking, environment leakage internal/secretstore, internal/ci/service_test.go, internal/deploy/service_test.go
Native and provider Git malicious refs/paths, webhook forgery/replay, clone URL abuse, status confusion, import boundaries internal/githost, internal/providers, internal/api/providers_test.go
Build execution repository-controlled command injection, BuildKit entitlement abuse, platform/resource enforcement, cache/artifact traversal internal/ci, internal/remotebuild, cmd/reaperci-connector
Deployment safety approval race, mutable rollback, cross-repository takeover, Compose quoting, secret exposure, health manipulation internal/deploy, internal/api/deployments_test.go
Connector enrollment replay, certificate theft/rotation/revocation, command substitution, capability escalation, offline recovery internal/agentconnector, internal/remote, cmd/reaperci-connector
API and browser CSRF, CORS/origin confusion, body/rate limits, unsafe paths, SSE scope leakage, error disclosure internal/api/security_test.go, internal/api/events_test.go, web/e2e
Managed isolation cross-tenant network/volume/key access, Docker socket exposure, rootless escape assumptions, quota bypass private Cloud provisioner, managed-policy tests, generated bundle review
Billing and lifecycle Stripe replay/state confusion, unpaid hosted work, backup/restore tampering, deletion/purge escape private Cloud billing, lifecycle, backup-storage, and purge tests
Supply chain workflow permissions, tag immutability, dependency compromise, SBOM/provenance/signature verification .github/workflows, docs/release-verification.md, signed RC assets
Availability queue/log/SSE load, disk full, worker/BuildKit/connector restart, registry loss, certificate expiry cmd/reaperci-loadtest, failure-injection drill records

Reproduction baseline

go test ./...
go vet ./...
go run golang.org/x/vuln/cmd/govulncheck@v1.3.0 ./...
corepack enable
pnpm --dir web install --frozen-lockfile
pnpm --dir web check
pnpm --dir web test -- --run
go run ./cmd/reaperci-loadtest
bash scripts/validate-marketing.sh

The reviewer should add independent tooling and manual tests. Passing repository tests does not close an attack that the tests do not cover.

Required deliverables

  1. Executive summary with scope, dates, versions, limitations, and overall risk.
  2. One finding record per issue using the finding template, including exploit evidence and a stable severity rationale.
  3. Architecture and trust-boundary review, including dedicated-host and rootless BuildKit assumptions.
  4. Retest record for every fixed critical/high finding and every disputed issue.
  5. Residual-risk list with owner, compensating control, and expiry date.
  6. Written confirmation that no known critical/high issue remains open at GA.

Reports belong in a restricted evidence store, not the public repository. A sanitized review summary may be published only with reviewer approval.

Release decision

Any confirmed critical/high issue blocks managed onboarding and paid GA. A lower severity exception requires a named owner, exploitability analysis, compensating control, target release, and expiry. “Accepted indefinitely” is not a valid exception. Re-run affected automated and live drills after remediation, then have the independent reviewer verify the fix.