feat(ops): ship the tool and its engine in one image

A contributor should be able to run this with nothing installed but Docker:

  docker compose build
  TARGET=/path/to/repo docker compose run --rm ousast scan /target

One image rather than two services, and the reason is the seam. The model
layer reaches Joern by subprocess; putting both in the same image means Joern
is simply on PATH, so there is no container-to-container call, no docker socket
to mount, no host/container path translation, and no second code path in
cpg/backend.py to get wrong. Sibling services would need the tool to exec into
the engine's container, which means handing a linter the docker socket -- a
large amount of privilege for something that reads source code. The image is
big (a JRE plus ~2 GB of Joern); that is the honest cost of bundling an engine.

I had started building the two-service version with a docker-wrapper mode in
the backend and dropped it, tests included: once the engine is on PATH the
wrapper is complexity with no purpose.

Defaults chosen so an unfamiliar analyser is safe to try: the target mounts
READ-ONLY, /work is a tmpfs so CPG scratch never outlives the run or touches
the host, network_mode is `none` unless the LLM judge is wanted, and API keys
pass through the environment rather than into an image layer. mem_limit is set
because two Joern JVMs at once is what triggered an out-of-memory kill on a
7.7 GB machine during this feature's measurements.

pyinfra deploy kept for persistent host installs, with the same version pin and
the same checksum verification -- done as an explicit `sha512sum -c` step
because pyinfra's files.download offers sha384/sha256/sha1/md5 and Joern
publishes sha512. That mismatch was caught by validating against the installed
pyinfra rather than trusting the API from memory.

Both include php-cli: php2cpg drives PHP-Parser and shells out to a real
interpreter, and without it a PHP tree fails with an opaque "Process exited
with code 1" -- measured here, which is what makes a WordPress corpus feasible.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01T7XD7x5KonMdmGRkp63EQG

docker-compose.yml

@@ -0,0 +1,33 @@
+# OpenUltraSAST as a contributor runs it: nothing installed on the host but Docker.
+#
+#   docker compose build
+#   TARGET=/path/to/repo docker compose run --rm ousast scan /target
+#
+# The target is mounted READ-ONLY. A tool that reads your source to tell you about it has no business being
+# able to write to it, and a contributor evaluating an unfamiliar analyser should not have to take that on
+# trust.
+
+services:
+  ousast:
+    build:
+      context: .
+      args:
+        JOERN_VERSION: ${JOERN_VERSION:-v4.0.623}
+    image: openultrasast:${OUSAST_VERSION:-dev}
+    volumes:
+      - ${TARGET:-.}:/target:ro          # the repository under analysis, read-only
+      - ./reports:/reports               # where findings land, the one writable mount
+    working_dir: /work
+    tmpfs:
+      # CPG construction is scratch-heavy and none of it should outlive the run or touch the host.
+      - /work:size=${WORK_SIZE:-4g}
+    environment:
+      # The LLM endpoint is optional: without it the model layer still entails, and the suspicion band simply
+      # goes unasked. Passed through rather than baked in, so no key is ever in an image layer.
+      DEEPSEEK_API_KEY: ${DEEPSEEK_API_KEY:-}
+      OPENROUTER_API_KEY: ${OPENROUTER_API_KEY:-}
+      TMPDIR: /work
+    # A CPG build is memory-hungry, and two Joern JVMs at once is what triggered an out-of-memory kill on a
+    # 7.7 GB machine during this project's measurements.
+    mem_limit: ${OUSAST_MEM_LIMIT:-6g}
+    network_mode: ${OUSAST_NETWORK:-none}   # `bridge` only when the LLM judge is wanted