Build SynSec v0.2 multi-scanner repository security MVP

[cmahmud]

Work in progress toward a production-oriented, repository-first SynSec v0.2 release. This PR intentionally remains draft while major production roadmap items are unfinished.

Implemented in this branch

• Multi-scanner repository-security engine with normalized/versioned reports, evidence-aware baselines, conservative incremental scope, lifecycle/triage, remediation verification, opt-in AI review, defensive workflows, GitHub Actions publication, local dashboards, and hosted GitHub App foundations.
• Genuine PostgreSQL shared state for horizontally scaled GitHub App runtimes: atomic replay claims, exact-provenance idempotent queue insertion, installation/authorization state, fenced worker claims, compare-and-set lease renewal, terminal transitions, serialized migrations, restart/reconnect behavior, and cross-replica revocation. The canonical conformance matrix runs through independent PostgreSQL pools.
• Enforced OCI scanner execution using immutable digest-pinned images, read-only repository/root filesystems, separate writable tmpfs scratch, non-root execution, all capabilities dropped, no-new-privileges, bounded CPU/memory/PIDs, network=none, no host control socket mounts, and no explicit child credential environment. CI executes this boundary.
• Executable hosted intake and worker roles. Intake composes mounted memory-only credentials, PostgreSQL shared stores, bounded HTTP(S), reload, and webhook drain. The worker validates PostgreSQL conformance before sensitive activation, uses fenced leases and authorization rechecks, keeps acquisition/publication credentials in the host layer, and enforces OCI execution for the currently runner-injectable checkov, grype, and syft adapters. Hosted AI review remains disabled because it is a separate outbound disclosure boundary.
• Conservative repository intelligence with bounded JS/TS/Python/Go call graphs, local/import resolution, exact route-to-sink correlation, request-input/source evidence, immutable forwarding, narrowly defined helper-return evidence, and framework-aware composition for Express, Koa, FastAPI, Django, Flask Blueprints, NestJS, and Go/Gin.
• Gin request flow includes exact direct *gin.Context access and a separate bounded one-local forwarding layer. Koa has equivalent framework-specific directional layers for strict Koa router entrypoints: direct request access must occur on the exact sink line or same line as one direct resolved call, while one-local forwarding requires an exact const assignment, exactly one later occurrence, a bounded forward distance, and one unchanged sole-argument call. Koa request sources are limited to request.body, query, params, headers/get(), and cookies; ctx.body is rejected as response state. Generic Node routes, mutable/multi-use locals, aliases, destructuring, transforms, wider propagation, and deeper forwarding fail closed. Bare local execute/query lexical collisions are not upgraded into database flow without member-qualified database-style sink syntax. Cross-module Koa named handlers reuse the existing conservative repository-local import resolver while preserving Koa framework identity.
• Middleware/dependency/guard attachments remain separately labeled review-only structural evidence. Static route, source, call, sink, middleware, dependency, guard, import, or framework composition evidence is never presented as runtime reachability, attacker control, authorization success, exploitability, or proof that a framework registers a route in a deployment.
• GitHub App trust boundaries covering webhook verification/rotation, durable replay/idempotency, installation authorization synchronization, exact commit acquisition, lease fencing/heartbeat renewal, purpose-scoped installation tokens, fixed-host publication, bounded HTTP handling, retention, workspace ownership/reconciliation, and approval-bound remediation PR writes.
• GitHub App provisioning/credential operations with App Manifest provisioning/conversion, memory-only atomic credential generations, mounted fixed-filename credential sources, explicit secret-manager/service-manager boundaries, rolling-upgrade gates, webhook/worker drain, durable lease observation, maintenance/lifecycle, fail-closed recovery, and protected aggregate operator status.
• Authenticated hosted installation ownership and revocation-aware re-verification with a PostgreSQL first-tenant-wins fence, monotonic verification epochs, stale-result rejection, bounded-fresh authorization evidence, and bounded periodic sweep orchestration. These are prerequisites for hosted collaboration, not a complete collaboration model.
• Secret-free exact-keyed host profiles and machine-readable release-readiness checks. The strict pre-tag gate still blocks on unresolved reproducible dependency installation rather than fabricating a lockfile.

Security interpretation

Repository content, scanner output, webhook payloads, stored artifacts, backend errors, CLI input, and externally supplied metadata are untrusted and bounded. Static evidence, AI output, scanner absence, readiness declarations, provisioning output, mounted credential snapshots, ownership/re-verification state, scheduler completion, maintenance/lifecycle/recovery observations, operator status, host profiles, durable zero-lease observations, upgrade assessments, worker-host execution, OCI configuration, and release-readiness output do not by themselves establish runtime exposure, effective authorization, exploitability, future GitHub access, fleet-wide readiness, complete scanner coverage, deployment success, or absence of vulnerabilities.

The project remains defensive and repository-first. This PR does not add autonomous live-target exploitation, credential harvesting, secret exfiltration, persistence on targets, destructive target behavior, arbitrary outbound targeting, or silent scope expansion.

Still unfinished before production release

1. Repository intelligence: carefully bounded additional argument/return/control/data-flow shapes, broader framework route/middleware/dependency models where materially useful, sanitizer modeling only where defensible, and broader exact finding correlation without turning structural evidence into runtime or exploitability claims.
2. Hosted scanner execution and deployment: other scanners may join the hosted worker only after equivalent runner injection and adversarial offline/isolation coverage. Container/service-manager packaging and deployable production examples around the intake/worker roles remain unfinished.
3. GitHub App operations: provider-specific secret adapters only where justified, fuller disaster-recovery procedures for genuine destructive/state-loss scenarios, and deployment orchestration around the existing provisioning, ownership/re-verification, reload, drain, maintenance, recovery, lifecycle, and upgrade boundaries.
4. Authenticated hosted collaboration: only after tenant authorization, isolation, persistence, disclosure, and audit boundaries are designed and tested. The sanitized local-dashboard model must not be weakened to add web features.
5. Release engineering/operator UX: reproducible dependency installation and packaging, migration/version policy, broader observability, and upgrade/rollback deployment examples. The strict tag gate remains blocked because the repository still lacks a verified package-lock.json; CI therefore still uses npm install. Generate a lockfile only from a verified dependency graph, then move CI to npm ci.
6. Additional scanner integrations only when they materially improve coverage, incremental correctness, normalization, or production behavior.

Validation expectation

Changes are expected to pass build, typecheck, the full Node 20/24 test matrix, machine-readable release-readiness invariant assessment, real PostgreSQL shared-state/ownership/conformance coverage, and enforced OCI scanner-sandbox integration before the branch is treated as green. The PR should remain draft until the remaining major production roadmap items above are resolved.