The most secure code is code that doesn't exist. Semcom binaries contain only the capabilities declared in the project catalog. Everything else is absent from the binary, the container, and the attack surface.
Traditional software security is additive. You ship a large runtime, then add firewalls, WAFs, RBAC, sandboxing, and monitoring to constrain what it can do. The attack surface is whatever the runtime could do minus whatever your security layers prevent. Every layer has gaps.
Semcom inverts this. The attack surface is whatever the catalog declares. If a capability isn't in the catalog, it doesn't exist in the binary. There's nothing to exploit, nothing to misconfigure, nothing to bypass — because the code was never compiled in.
FROM scratch. Empty.Every Semcom project has a catalog.conf — a plain text file listing the capabilities the project needs. This is the complete inventory of computation the binary can perform.
# projects/website/catalog.conf # These 7 capabilities are the ONLY computation in the binary. http_build_response build_file_path string_copy string_concat string_index_of_char string_length copy_bytes
The build pipeline compiles only these capabilities (plus their transitive dependencies) into the binary. The other 320+ capabilities in the Method Dictionary are not included. They don't exist in the artifact.
Dead code elimination removes unreachable code from a large codebase. The catalog boundary is stronger: the code is never compiled in the first place. There is no version of the binary that contains exec, eval, or any capability not in the catalog. The absence is structural, not incidental.
These are the only 9 words that touch the operating system. This is not a subset — it is the complete interface between the application and the kernel.
| Word | Signature | Purpose |
|---|---|---|
| open-rd | path → fd | Open file read-only |
| read-fd | buf size fd → n | Read bytes from file descriptor |
| write-fd | buf size fd → n | Write bytes to file descriptor |
| close-fd | fd → | Close file descriptor |
| fstat-size | fd → size | Get file size |
| tcp-listen | port → fd | Bind and listen on TCP port |
| accept-conn | fd → fd | Accept incoming connection |
| find-route | path → flag | Dictionary lookup + execute |
| z" | → addr | String literal (compile-time) |
No exec. No fork. No system(). No dlopen. No mmap with execute permissions. No network calls except the TCP listener the server itself opens. Even if an attacker achieved arbitrary code execution inside the Forth interpreter, these 9 words are the only operations available.
The production container is built FROM scratch — Docker's empty base image. The container has:
That's it. No shell. No /bin/sh. No curl. No wget. No package manager. No /etc/passwd. No /tmp. You cannot docker exec into this container because there is nothing to exec. There is no tool to download a second-stage payload with. There is no interpreter to run it.
Remote code execution (no interpreter beyond Forth, no exec syscall). Dependency poisoning (no dependencies). Container escape via shell (no shell). Privilege escalation (no setuid, no sudo, no users). Data exfiltration via DNS/HTTP (no outbound network calls). Supply chain injection (no package manager, no build-time downloads).
For this website — the server you are connected to right now — the entire security audit is:
A compliance officer can read every line of logic. A penetration tester can enumerate every possible operation. A supply chain auditor has nothing to audit because there is no supply chain. This is not a simplification of a security review — it is the complete security review.
Software supply chain attacks increased 742% between 2019 and 2025. The industry response has been to add more scanning, more SBOMs, more monitoring. These are necessary but insufficient — they are detective controls on a system with an enormous attack surface.
Semcom takes the opposite approach: reduce the attack surface until there is nothing left to detect. The catalog declares what exists. The build compiles only that. The container contains only the binary and its content. Everything else is absent.
The most secure code is code that doesn't exist.