Code Security

Run Shannon vulnerability assessments on your Studio project repository — distinct from ORGN Scanner attestation auditing.

Studio Code Security runs automated vulnerability assessments against your project's repository inside an isolated Trust Domain. It is powered by Shannon — ORGN's security operations pipeline — and answers:

"What vulnerabilities exist in my codebase?"

This is not ORGN Scanner. Scanner audits Gateway inference and sandbox attestation. Code Security analyzes your source code.

Shannon vs Scanner

	Code Security (Shannon)	ORGN Scanner
Product surface	Studio → Project → Security tab	`scanner.orgn.com`
Question answered	What CWE-class vulnerabilities exist in this repo?	Was this inference request attested in a verified Trust Domain?
Scope	Project repository (static/dynamic analysis)	Gateway spend logs, attestation receipts, sandboxes
Trigger	Manual "Start Assessment" or CI integration	Automatic on every Gateway TEE request
Output	Findings, scores, remediation guidance, exportable reports	Request metadata, attestation status, verification hashes
Backend	Shannon pentest pipeline via Deno security scan API + Trigger.dev	ClickHouse spend logs + attestation store

If procurement asks for "security scanning," clarify whether they mean code vulnerability analysis (Shannon) or inference attestation audit (Scanner). Both are load-bearing for different compliance narratives.

Running an assessment

Open your project in ORGN Studio.
Navigate to Security.
Click Start Assessment.

Shannon provisions an isolated container, reads the full repository, and evaluates:

Dependency vulnerabilities
Configuration misconfigurations
Common application logic flaws (CWE-class patterns)
Insecure defaults in infrastructure-as-code files

The scan is read-only — it does not modify your repository or affect active worktrees.

While running, the UI shows execution status. Active scan state is tracked server-side so you can navigate away and return.

Findings and reports

Findings tab

Displays the latest assessment results:

Status — Clean or findings detected
Score — Aggregate security score (e.g. 100/100 when clean)
Structured findings — CWE classification, affected files, severity, remediation guidance

History tab

Maintains an audit log of all past assessments:

Date, duration, files analyzed, finding count
Execution status (running, completed, cancelled)
Open any historical scan to review its full report

Report sections

Each completed assessment includes:

Executive summary — high-level status for engineering leads
Full report — detailed findings with file paths and fix guidance
Compliance — alignment summary for audit workflows
Deliverables — JSON export for CI/CD pipelines and external dashboards

Isolation and safety

Security assessments:

Run inside sandboxed TDX containers scoped to the project
Do not push changes to Git
Do not access external systems unless you configure them via project secrets
Do not interfere with active chat worktrees or agent sessions

Recommended workflow

Implement a feature in a chat worktree (/chat/:id).
Run tests in the workspace terminal.
Open Security → Start Assessment.
Review the executive summary and detailed findings.
Fix issues in a new worktree.
Re-run the assessment to confirm resolution.
Create a pull request once the project is clean.

Run assessments before major releases, after dependency upgrades, and during periodic security reviews. Retained history demonstrates consistent validation over time.

ORGN Scanner — inference and compute attestation audit
Platform trust model — how code security fits the four-layer stack
Project settings → Sandboxes — where assessments execute
Glossary → Shannon vs Scanner — term disambiguation

On this page