ovalenzuela/crane repository overview

⁠CRAne

Compliance evidence and audit workflow platform. It tracks which products and components exist, how they relate, who owns them, whether they are in scope under each competing definition, and whether their evidence holds up.

Documentation: https://oscarvalenzuelab.github.io/CRAne⁠ · Apache-2.0

It answers the questions that are usually spread across several systems and several spreadsheets:

• How many products are there, and how many components?
• Which components ship in more than one product?
• Which products are in scope — under whose definition? Legal, the ship room, the commercial catalog and the regulatory reading of the CRA each get their own lens, and a product can be in scope under one and out of scope under another. Both are kept, and every number names the lens it used.
• Which have an SBOM, and is that SBOM any good?
• Where does the whole effort actually stand?

Obligations are plural: the CRA ships alongside FedRAMP and the NTIA minimum elements, each with its own checks, weights and reporting lens. Nothing imported is treated as a decision — everything lands as an observation, and approving it is a separate recorded act with an authority and a rationale.

⁠Sixty seconds

You need Docker. Nothing else.

mkdir -p crane/data && cd crane

# The directory has to be writable by the container's user, so hand it your own uid.
docker run --rm -v "$PWD/data:/data" --user "$(id -u):$(id -g)" \
    ovalenzuela/crane:latest init

# Eight invented products, chosen to show the situations this exists for.
docker run --rm -v "$PWD/data:/data" --user "$(id -u):$(id -g)" \
    ovalenzuela/crane:latest demo

docker run --rm -p 127.0.0.1:8000:8000 -v "$PWD/data:/data" \
    --user "$(id -u):$(id -g)" -e CRANE_ALLOW_UNAUTHENTICATED_BIND=1 \
    ovalenzuela/crane:latest serve --host 0.0.0.0 --port 8000 --worker

Open http://127.0.0.1:8000⁠.

The database is a single SQLite file at data/crane.db. Open it with any SQLite browser. That is deliberate: nothing here is locked inside a format only this tool can read.

⁠Tags

Two variants, because the validator question has no single answer. SBOM conformance is checked by a separate tool, and which one you need depends on which obligations you measure against. The plain image runs everything except validations, which report the executable as missing — recorded as a coverage gap rather than a compliance verdict, so nothing scores as failing merely because a tool was never installed. The -ossbomer variant is the right default if you are measuring against the CRA or NTIA profiles.

Both are linux/amd64 and linux/arm64. Pin a version for anything you depend on; latest moves.

⁠Volumes

Nothing is baked into the image except code. No database, no credentials, no data. It runs as uid 10001, so mounted directories have to be writable by that uid — or pass --user "$(id -u):$(id -g)" as above.

⁠Exposing it

Inside a container the server has to bind 0.0.0.0 for a published port to reach it, so it refuses to start that way unless you have made a decision:

• Set CRANE_API_TOKEN — the real answer for anything reachable by anyone else.
• Or publish the port to 127.0.0.1 only and set CRANE_ALLOW_UNAUTHENTICATED_BIND=1.

There is no TLS inside the container. Put a reverse proxy in front of it. Configure⁠ covers every variable.

⁠Security

No release is pushed with a fixable HIGH or CRITICAL vulnerability in it. The scan runs in the release workflow before the push, so a tag that exists is a tag that passed, and the gate ignores only findings with no fix available in any stable Debian suite.

Further than the gate requires: the perl interpreter is removed from the image entirely. Nothing here invoked it, and leaving it in meant carrying critical CVEs that Debian has no fix for in any stable suite. If a future base-image advisory does show up in the scan results with no upstream fix, that is what it is — unfixable, and named rather than hidden.

Security⁠ covers reporting a vulnerability, hardening a real deployment, and the design decisions that look like findings and are not.

⁠Driving it from an agent

The agent guide ships in the image, so an agent on a machine with no route to the documentation still has the rules, the exit codes and the working loop:

docker run --rm --entrypoint cat ovalenzuela/crane:latest /app/AGENTS.md