Security + supply-chain review remediation (H11, M2–M5, M22–M26, L1–L4, L23) - #64

The only strength gate on the master key was length: a memorable passphrase was
accepted as long as it was >= 32 bytes, and the field key is then derived with a
single fast HKDF expand. If an attacker obtained scrye.db (the exact DB-read
threat the field encryption defends against) and the operator had chosen a
low-entropy but long key, it could be brute-forced offline at HKDF speed.

Add an entropy floor at key load: the master key material must be valid base64
decoding to >= 32 bytes — the documented `openssl rand -base64 48` form. Raw
passphrase material (anything not valid base64) is rejected with an actionable
error instead of silently accepted via the UTF-8 fallback. A temporary
boot-and-rotate escape hatch, SCRYE_ALLOW_WEAK_MASTER_KEY, lets an existing
passphrase-keyed deployment start long enough to rotate; it logs a warning on
every load so it can't quietly become permanent.

This is input validation only. Key derivation and the on-disk token format are
unchanged, so every existing encrypted value still decrypts (regression test
added). README security model documents the requirement and the escape hatch.

The notification transports (webhook/Discord/Matrix/SMTP), the registry
connectivity probe, and the Docker socket-proxy client all took an
admin-supplied URL/host and connected with no destination check, so they could
be pointed at the cloud metadata endpoint (169.254.169.254), loopback, or an
internal service — an SSRF surface, admin-gated but unguarded.

Add core/egress.py: resolve the target host and refuse loopback, link-local
(including cloud metadata), multicast, unspecified, and reserved addresses
always, and RFC-1918/ULA/CGNAT private addresses unless the operator opts in
with SCRYE_ALLOW_INTERNAL_EGRESS (self-hosted deployments legitimately run an
internal SMTP relay or private registry). The Docker proxy targets an internal
sidecar by design, so it allows private addresses but still refuses
loopback/metadata. The registry bearer-token realm — attacker-influenced, from
the probed registry's own header — is screened too.

Resolution here is best-effort (httpx re-resolves on connect), which is
appropriate for an admin-gated, CSRF-protected surface. Settings gains
allow_internal_egress (off by default); README security model and the env-var
table document it.

… token (SEC-4)

The key/value redaction filter's unquoted-value branch stopped at the first
whitespace, comma, semicolon, or ampersand, so an unquoted secret containing any
of those — an SMTP password, a backup passphrase, a multi-word token — was only
prefix-masked and its tail leaked to the log (`password=p@ss w0rd here` left
`w0rd here`; `api_key=abc,def` left `,def`).

Make the unquoted match tempered-greedy: consume to end of line unless it first
reaches the start of another `key=`/`key:` pair, so a spaced/comma-bearing secret
is redacted whole while a following structured field (`region=us`) is still
preserved. The value is anchored to a non-space first character so the engine
can't backtrack the key's trailing space and start the value on it, slipping past
the Bearer/Basic guard. Redaction stays bounded to a single log line.

Over-redacting a trailing free-text phrase is the accepted trade-off for never
leaking secret bytes; two tests that asserted trailing context survived a
single-token secret are updated, and a spaced-secret regression test is added.

…gest (SC-6)

The frontend builder pinned a node:22-bookworm-slim digest that upstream had
superseded by ~a Debian patch cycle, so the build ran on an older OS snapshot.
Bump to the current manifest-list digest
(sha256:53ada149d435c38b14476cb57e4a7da73c15595aba79bd6971b547ceb6d018bf). Tag +
digest are kept together (human-readable and immutable). Builder stage only —
nothing from it ships to the runtime image except the compiled dist/.

The read-only Docker socket proxy — the single most security-sensitive sidecar,
the only container mounting docker.sock — was pinned to 0.3.0 (~15 months old),
running a year-plus-old HAProxy base. Bump to v0.4.2 (current stable; upstream
now prefixes tags with `v`) with its resolved manifest digest.

The env-var interface (IMAGES/CONTAINERS/INFO/POST) is unchanged across the
0.3 -> 0.4 line and the app only calls GET /images/json (gated by IMAGES=1), so
no client change is needed. The existing hardened-boot NOTE (read-only FS + /run
tmpfs + cap_drop:ALL; add SETUID/SETGID only if privilege-drop fails) still
applies and should be re-verified on a Docker-Hub-reachable host — image pull/boot
could not be exercised in the egress-restricted environment where this was
prepared.

