terraform-aws-observability-pro

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Met — Development happens in the public GitHub repository using commits and pull requests between releases.
Evidence:

• https://github.com/Codreum/terraform-aws-observability-pro/commits/main
• https://github.com/Codreum/terraform-aws-observability-pro/pulls?q=is%3Apr
  (Optional)
• https://github.com/Codreum/terraform-aws-dns-monitoring-pro/tags

Repository on GitHub, which uses git. git is distributed.

Met — Each user-facing release is identified by an immutable git tag (SemVer), so every release has a unique version identifier.
Evidence:

• https://github.com/Codreum/terraform-aws-observability-pro/tags
  (If using GitHub Releases)
• https://github.com/Codreum/terraform-aws-dns-monitoring-pro/releases

Met — Each release is recorded in version control using immutable git tags.
Evidence:

• https://github.com/Codreum/terraform-aws-observability-pro/tags

Non-trivial release notes file in repository: https://github.com/Codreum/terraform-aws-observability-pro/blob/main/CHANGELOG.md.

https://github.com/Codreum/terraform-aws-observability-pro/releases

Users submit bug reports via Codreum Support (not GitHub Issues). The contribution/support process is documented here:

• CONTRIBUTING: https://github.com/Codreum/terraform-aws-observability-pro/blob/main/CONTRIBUTING.md
• Contact (bug/feature/improvement suggestions): https://www.codreum.com/contact
• Support portal / case management: https://www.codreum.com/support
• My Cases (open/track tickets): https://www.codreum.com/cases.html ( require login )

We use Codreum’s support case system as our issue tracker for individual reports. Each bug report becomes a tracked case (status updates, follow-ups, resolution notes) in:

• My Cases: https://www.codreum.com/cases.html

All bug reports submitted through Codreum Support receive an acknowledgement and initial triage response (does not require an immediate fix). See:

• https://github.com/Codreum/terraform-aws-observability-pro/blob/main/README.md (section included support)
• Support portal: https://www.codreum.com/support
• My Cases: https://www.codreum.com/cases.html

Enhancement/feature requests are submitted via the Contact/Support channels and receive a response (at minimum: acknowledgement + triage/status). See:

• https://github.com/Codreum/terraform-aws-observability-pro/blob/main/README.md (section included support)
• Contact: https://www.codreum.com/contact
• Support portal: https://www.codreum.com/support

We maintain a publicly available, searchable Knowledge Base with known issues, how-to articles, and documented resolutions/updates:

• Knowledge Base: https://www.codreum.com/knowledge.html

Individual customer reports are handled privately via cases, and we publish generalized/anonymized guidance as Knowledge Base articles when appropriate.

We publish vulnerability reporting instructions in SECURITY.md:

• SECURITY.md: https://github.com/Codreum/terraform-aws-observability-pro/blob/main/SECURITY.md

We support private vulnerability reports. Report security issues privately as described in SECURITY.md (e.g., email support channel). Do not open public GitHub issues.

• SECURITY.md: https://github.com/Codreum/terraform-aws-observability-pro/blob/main/SECURITY.md

We acknowledge vulnerability reports and begin triage promptly, with initial response within 14 days or less (typically sooner). Process is documented in:

• SECURITY.md: https://github.com/Codreum/terraform-aws-observability-pro/blob/main/SECURITY.md

N/A — This repository contains Terraform templates and documentation. Users consume the templates directly with Terraform; there is no compilation/build step required to use the project.

(We do publish optional release bundles for convenience, but a build is not required for use.)
https://github.com/Codreum/terraform-aws-observability-pro/blob/main/.github/workflows/release.yml

This project uses standard, widely used build/validation tools: Terraform CLI for templates (fmt check), Python for template validation, and Go for fuzzing. Release artifacts are bundled with tar + sha256sum and signed with cosign. Evidence: .github/workflows/ci.yml (terraform fmt + python validation) and .github/workflows/release.yml (tar/sha256/cosign).

The project can be built/validated using only FLOSS tooling: Terraform CLI, Python, Go toolchain, and standard Unix tools. CI demonstrates this in .github/workflows/ci.yml (terraform fmt + python validation) and .github/workflows/fuzz.yml (go test fuzz). Note: Access to the Codreum private registry may be required for deploying the Pro module, but the build/validation toolchain itself is FLOSS.

We have automated tests/checks that run in CI on PRs and main: Terraform template formatting checks and a Python template validation test suite (validate_templates.py) that fails CI if templates are inconsistent. We also run an automated Go fuzz test. Evidence: .github/workflows/ci.yml (terraform fmt check + python validation) and .github/workflows/fuzz.yml (go test fuzz). We document local invocation in README/BUILD.

Test invocation is documented in the README. From the repository root, run make test for template checks (Terraform formatting and the Python template validation script), make tf-validate-templates for functional Terraform validation of templates (using a stubbed local module to avoid requiring private registry access), and make fuzz to run the Go fuzz test. Manual equivalents are also documented.

CI is implemented with GitHub Actions and runs automatically on pull requests and on pushes to main. Evidence: .github/workflows/ci.yml triggers on pull_request and push to main

