What process should we use to "bless" a module as "officially supported" at our company?

[brikis98]

We got a question from a customer that I wanted to share here so others can find it:

What the steps are for our central platform team to ‘bless’ a module for general consumption?

I'll share Gruntwork's recommendation below. We'd also love to hear about the processes you use at your companies!

---

Tracked in ticket #110586

[brikis98]

This process varies for every company. Here are some common patterns for you to consider in your own process:

1. Repo. Typically, “blessed” modules must live in a specific repo: e.g., a centrally-managed infrastructure-modules repo.
2. Coding conventions. The module, and everything in that infrastructure-modules repo, should follow certain coding conventions: e.g., file naming, variable naming, comment style, etc. E.g., See Gruntwork’s Terraform style guide as a starting point.
3. Docs. The module must be documented. Typically, a README.md is sufficient, but for complex modules, sometimes you need more. See also the Gruntwork Library reference.
4. Tests. The module must have automated tests. We recommend, at a bare minimum, functional tests where, after every commit, you deploy the module to a real AWS account, validate it works as expected, and then undeploy it. You can write such tests using Terratest.
5. Security scans. The module must pass various security scans. You may wish to use tools such as tfsec, terrascan, OPA, tflint, and snyk.
6. Policy scans. You may also want to enforce that the module passes various policy scans. These overlap with the security scans mentioned in the previous item—and therefore, you may use the same tools—but the policies you enforce may involve not only security requirements, but other business and legal requirements: e.g., perhaps you don’t want to allow certain AWS services to be used, so you could create a policy that scans the Terraform code for the relevant resources, and blocks merge if those are found. You might also enforce policies around compliance requirements: e.g., CIS, PCI, NIST, etc.

[atrachtenberg]

7. Community, Support, and Maintenance How active are the people who develop and use the module, and how healthy (or toxic) is their behavior. Once you rely on a module, you’re signing up to ensure it works today and tomorrow: fixing bugs and security vulnerabilities; supporting new versions of operating systems, chips, or modules it uses; and adding new features you need to solve future problems. A healthy community will largely handle those for you or facilitate you making this happen. Abandoned software places you as the person responsible for this (either directly or by hiring someone). Even if you have the skills or money, is that where you want to spend your time?
8. Licensing Does the license support how you currently (and might in the future) use the software. What happens if this changes?