Skip to content

Security: cychiang/xp-provider-gen

SECURITY.md

Security Policy

Reporting a vulnerability

Report privately through GitHub's Report a vulnerability form. Please do not open a public issue, and please do not include a working exploit — a description of the class of problem and the affected code path is enough to act on.

Useful things to include: the command and flags you ran, the flavor (native or upjet), the generator version (xp-provider-gen version), and what an attacker would gain.

This is a personal project, not a vendored product. Expect a first response within a week, and no guaranteed patch timeline.

Supported versions

main, and the latest release. Releases are cut from main by the Release workflow.

What is in scope

This tool generates code. That makes "where the vulnerability lives" the first question worth answering, because the three cases have different owners:

In scope — the generator itself. Anything xp-provider-gen does on your machine: path traversal when writing a scaffold, update/update --adopt overwriting or destroying files it should not touch, command injection through a flag value, or a template that renders attacker-controlled input into generated source.

In scope — what the templates produce. A scaffolded provider that ships an insecure default: over-broad RBAC, credentials written somewhere world-readable, a container running as root, or a generated manifest that widens access beyond what the resource needs.

Not in scope — your provider's own code. Everything behind the ownership seam is yours. Files without the Code generated by xp-provider-gen. DO NOT EDIT. header are never rewritten by this tool, and what you put in them is your responsibility.

Not in scope — upstream. A vulnerability in Crossplane, Kubebuilder, upjet, or in the Terraform provider an upjet-flavored provider wraps, belongs to that project. Report it there. If our scaffolding makes such a flaw materially worse — by, say, pinning a version known to be vulnerable — that part is ours, so tell us as well.

What we already run

Every pull request is scanned by gosec and Trivy, and results go to the repository's Security tab. GitHub Actions are pinned to commit SHAs rather than floating tags, so a compromised upstream tag cannot silently change what CI executes; Renovate updates those digests.

Generated providers deliberately carry no Go toolchain directive — see docs/development.md — so they build with whatever Go you have. Keep it current; that is the half of the supply chain this tool cannot pin for you.

There aren't any published security advisories