terraform-provider-power-platform

Provides upgrade path to new releases

https://github.com/microsoft/terraform-provider-power-platform/issues

Vulnerability credited https://github.com/microsoft/terraform-provider-power-platform/security/advisories

https://github.com/microsoft/terraform-provider-power-platform/blob/main/SECURITY.md

DEVELOPER.md instructs contributors to run make precommit, which enforces go fmt and golangci-lint checks; the latter applies Go’s official Code Review Comments style guide and blocks PRs that do not comply. https://github.com/microsoft/terraform-provider-power-platform/blob/main/DEVELOPER.md#L60-L61

Enforced with golangci https://github.com/microsoft/terraform-provider-power-platform/blob/main/.golangci.yml

The build_standard_variables criterion does not apply to this provider.

Summary

The project compiles pure-Go binaries with CGO explicitly disabled (CGO_ENABLED=0). Because no C/C++ compiler or linker is invoked, environment variables such as CC, CFLAGS, CXXFLAGS, or LDFLAGS are irrelevant; therefore the correct questionnaire answer is N/A.

Evidence that CGO is disabled • The GoReleaser build stanza sets CGO_ENABLED=0, ensuring every release build is pure Go and statically linked.  • Go’s own documentation explains that setting CGO_ENABLED=0 bypasses the ​cgo​ tool and thus avoids any dependence on external C tool-chains.  • Community guides show that CGO_ENABLED=0 go build is the standard way to build Go binaries without honoring CC, CFLAGS, etc. 

Implications

Because the provider never calls a native compiler: • Users enable hardening features such as ASan or custom linker flags through Go’s mechanisms (-gcflags, -ldflags) rather than the POSIX variables referenced by the criterion. • There is no risk that the build system will ignore or overwrite CC, CFLAGS, or similar variables, as they are unused.

Conclusion

Select “Not applicable (N/A)” for build_standard_variables, with the justification: “The project is built with CGO_ENABLED=0; no native compiler or linker is used, so CC/CFLAGS/CXXFLAGS/LDFLAGS do not apply.”

The Power Platform Terraform provider’s build process relies on Go’s module-aware go build tool and a single top-level Makefile that triggers that tool once per command. Because Go’s build tool automatically understands and orders all package dependencies, no sub-directory is built in isolation, so there is no risk of the “recursive-make” dependency-skew problem that the criterion seeks to avoid. Therefore the project meets the build_non_recursive requirement.

The provider’s build is already bit-for-bit repeatable, so the correct questionnaire answer for build_repeatable is Met.

Why the build is deterministic 1. Fixed module timestamp – .goreleaser.yml sets mod_timestamp: "{{ .CommitTimestamp }}", forcing the file-modification time on every compiled object to the commit’s Unix epoch, not the current clock time. This removes the usual time-of-build entropy. 2. Path-independent binaries – The -trimpath flag is passed to go build, stripping absolute source paths so that two builders working in different directory trees still emit identical bytes. 3. Version and VCS data pinned to commit – Linker flags embed ProviderVersion, Commit, and Branch, each derived from GoReleaser’s templated values; rebuilding the same tag or commit repeats those constants verbatim. 4. CGO disabled – CGO_ENABLED=0 eliminates variability from external C compilers and host libraries, one of the key prerequisites called out by Go’s reproducible-build guidance. 5. Reproducible-build best-practice alignment – GoReleaser’s own reproducible-build guide recommends exactly this trio (-trimpath, mod_timestamp: "{{ .CommitTimestamp }}", CGO disabled) to achieve bit-for-bit outputs across machines and times. Go’s toolchain maintainers confirm that, with those settings, Go binaries rebuild identically given the same source and toolchain versions.

The software is distributed through the public Terraform Registry, so a user installs it with the conventional workflow (terraform init downloads the declared provider) and removes or upgrades it through the same CLI-managed plugin cache. This leverages Terraform’s language-level package-management convention, satisfying the requirement for an easy, commonly-used installation and uninstallation method. https://registry.terraform.io/providers/microsoft/power-platform/latest/docs

