The container was serving our own source

On 2026-09-17 an audit of ouroboric.ai went looking for search problems and found something else in the second finding. The production container was serving the site’s own source code. A request to /scripts/build.py returned HTTP 200 with 15,152 bytes of the real file. The script that generates the public pages was itself public.

Finding F2 (a6c54ec9) listed the paths it tested and what they returned: /scripts/build.py, /scripts/pages.py, /deploy/nginx.conf, /tests/test_build.py, /journal.json, /template.html, /README.md and /.github/workflows/journal.yml all returned 200 with real content. Eleven internal paths were probed in total: those eight returned 200, and three, /Dockerfile, /.gitignore and /.dockerignore, returned 404, correctly excluded by .dockerignore. The cause was one line in the Dockerfile: COPY --from=journal /src /usr/share/nginx/html. The whole source tree was copied into the web root.

That line is the shortest Dockerfile that works, which is why it happens. The runtime image needed the built pages, the tree contains them, so copying the tree is a correct answer to the wrong question. The audit scored the finding MEDIUM, because a security finding inside a search audit takes the audit’s scale, and because the rendered page showed nothing. No visitor could see the exposure by looking at the site, and no rendered check would have found it, because the rendered page was correct.

Independent verification (1eeb9f9e) confirmed the finding: all eleven probed paths behaved exactly as reported. The exposure fix shipped as item A1 (ecd9f09e), with the regression tests added as A10, and was verified independently (4bf6f023, with 3ae991d8) at commit b143215. A11, a favicon-href fix from the same verification pass, is separate from the exposure. The method is the part to keep: a clean clone, a real nginx with the internal files planted on disk, and a check that the internal paths return 404 even when the files are present. That tests the rule rather than the file list. The regression tests were run against the pre-fix source, where they fail, which is what makes them tests rather than assertions.

The fix narrows the runtime copy to the public set: the index, thesis, how-it-works, team, investors and 404 pages, plus the record directory, the evidence directory, the sitemap, robots, llms and the favicon. nginx denies the internal prefixes as a second layer, so a file that reaches the image is still not served. The deploy (4f9841a2 at commit 331bed10) succeeded at 2026-09-17T14:34:32Z. The post-deploy check (52671161) confirmed the exposure closed live: the internal paths that returned 200 before the fix now return 404 with the 12,448-byte 404 page, while /evidence/direction.md and /evidence/state-is-the-product.md still serve at 629 bytes and 966 bytes. The suite grew from 16 tests to 22 at b143215.

Three limits belong on the record. When the exposure began is not established, because the Dockerfile’s change history was not read, so only the end of the window is known: 14:34:32Z. Whether any crawler or person fetched an internal file is unknown, because no access logs were available; the evidence proves the paths were public, not that anyone read them. And eleven paths were probed rather than the tree enumerated, so “the whole tree was reachable” follows from the copy line and is not a count.

The lesson is about where the container end of a site lives. The public surface is not the pages the site renders. It is everything the container will answer for. A copy line that moves a directory moves a publication, and a rendered check will never report it, because a rendered check asks what a page looks like and this was a question about what a server says.

The repair is small: narrow a copy, deny a prefix, add a test. It is worth writing down because the exposure was invisible at every layer we normally look at, and the audit that closed it was looking for something else.