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

All cryptographic operations rely on the Go standard-library TLS stack (TLS 1.2+ with AES-GCM) and Microsoft Entra ID tokens signed with SHA-256; the only hash used directly in the code is SHA-256 (crypto/sha256) in internal/helpers/hash.go. No component depends on SHA-1, MD5, CBC-mode SSH, or other algorithms with known serious weaknesses. https://github.com/microsoft/terraform-provider-power-platform/blob/main/internal/helpers/hash.go

The provider defers all cryptographic operations to the Go standard‐library TLS stack, which automatically negotiates among multiple modern cipher suites (e.g., AES-GCM and ChaCha20-Poly1305 with SHA-256/384) during every HTTPS connection. Because at least two strong symmetric ciphers and hash families are available and selected at runtime, users gain algorithm agility without changes to the code. https://pkg.go.dev/crypto/tls#pkg-constants

The provider accepts all authentication material—client IDs, secrets, certificates, OIDC tokens—via environment variables or dedicated Terraform variables, entirely separate from the main configuration files; users can rotate or replace these credentials at any time without rebuilding the provider. https://registry.terraform.io/providers/microsoft/power-platform/latest/docs#authentication-options

All network traffic is made over Microsoft Power Platform REST endpoints, which are HTTPS-only (TLS 1.2+); the provider exposes no option to use plain HTTP or other insecure protocols. https://registry.terraform.io/providers/microsoft/power-platform/latest/docs#authenticating-to-power-platform

Every API call is made over HTTPS endpoints that require TLS 1.2 or later; no HTTP fallback is available. https://registry.terraform.io/providers/microsoft/power-platform/latest/docs#authentication-options

The provider relies on Go’s default net/http client—which performs full X.509 certificate validation—and communicates only with HTTPS endpoints, so TLS certificate verification is always enabled by default. https://pkg.go.dev/net/http#Client

Using Go’s standard net/http client, the provider completes the TLS handshake (including certificate verification) before it writes any HTTP request—so Authorization headers and other private data are only sent after the certificate is validated. https://pkg.go.dev/net/http#Transport

Releases are signed by GoReleaser’s signs block, which detaches a GPG signature over the SHA-256 checksums file using the maintainer’s key (GPG_FINGERPRINT env var); each GitHub release publishes both the *_SHA256SUMS file and its .sig, and the repository’s release instructions explain how to import the public key and verify the signature. https://github.com/microsoft/terraform-provider-power-platform/blob/main/.goreleaser.yml#L40-L55

Release binaries are built with Go 1.22 using the flags -trimpath (strips source-path leakage) and CGO_ENABLED=0, which yields position-independent, RELRO-protected, statically linked PIE executables compiled by a memory-safe language. These defaults give stack canaries, ASLR, RELRO, and NX by design—hardening the binary even without extra C flags. https://github.com/microsoft/terraform-provider-power-platform/blob/main/.goreleaser.yml#L12-L19

Every push and pull-request triggers the CodeQL workflow in GitHub Actions, which runs CodeQL’s Go security queries to detect common vulnerabilities such as SQL injection, command execution, and unsafe deserialization. Thus the project applies a FLOSS static-analysis tool focused on vulnerability discovery. https://github.com/microsoft/terraform-provider-power-platform/actions/workflows/codeql.yml

The entire codebase is written in Go with CGO_ENABLED=0, so no memory-unsafe C or C++ code is compiled; therefore dynamic memory-safety tools are not applicable. https://github.com/microsoft/terraform-provider-power-platform/blob/main/go.mod