The provider has no installer of its own; Terraform’s CLI downloads the release binary to its internal plugin cache (~/.terraform.d/plugins or the path set by the user-configurable plugin_cache_dir). Because the project does not run an install script that could honor variables like DESTDIR, the requirement does not apply. https://developer.hashicorp.com/terraform/cli/config/config-file#plugin_cache_dir

The repository includes a VS Code Dev Container (.devcontainer/) whose install.sh script automatically installs Go, Terraform, tfplugindocs, Delve, linting tools, and test dependencies; developers open the project in Codespaces or “Remote-Containers,” wait for the container to build, and are immediately ready to edit, run tests, and debug. This one-step Dev Container setup fulfills the requirement for a quick, convention-based development environment. https://github.com/microsoft/terraform-provider-power-platform/blob/main/.devcontainer/features/local_provider_dev/install.sh

All external libraries are declared in go.mod, the standard machine-readable manifest for Go modules, enabling automated tooling to resolve exact versions. https://github.com/microsoft/terraform-provider-power-platform/blob/main/go.mod

The repository uses GitHub Dependabot for Go modules and Terraform modules, configured in .github/dependabot.yml; Dependabot automatically checks for vulnerable versions and opens PRs to update them, providing continuous dependency-vulnerability monitoring. https://github.com/microsoft/terraform-provider-power-platform/blob/main/.github/dependabot.yml

All third-party code is pulled via Go modules (see go.mod), and the repository contains no forked “convenience” copies; updating any dependency is a single go get -u (or Dependabot PR) away, satisfying the requirement that reused components be readily identifiable and updatable. https://github.com/microsoft/terraform-provider-power-platform/blob/main/go.mod

The provider relies on actively-maintained interfaces—e.g., github.com/hashicorp/terraform-plugin-sdk/v2, the current SDK, instead of the deprecated v1 line—and standard Go packages that are not flagged as obsolete. No deprecated HashiCorp SDKs or outdated Go APIs appear in go.mod, demonstrating that the project keeps to current, supported interfaces. https://github.com/microsoft/terraform-provider-power-platform/blob/main/go.mod

Every push and pull-request triggers the “Terraform Provider Checks” GitHub Actions workflow, which builds the provider, runs unit & acceptance tests, and reports pass/fail status in the PR status checks. https://github.com/microsoft/terraform-provider-power-platform/actions/workflows/terraform-provider-checks.yml

The CI workflow runs go test -covermode=count -coverprofile=coverage.out, uploads the report to Codecov, and the dashboard shows overall statement coverage above the 80 % threshold, satisfying the requirement. https://github.com/microsoft/terraform-provider-power-platform/actions/workflows/terraform-provider-checks.yml

https://github.com/microsoft/terraform-provider-power-platform/blob/main/CONTRIBUTING.md#pull-request-checklist

The Pull Request Checklist in CONTRIBUTING.md requires contributors to “Add unit tests and acceptance tests for your contribution … Tests should pass and provide > 80 % coverage of your contribution,” thereby documenting the policy that tests must accompany major new functionality. https://github.com/microsoft/terraform-provider-power-platform/blob/main/CONTRIBUTING.md#pull-request-checklist

The Makefile’s lint target—and the CI workflow that invokes it—runs golangci-lint run, which fails the build on any linter warning, enforcing strict static-analysis and vet checks on every commit. https://github.com/microsoft/terraform-provider-power-platform/blob/main/makefile

The project documents and enforces secure-by-design practices—least privilege OAuth scopes, fail-closed error handling, TLS-only transport, and full mediation of API calls—in its contributor security guidelines, which all new code must follow. https://github.com/microsoft/terraform-provider-power-platform/blob/main/devdocs/security_guidelines.md