OpOrder is designed to be run against a real codebase and a real cloud account. If it can't be trusted with that, nothing else in this project matters — this document is held to the same evidence standard as the rest of the repo, not boilerplate.

Do not open a public GitHub issue for a security vulnerability. Use GitHub Security Advisories for this repository, which creates a private disclosure thread. If that's not available to you for any reason, email security@codetocloud.io.

Include what you'd want to receive yourself: the affected version, a minimal repro, and the actual impact — what an attacker gains, not just that something looks off.

Response commitment: acknowledgment within 5 business days. This project does not yet have the maintainer bandwidth to promise faster, and a false promise here would be worse than an honest one — see this spec's own repeated position on not committing to process the project can't actually sustain yet.

Disclosure: coordinated. We'll work with you on a fix and a timeline before any public detail, and credit you in the advisory and the changelog unless you'd rather stay anonymous.

• Anything that leaks credentials, cloud account data, or source code somewhere it wasn't explicitly sent by the user.
• Anything that lets a scanned repository or cloud account cause OpOrder to take an action, make a network call, or alter its own output beyond what the user asked for — see the prompt-injection threat model below, which is the sharpest edge case this category of tool has.
• Privilege escalation beyond what the configured cloud credentials should allow.
• Supply-chain issues in a released binary (see §"Supply chain" below).

Out of scope: a wrong 5/7-Rs recommendation, an inaccurate cost estimate, or a debt-delta call you disagree with. Those are quality bugs — file them as normal GitHub issues per CONTRIBUTING.md, not here. A wrong answer isn't a vulnerability; a leaked credential is.

OpOrder's cloud connectors (§4, §4.5 of SPEC.md) are read-only by design and are never logged, never written into any report file, and never included in what gets sent to an LLM. Only derived findings — "this bucket has public read access," not the credential that discovered it — cross that boundary, and only when the user has configured an LLM call at all. Self-hosted is the default; there is no telemetry, and no report or finding is sent anywhere OpOrder wasn't explicitly told to send it.

The same standard applies to the LLM provider key itself (§4.6 of SPEC.md), which wasn't previously addressed here even though it's a credential like any other: oporder auth writes the key to ~/.config/oporder/auth.json created with 0600 permissions (owner read/write only, never group- or world-readable), the key is never printed in full in any log or error message (truncated to a fingerprint if it needs to appear at all), and a crash or panic never dumps process environment or config contents into a stack trace. A leaked LLM key is a smaller blast radius than a leaked cloud credential, but it's still real money and real access, and gets the same discipline, not a lesser one because it's newer.

Development against a real account never puts that account's identity in the public repo. No subscription/account name, subscription/account ID, tenant name or ID, or resource name from a real cloud account ever appears in a commit message, code comment, test fixture, or issue — those get passed as runtime arguments or environment variables, exactly like a credential, never hardcoded or written into anything version-controlled. This project develops against real accounts (§7's live-credential integration path exists specifically because mocked fixtures alone eventually drift from reality) — the account's existence is fine to mention in the abstract; anything that identifies it is not.

Every commit touching a provider connector gets scanned before it's made, not after. A quick grep across staged files for known account IDs, ARNs, tenant names, and any live token fragments, run as a real step before git commit — not a mental check. This caught a real instance during this project's own early development (a subscription name that made it into a commit message) within minutes of it happening, which is exactly the point: cheap, mechanical, and it works precisely because it doesn't rely on remembering to be careful in the moment.

OpOrder reads two kinds of content it does not control: arbitrary source code in the repository being assessed, and arbitrary metadata in the cloud account being scanned (resource names, tags, descriptions). Both are attacker-reachable in a real scenario — a malicious dependency, a compromised contributor's commit, or a resource tag set by someone with limited account access could all contain text crafted to manipulate an LLM into a false or dangerous conclusion. This is close to exactly the shape of Simon Willison's "lethal trifecta" already cited as Tier 0 material in the Code To Cloud vault's own security research: private data (the account being scanned), untrusted content (arbitrary code/metadata), and a channel out (the LLM call, and anything downstream that trusts its output).

Mitigations already designed into the architecture, and their honest limits:

• The fresh-context verifier discipline (§5.7) means no single compromised finding reaches the report without an independent check — but a verifier reading the same poisoned content can, in principle, be fooled the same way the worker was. This is a partial mitigation, not a solved problem, and is tracked as an open item, not a closed one.
• The rubric (§5.3–§5.5) is evidence-based and auditable specifically so a manipulated conclusion is more likely to look wrong against the visible rubric than it would coming from an opaque model call with no rubric to check it against.
• What this doesn't yet have: a dedicated, tested defense specifically against adversarial content planted in scanned repos or cloud metadata. Treat this as a known gap until it has one, and report anything that demonstrates it concretely as a vulnerability, not a feature request.

SBOM generation and SLSA provenance are planned, triggered by the first tagged binary release (SPEC.md §13.2) — not built yet, because there's nothing to attest to the provenance of before then. Until that pipeline exists, verify a release's checksum against the GitHub release page before running an unfamiliar binary, the same caution you'd apply to any infrastructure tool that touches live cloud credentials.

Per SPEC.md §4.1, cloud and pricing API access is isolated behind MCP servers specifically so the blast radius of a bug in that code is bounded to "reads cloud state," never "runs arbitrary commands" or "writes to the account." Any MCP server requesting write access, broader-than-read-only scopes, or credentials beyond what a specific check needs is treated as a design defect, not a convenience worth keeping.

Same discipline as a wrong recommendation (CONTRIBUTING.md): a confirmed security issue gets a regression test that would have caught it, committed alongside the fix, so the same class of issue can't silently reappear in a future refactor.