Security

Principles

These principles define what we treat as a vulnerability. Any way to break them is in scope.

• No cloud credentials

  Moduloom never stores or uses Azure or AWS credentials. Your pipeline authenticates to the cloud with OIDC (workload identity federation).

• No plan, no apply

  The most the tool can do is open a pull request. A person approves it and your pipeline applies it with your runners and your state.

• Self-hosted

  Moduloom installs with Helm in your Kubernetes (EKS, AKS, or kind). Designs, network layouts, and Git credentials stay in your environment. The default install is the most restrictive one: AI off, sign-up closed, TLS required.

• Deterministic, verified output

  Terraform is produced by an emitter that only accepts typed values and escapes everything. It never concatenates text or uses templates. Every output is parsed back and compared with the design, and the same design always yields the same bytes.

• Every change is a pull request

  Changes reach your repo only as pull requests that a person reviews. A check in your pipeline fails if the Terraform in the repo no longer matches the design.

• Tenant isolation in two layers

  Authorization in the application and Row-Level Security in PostgreSQL, with least privilege for the Git app, Kubernetes service accounts, and database roles.

Reporting a vulnerability

Thank you for helping keep Moduloom safe. Please do not open a public issue, pull request, or discussion with the details. Report privately instead:

1. GitHub private vulnerability reporting (preferred, once the repository is public): theReport a vulnerability button in the repository's Security tab.
2. Email: contact@moduloom.dev, with the subject[SECURITY] Moduloom: <short summary>. While the repository is private, this is the channel to use.

What to include

• Affected version or commit, and how it is installed (kind, EKS, AKS).
• Component: engine, API, web, Helm chart, or pipeline templates.
• Steps to reproduce or a minimal proof of concept.
• The impact you expect, for example reading another organization's data or injecting code into generated Terraform.
• Whether you want to be credited, and under what name.

Do not include real customer data or live credentials. If you need to show a secret, use a fake or revoked one.

What you can expect

We keep you updated and agree on the disclosure date with you. We publish a GitHub Security Advisory when the fix is available and credit you if you wish. If we cannot meet a target, we tell you before it passes and explain why.

Good faith

Test only against your own installation, do not access or modify other people's data, and do not degrade services you do not own. If you follow these rules, we consider your work good-faith research.

Scope

In scope:

• The code in the Moduloom repository: engine (Terraform rendering, rules, CLI), API, and web app.
• The Helm chart, manifests, and example Terraform for deployment.
• The pipeline templates we provide for customers.
• The project's CI and supply chain: workflows, published images, SBOMs, and signatures.

Out of scope:

• Vulnerabilities in third-party dependencies that cannot be exploited through Moduloom (report them upstream).
• Your infrastructure and your plan/apply pipeline, unless the problem comes from one of our templates.
• Installations using a configuration the documentation explicitly marks as insecure.
• Attacks that require physical access or a cluster administrator account.
• Volumetric denial of service, and automated scanner reports without a demonstrated impact.