Epic: Harden repository, application, build, and delivery

[DenWin]

Goal

Harden ConvertX across repository governance, CI/CD, application security and resilience, Docker/runtime, build reproducibility, dependencies, and static validation.

Hardening is evidence-driven: establish baselines, add tests/controls, demonstrate that controls detect representative failures, and document accepted residual risks.

Existing related work

Docker/runtime

• Evaluate and pin the production Debian base image #2 stable and pinned Debian base
• Make downloaded Docker build dependencies reproducible #3 reproducible downloaded dependencies
• Run the ConvertX container as a non-root user #4 non-root runtime
• Audit and reduce Docker runtime dependencies #5 runtime dependency/size audit
• Add BuildKit caching and multi-platform Docker validation #6 BuildKit caching and multi-platform validation
• Improve container health checks and subprocess lifecycle handling #7 health checks and subprocess lifecycle

Testing and architecture safety

• Establish TDD, retrospective characterization, and real-world assessment #16 TDD, retrospective characterization, and real-world assessment
• Audit existing behavior and testability before retrospective testing #17 behavior/testability audit
• Create a characterization harness and testable application bootstrap #18-Add browser-level characterization for existing user workflows #23 focused characterization suites

Do not duplicate those issues. This epic adds cross-cutting hardening and links existing foundations.

Hardening domains

• GitHub Actions and CI/CD security.
• Application security boundaries and abuse resistance.
• Application resilience, process control, and data integrity.
• Container supply chain and production runtime controls.
• Deterministic, offline-capable build verification.
• Repository governance and security configuration.
• Coherent linting, type checking, policy, and validation gates.

Governing requirements

• Least privilege by default.
• Immutable or automatically verified dependencies.
• Forked pull requests cannot access secrets or publish artifacts.
• Security-critical controls have negative tests proving they fail closed.
• CI checks are reproducible locally where practical.
• Exceptions are time-bounded, documented, and owned.
• Release artifacts are traceable to source, workflow, dependencies, and image digest.
• Hardening work follows Establish TDD, retrospective characterization, and real-world assessment #16.

Completion criteria

• Required branch checks and repository protections are enabled.
• CI/CD dependencies and permissions are least-privilege and auditable.
• Application abuse, ownership, path, process, and data-integrity controls are tested.
• Images are minimized, scanned, signed/attested, and reproducible.
• Builds fail on undeclared network/dependency/generated-artifact drift.
• Lint/type/test/security/format policies are non-overlapping and enforced.
• Residual risks and operational response are documented.

[DenWin]

Existing foundations linked

Docker issues #2-#7 are now direct sub-issues of this epic. Testing and retrospective characterization remain governed by #16-#23 and are linked rather than duplicated. Application hardening waits for the relevant characterization safety net before structural changes.