AI can draft code. It cannot approve a release.

Faster development does not lower the standard

AI changes how quickly code can be produced. It does not change what must be true before that code reaches customers.

We assume generated code can look plausible and still be wrong. Our controls target observable failure modes rather than confidence in a model.

What we expect generated code to get wrong

These are not theoretical edge cases. They are predictable problems that our review and release process is designed to catch.

• Invented or unsafe dependencies: Invented packages, abandoned projects, vulnerable releases, or unreviewed changes to the dependency graph.
• Code that compiles but breaks: Code can pass local checks and still fail to build, integrate, or behave correctly under real workloads.
• Dead code that is never wired up: A function or component can look complete while never being connected to the rest of the product.
• Architectural violations: A small change can bypass established service boundaries and create dependencies that become expensive to undo later.
• API and OpenAPI spec drift: An endpoint can change without the published contract, documentation, and runtime changing together.
• Untested critical paths: Authentication, authorization, billing, audit logging, and data export need tests that cover every material change.

No change ships on confidence alone

Every commit and every pull request runs through the same pipeline. A change cannot reach a release until every check passes.

• Static analysis: Go and Svelte changes must pass the project linting and formatting rules. New violations stop the build.
• Architectural guards: Custom guards prevent code from crossing package boundaries or accessing the database directly from HTTP handlers. New violations stop the change.
• Deadcode analysis: Every pull request is checked for unused functions, catching code that was added but never connected to the product.
• Vulnerability scanning: The full Go dependency graph is scanned on every push. Known vulnerable packages block the release.
• Supply-chain integrity: Frontend installs use a committed lockfile and verify package signatures. Third-party workflow actions are pinned to specific commits rather than movable tags.
• OpenAPI contract enforcement: The generated OpenAPI specification must remain valid, and contract tests confirm that the running API matches it. API drift fails the build.
• Frontend tests and coverage: Frontend unit and component tests run on every pull request, with coverage changes visible during review.
• Bundle size report: Every pull request reports the compressed bundle size, making unexpectedly heavy dependencies visible before they ship.
• Production build and multi-architecture image: The production build and container image are validated for both linux/amd64 and linux/arm64. Every published architecture must pass.
• Signed image provenance: Published container images include signed attestations linking the image to the workflow and source commit that produced it.
• Scratch base image: The published container has no base operating system, shell, or package manager. It contains the Windshift binary and required certificates only.

Independent testing beyond our pipeline

Automated controls and internal review are not enough on their own. Windshift is also tested by an independent commercial security firm.

Questions about how we use AI, or want a copy of the latest pentest summary? Email security@windshift.sh.

• Annual penetration test by an external commercial security firm.
• Scope covers authentication, authorization, tenant isolation, the public API surface, and the default self-hosted deployment configuration.
• Findings are tracked to resolution. Criticals block the next release.
• A summary of the most recent test is available to enterprise customers under NDA.