.github/workflows/ci.yml
.github/scripts/validate_templates.py
.github/workflows/fuzz.yml
.github/workflows/release.yml

Automated tests/checks run in CI and are invocable locally. The suite includes template checks (terraform fmt -check + .github/scripts/validate_templates.py), functional validation of templates via Terraform (terraform init -backend=false + terraform validate on a stubbed copy of templates), and optional Go fuzzing. These commands are documented in README and enforced in CI.

Policy: changes that modify templates or validation tooling must include corresponding updates to automated tests/checks. At minimum, affected templates must continue to pass make test and make tf-validate-templates (and fuzzing where applicable). PRs must pass CI before merge.

Recent template changes are accompanied by updates to the automated test suite (template checks and/or functional Terraform validation). Example: include the PR/commit link where a template change also updates or extends the test harness/fixtures.

For this templates-only Terraform repository, “warning flags” are implemented via strict linters/checkers that fail CI: Terraform formatting checks, template convention validation, and functional Terraform validation (terraform validate) on generated/stubbed template configs. CI treats findings as failures.

Findings from linters/checkers are treated as failures in CI. PRs must resolve issues and pass required checks before merging.

Linters/checkers run in strict mode and fail the build on findings (no warnings-only mode). Terraform format/validate and template validation are required CI checks.

At least one primary maintainer reviews changes for security and follows a secure-by-default approach for Terraform templates (least privilege, avoid secrets in code, safe defaults). Security review expectations are documented in CONTRIBUTING.md (Security section) and changes must pass CI checks before merge.

The project documents common security pitfalls for Terraform templates (e.g., secrets in config, overly broad IAM, public exposure, missing encryption/log retention) and required mitigations (CI checks, code review, least privilege defaults). Guidance is documented in CONTRIBUTING.md and enforced via required CI checks.

This repository provides Terraform templates and does not implement cryptographic algorithms or protocols. Any encryption is handled by underlying platforms/tools (e.g., Terraform, TLS transport, AWS-managed encryption) rather than custom crypto in this repository.

No cryptographic functionality is implemented in this repository.

No cryptographic mechanisms are implemented by the project.

No cryptographic mechanisms are implemented or configured directly by the project.

The project does not depend on broken cryptographic algorithms or modes because it does not implement cryptography.

The project does not implement cryptography or select crypto algorithms/modes.

This repository does not implement cryptography or network protocols. Any TLS properties (including PFS) are provided by the hosting/distribution platform (e.g., GitHub over HTTPS) rather than custom code in this repo.

This repository does not store or process end-user passwords. It contains Terraform templates and supporting tooling only.

This repository does not generate cryptographic keys or nonces. Any cryptographic operations are handled by underlying platforms/tools, not implemented here.

Source is delivered via GitHub over HTTPS (or SSH for contributors). Users obtain the project using git clone https://github.com/Codreum/terraform-aws-observability-pro.git (or git@github.com:Codreum/terraform-aws-observability-pro.git), which counters MITM.

This repository is obtained via GitHub over HTTPS/SSH. We do not publish separate checksum files for release artifacts retrieved over HTTP.

We monitor dependencies and vulnerabilities using GitHub security features (Dependabot alerts/security updates + code scanning where applicable). We triage and remediate medium+ vulnerabilities promptly; currently there are no open medium+ vulnerability alerts older than 60 days.

https://github.com/Codreum/terraform-aws-observability-pro/blob/main/SECURITY.md

Critical vulnerabilities are handled via coordinated vulnerability disclosure as documented in SECURITY.md. We triage immediately and aim to acknowledge critical reports within 1 business day and provide a fix or mitigation within 7 days when feasible, with at least weekly updates if upstream coordination or complexity requires more time.
The repository also enables GitHub private vulnerability reporting to allow confidential disclosure.

The repository is templates-only and does not store valid private credentials. Contributors are instructed not to commit secrets, and CI/review practices are used to prevent accidental secret inclusion.

This repository runs static analysis in CI (GitHub CodeQL / code scanning) on changes before release. Findings are reviewed via GitHub Security code scanning alerts.

Static analysis includes security-focused rulesets (e.g., CodeQL security queries and/or IaC scanners like tfsec/checkov) to detect common vulnerability patterns and insecure IaC configurations.

Medium/high severity findings from static analysis (CodeQL / IaC scanners) are triaged and remediated according to the timelines documented in SECURITY.md. We use GitHub Security alerts as the tracking mechanism for fixes.

Static analysis runs automatically on pull requests (and on a scheduled cadence) so new issues are detected quickly.

Dynamic checks are run in CI by executing Terraform validation against representative template inputs, and fuzzing is used to exercise parsers/inputs beyond fixed test cases.

the repository primarily contains Terraform templates and does not ship software written in memory-unsafe languages (e.g., C/C++)

Dynamic checks run in CI in test mode (Terraform validation and Go fuzz tests) and are not part of production artifacts, providing additional runtime checking during development.

Medium/high severity issues found via dynamic checks (template validation / fuzzing) are triaged and fixed according to the SECURITY.md timelines, using GitHub issues/security advisories as needed.