A future migration to wollomatic/socket-proxy is tracked separately (#63).

Published images carried no provenance or SBOM attestation, so a consumer of
ghcr.io/tyler-rich/scrye couldn't verify that :latest/:<version>/:dev was built
by this repo's workflow from a given commit — a credibility gap for a tool whose
product is SBOM/vulnerability transparency.

The shared build-image action gains provenance/sbom inputs (default off, so the
CI build-only check is unaffected) and exposes the pushed image digest. The two
publish workflows turn on BuildKit SLSA provenance (mode=max) + SPDX SBOM on the
image manifest, and add a GitHub-signed build-provenance attestation via
actions/attest-build-provenance (SHA-pinned), verifiable with
`gh attestation verify oci://ghcr.io/tyler-rich/scrye:<tag>`. The id-token/
attestations scopes are granted at job level only, on the publish workflows.
CONTRIBUTING documents verification.

The dogfood gate runs only on PRs/pushes, so a CVE disclosed after an image was
published went unnoticed until the next unrelated build — during any quiet
period the shipped :latest/:dev could carry a fixable HIGH/CRITICAL with nobody
looking.

Add rescan.yml: weekly (and on demand) it pulls each published image and re-runs
the SAME Trivy + Grype gate the dogfood self-scan uses (fixable HIGH/CRITICAL,
bundled trivy/grype/syft binaries excluded, same triage ignorefiles). It doesn't
gate a merge — on a finding it opens, or comments on, a per-tag tracking issue
(deduped by title). A leg whose tag isn't published yet skips cleanly. This also
automates the bundled-binary CVE treadmill check the archive did by hand. README
documents it.

… (SC-8)

Each scanner tarball was verified against a checksums.txt downloaded from the
same GitHub release — which defeats transit corruption but not a compromised
release, since an attacker who can replace the tarball can regenerate the
matching checksum beside it.

Add keyless cosign verification of each publisher's signature over its
checksums.txt before the existing sha256sum check: cosign is pinned by digest
from the official Sigstore ko image (COPY --from), and each verify-blob pins the
GitHub Actions OIDC issuer and an identity regexp scoped to the upstream repo's
release workflow (aquasecurity/trivy, anchore/grype, anchore/syft). This raises
the guarantee from "matches what GitHub serves" to "signed by the upstream
project's own release pipeline" (Fulcio identity + Rekor inclusion). The
download → cosign-verify → sha256sum → extract order and the concurrent-subshell
build-performance shape are preserved; a bad signature fails the build.

Note: the upstream signature asset names and certificate identities could not be
exercised in the egress-restricted prep environment (the release CDN is blocked);
the CI image-build job validates them end-to-end.

…mn (SEC-7)

Each stored secret's AAD was the (table, column) tag, so a ciphertext could be
relocated between two rows of the same column and still authenticate (swap one
registry's secret into another, or one user's MFA seed into another user's row).
The threat needs DB write access — outside the DB-read model §6 defends — but is
cheap to close.

encrypt_secret/decrypt_secret now accept an optional row_id: when given, the AAD
becomes "<table>.<column>:<row-id>". decrypt tries the row-bound tag first and
falls back to the bare column tag, so this needs NO migration — every secret
written before row binding still decrypts, and each upgrades to row binding the
next time it's written. Call sites thread the row id (MFA and the OIDC singleton
bind immediately since their rows pre-exist; API-resource create paths bind on
first update, since the id doesn't exist pre-flush). The backup re-wrap preserves
each value's existing binding across a build/restore cycle rather than silently
upgrading it. Passing row_id=obj.id is None-safe (None -> column-only), so no
create-flow reordering was needed.

Tests: row-bound round-trip, a row-42 blob refuses to decrypt as row 43, and a
legacy column-only blob still decrypts when the reader passes a row_id.

The mandatory-MFA policy (required_all / required_admin) is enforced only on
local password login; the OIDC callback delegates the second factor to the IdP.
That is an inherent, documented limitation — OIDC accounts have no local TOTP to
challenge, and forcing one in the redirect flow (or blocking the login) can be
wrong when the IdP already performed MFA, so the review recommends no behavioral
change and enforcement at the IdP.

Rather than change auth behavior, add operator visibility: when a mandatory
policy would require a second factor for the user's role, the OIDC login records
`mfa_delegated_to_idp` in the audit log, so an operator running mandatory MFA can
see which logins relied on the IdP and confirm it enforces MFA. Auth behavior is
unchanged; README security model documents the delegation and the audit signal.

When a mandatory-MFA policy applies to an account that has never enrolled,
enroll-on-first-login lets whoever holds the password complete the first-factor
setup — so in the window before the legitimate user enrolls, a password-only
attacker could bind their own authenticator. This is inherent to self-service
enrollment; the durable fix is out-of-band/admin-provisioned enrollment (a
feature), and blocking self-enrollment would break mandatory MFA for everyone.

Short of that, make the window auditable: the policy-forced first-enrollment
completion (the one code path reached only from a password login's forced-enroll
challenge) now records `forced_by_policy` on its auth.mfa_enabled event, so an
admin can detect an unexpected enrollment and respond. README security model
documents the window and the mitigation.

…-10)

The sliding-window limiter pruned each key's event deque on access but never
evicted idle keys, so a stream of distinct real client IPs grew the backing dict
without bound; PendingMfaStore likewise had no per-user cap on concurrent
challenges (bounded only by the shared IP limiter and the 300s TTL).

The limiter now sweeps fully-expired keys once the map grows past a threshold,
amortized to at most once per N events so it stays O(1) per call; the sweep runs
after the in-flight key's window is finalized so the current key is never
mistaken for idle. PendingMfaStore caps concurrent challenges per user, dropping
the oldest when a new one would exceed the cap (other users unaffected). Tests
cover idle-key eviction, active-key survival, and the per-user cap.

`# syntax=docker/dockerfile:1.7` resolved the BuildKit frontend by mutable tag at
build time — the one build component not pinned by digest. Pin it to the current
1.7 manifest digest (keeping tag + digest together), consistent with the base
images and scanner binaries. A guard test asserts the syntax directive stays
digest-pinned.

Records the H11/M2–M5/M22–M26/L1–L4/L23 remediation batch (per-finding), the
stop-and-ask decisions (uv lockfile, entropy-floor crypto, tecnativa bump), the
new operational knobs (SCRYE_ALLOW_INTERNAL_EGRESS, SCRYE_ALLOW_WEAK_MASTER_KEY),
the additive at-rest hardening (row-bound AAD, no format change), and the
CI-validated items (M26 cosign asset names/identities).

Follow-up isort fix for the import introduced in the SEC-8 commit; no behavior
change.

The initial SC-8 cosign step assumed all three scanners publish detached
certificate (.pem) + signature (.sig) files, which broke the CI image build:
Aqua/Trivy signs each artifact with a Sigstore protobuf bundle
(`trivy_<ver>_checksums.txt.sigstore.json`), not a .pem/.sig pair, so the
`.sig`/`.pem` downloads 404'd.

fetch_verify_extract now takes a signature style: Anchore (grype/syft) keeps the
`--certificate <.pem> --signature <.sig>` path (those assets are confirmed
present), and Aqua (trivy) verifies the bundle with `cosign verify-blob --bundle
<checksums.txt.sigstore.json> --new-bundle-format`. cosign is bumped to v2.6.1,
which unambiguously supports `--new-bundle-format` (Trivy documents that cosign
v2 requires that flag for the bundle format). Verified the RUN block's shell
parses (`sh -n`); the real end-to-end verification runs in CI, which can reach
the release assets.

CI showed the per-vendor split works — Trivy's Sigstore bundle verified OK — but
grype/syft failed identity verification: Anchore signs its release checksums from
`release.yaml@refs/heads/main` (the main-branch ref), while the regexp required a
`@refs/tags/v…` ref. Broaden the Anchore identity regexp to accept either a heads
or tags ref (still pinned to the anchore/grype and anchore/syft repos and the
GitHub Actions OIDC issuer). Trivy's tag-ref regexp is unchanged (it passed).