terraform-provider-power-platform

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 8714 est passing Voici comment l'intégrer :

Ce sont les critères du niveau Argent. Vous pouvez également afficher les critères des niveaux Basique ou Or.

        

 Notions de base 13/17

  • Identification

    Power Platform Terraform Provider

  • Conditions préalables


    Le projet DOIT atteindre un badge de niveau basique. [achieve_passing]

  • Contenu basique du site Web du projet


    Les informations sur la façon de contribuer DOIVENT inclure les exigences pour des contributions acceptables (par exemple, une référence à toute règle de codage requise). (URL requise) [contribution_requirements]
  • Supervision du projet


    Le projet DEVRAIT avoir un mécanisme juridique par lequel tous les développeurs de quantités non triviales de logiciel du projet affirment qu'ils sont légalement autorisés à effectuer ces contributions. L'approche la plus commune et facilement mise en œuvre pour ce faire est d'utiliser un Certificat d'origine du développeur (DCO), où les utilisateurs ajoutent une information « sign-off-by » dans leurs commits et le projet pointe vers le site Web du DCO. Cependant, cela PEUT être mis en œuvre en tant que contrat de licence de contributeur (CLA), ou tout autre mécanisme juridique. (URL requise) [dco]

    Le projet DOIT définir et documenter clairement son modèle de gouvernance de projet (la façon dont il prend ses décisions, y compris les rôles clés). (URL requise) [governance]


    Le projet DOIT adopter un code de conduite et le publier dans un lieu standard. (URL requise) [code_of_conduct]

    Le projet DOIT clairement définir et documenter publiquement les rôles clés dans le projet et leurs responsabilités, y compris les tâches que ces rôles doivent accomplir. Il DOIT être clairement exprimé qui a quel(s) rôle(s), mais cela pourrait ne pas être documenté de la même manière. (URL requise) [roles_responsibilities]

    Roles and responsibilities are not defined in the repo



    Le projet DOIT pouvoir continuer avec une interruption minimale si une personne décède, est invalidée ou ne peut/veut plus continuer à maintenir le projet. En particulier, le projet DOIT être en mesure de créer et de fermer des problèmes, d'accepter les modifications proposées et de publier des versions du logiciel, dans un délai d'une semaine après confirmation du retrait d'un individu du projet. Cela PEUT être fait en s'assurant que quelqu'un d'autre possède les clés, les mots de passe et les droits juridiques nécessaires pour poursuivre le projet. Les personnes qui exécutent un projet FLOSS PEUVENT faire cela en fournissant des clés dans un coffre-fort et un testament fournissant les droits légaux nécessaires (par exemple, pour les noms DNS). (URL requise) [access_continuity]

    The repository’s CODEOWNERS file designates the GitHub team @microsoft/power-platform-terraform-maintainers as the default reviewer/approver for every path, ensuring that multiple maintainers—not a single individual—can create issues, merge PRs, and trigger signed releases. If any one maintainer becomes unavailable, other team members still have the permissions and secrets (stored in the organization) to continue project operations within a week, satisfying the access-continuity requirement. https://github.com/microsoft/terraform-provider-power-platform/blob/main/CODEOWNERS



    Le projet DEVRAIT avoir un « bus factor » de 2 ou plus. (URL requise) [bus_factor]
  • Documentation


    Le projet DOIT avoir une feuille de route documentée qui décrit ce que le projet a l'intention de faire et ne pas faire pour au moins l'année suivante. (URL requise) [documentation_roadmap]

    Le projet DOIT inclure la documentation de l'architecture (aussi appelée conception de haut niveau) du logiciel produit par le projet. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). (URL requise) [documentation_architecture]

    Le projet DOIT documenter ce à quoi l'utilisateur peut et ne peut pas s'attendre en termes de sécurité à partir du logiciel produit par le projet (ses « exigences de sécurité »). (URL requise) [documentation_security]


    Le projet DOIT fournir un guide de « démarrage rapide » pour les nouveaux utilisateurs afin de les aider à faire rapidement quelque chose avec le logiciel. (URL requise) [documentation_quick_start]

    Le projet DOIT faire un effort pour maintenir la documentation conforme à la version actuelle des résultats du projet (y compris les logiciels produits par le projet). Tous les défauts de la documentation connus la rendant incohérente DOIVENT être corrigés. Si la documentation est généralement à jour, mais inclut de manière erronée certaines informations antérieures qui ne sont plus vraies, considérez cela comme un défaut, puis faites le suivi et corrigez comme d'habitude. [documentation_current]

    La page d'accueil et/ou le site Web du dépôt du projet DOIVENT identifier et pointer tous les accomplissements, y compris ce badge sur les meilleures pratiques, dans les 48 heures suivant la reconnaissance publique que l'accomplissement a été atteint. (URL requise) [documentation_achievements]
  • Accessibilité et internationalisation


    Le projet (à la fois les sites du projet et les résultats du projet) DEVRAIT suivre les meilleures pratiques d'accessibilité afin que les personnes handicapées puissent encore participer au projet et utiliser les résultats du projet où il est raisonnable de le faire. [accessibility_best_practices]

    Le logiciel produit par le projet DEVRAIT être internationalisé pour permettre une localisation facile pour la culture, la région ou la langue du public cible. Si l'internationalisation (i18n) ne s'applique pas (par exemple, le logiciel ne génère pas de texte destiné aux utilisateurs finaux et ne trie pas de texte lisible par les humains), sélectionnez « non applicable » (N/A). [internationalization]

    This provider is a back-end plugin that exchanges structured data with the Terraform CLI. It emits a small set of diagnostic strings (errors, warnings, and attribute descriptions) aimed at infrastructure engineers, but it has no end-user UI, does not present menus or documentation in-tool, and does not sort or otherwise process human-readable text. Because the software’s primary interface is machine-readable configuration, internationalization is not relevant to its function.


  • Autre


    Si les sites du projet (site Web, dépôt et URL de téléchargement) entreposent des mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être entreposés comme hachages itérés avec salage par utilisateur en utilisant un algorithme d'étirement des clés (itéré) (par exemple, Argon2id, Bcrypt, Scrypt, ou PBKDF2). Si les sites du projet n'entreposent pas de mots de passe à cette fin, sélectionnez « non applicable » (N/A). [sites_password_security]

    Does not store passwords


  • Versions précédentes


    Le projet DOIT maintenir les anciennes versions les plus utilisées du produit ou fournir un chemin de mise à niveau vers des versions plus récentes. Si le chemin de mise à niveau est difficile, le projet DOIT documenter comment effectuer la mise à niveau (par exemple, les interfaces qui ont changé et une suggestion d'étapes détaillées pour aider la mise à niveau). [maintenance_or_update]

    Provides upgrade path to new releases


  • Procédure de signalement des bogues


    Le projet DOIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]
  • Processus de signalement de vulnérabilité


    Le projet DOIT créditer les auteurs de tous les signalements de vulnérabilité résolus au cours des 12 derniers mois, à l'exception des auteurs qui demandent l'anonymat. S'il n'y a pas eu de vulnérabilité résolue au cours des 12 derniers mois, sélectionnez « non applicable » (N/A). (URL requise) [vulnerability_report_credit]

    Le projet DOIT avoir un processus documenté pour répondre aux signalements de vulnérabilité. (URL requise) [vulnerability_response_process]
  • Normes de codage


    Le projet DOIT identifier les guides de style de codage spécifiques pour les langages principaux qu'il utilise, et exiger que les contributions le respectent en général. (URL requise) [coding_standards]

    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



    Le projet DOIT imposer automatiquement son ou ses styles de codage sélectionnés s'il existe au moins un outil FLOSS qui peut le faire dans le(s) langage(s) sélectionné(s). [coding_standards_enforced]
  • Système de construction opérationnel


    Les systèmes de construction pour les binaires natifs DOIVENT honorer les variables (d'environnement) pertinentes du compilateur et du lieur qui leur sont transmises (par exemple, CC, CFLAGS, CXX, CXXFLAGS et LDFLAGS) et les transmettre aux invocations du compilateur et du lieur. Un système de construction PEUT les étendre avec des options supplémentaires ; il NE DOIT PAS simplement remplacer les valeurs fournies par les siennes. Si aucun fichier binaire natif n'est généré, sélectionnez « non applicable » (N/A). [build_standard_variables]

    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.”



    Le système de construction et d'installation DEVRAIT préserver les informations de débogage si elles sont demandées dans les options correspondants (par exemple, « install -s » n'est pas utilisé). S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_preserve_debug]

    Le système de construction pour le logiciel produit par le projet NE DOIT PAS reconstruire de manière récursive des sous-répertoires s'il existe des dépendances croisées dans les sous-répertoires. S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_non_recursive]

    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.



    Le projet DOIT pouvoir répéter le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Si aucune construction ne se produit (par exemple, dans les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). [build_repeatable]

    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.


  • Système d'installation


    Le projet DOIT fournir un moyen d'installer et de désinstaller facilement le logiciel produit par le projet en utilisant une convention couramment utilisée. [installation_common]

    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



    Le système d'installation pour les utilisateurs finaux DOIT honorer les conventions standard pour sélectionner l'emplacement où les artefacts construits sont écrits au moment de l'installation. Par exemple, s'il installe des fichiers sur un système POSIX, il DOIT honorer la variable d'environnement DESTDIR. S'il n'y a pas de système d'installation ou pas de convention standard, sélectionnez « non applicable » (N/A). [installation_standard_variables]

    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



    Le projet DOIT fournir un moyen pour les développeurs potentiels d'installer rapidement tous les résultats du projet ainsi que l'environnement nécessaire pour apporter des modifications, y compris les tests et l'environnement de test. Cela DOIT être effectué avec une convention couramment utilisée. [installation_development_quick]

    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


  • Composants maintenus à l'extérieur


    Le projet DOIT afficher ses dépendances externes de manière analysable par ordinateur. (URL requise) [external_dependencies]

    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



    Les projets DOIVENT surveiller ou vérifier périodiquement leurs dépendances externes (y compris les copies de commodité) pour détecter les vulnérabilités connues, et corriger les vulnérabilités exploitables ou les vérifier comme inexploitables. [dependency_monitoring]

    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



    Le projet DOIT :
    1. rendre facile l'identification et la mise à jour des composants maintenus extérieurement au projet ; ou
    2. utiliser des composants standards fournis par le système ou le langage de programmation.
    Ensuite, si une vulnérabilité se trouve dans un composant réutilisé, il sera facile de mettre à jour ce composant. [updateable_reused_components]

    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



    Le projet DEVRAIT éviter d'utiliser des fonctions et des API obsolètes quand des alternatives FLOSS sont disponibles dans l'ensemble de technologies qu'il utilise (sa « pile de technologies ») et disponibles à une large majorité des utilisateurs supportés par le projet (afin que les utilisateurs puissent avoir accès à l'alternative). [interfaces_current]

    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


  • Suite de tests automatisée


    Une suite de tests automatisée DOIT être appliquée à chaque commit dans un dépôt partagé pour au moins une branche. Cette suite de tests DOIT produire un rapport sur le succès ou l'échec du test. [automated_integration_testing]

    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



    Le projet DOIT ajouter des tests de régression à une suite de tests automatisée pour au moins 50% des bogues corrigés au cours des six derniers mois. [regression_tests_added50]

    The project does not track fixes and their corresponding regression tests in a way that lets us demonstrate that at least half of the bugs resolved in the past six months received new or updated test coverage; therefore we cannot currently claim compliance with the 50 % regression-test threshold.



    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage80]

    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


  • Nouveau test de fonctionnalité


    Le projet DOIT avoir une politique écrite formelle, que dès qu'une nouvelle fonctionnalité majeure est ajoutée, des tests pour la nouvelle fonctionnalité DOIVENT être ajoutés à une suite de tests automatisée. [test_policy_mandated]

    Le projet DOIT inclure, dans ses instructions documentées pour les propositions de changement, la politique selon laquelle des tests doivent être ajoutés pour toute nouvelle fonctionnalité majeure. [tests_documented_added]

    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


  • Options d'avertissement


    Les projets DOIVENT être maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]

    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


  • Connaissance du développement sécurisé


    Le projet DOIT implémenter des principes de conception sécurisés (à partir de « know_secure_design »), quand cela est approprié. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). [implement_secure_design]

    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


  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). [crypto_weaknesses]

    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



    Le projet DEVRAIT supporter plusieurs algorithmes cryptographiques, afin que les utilisateurs puissent rapidement changer si l'un deux est cassé. Les algorithmes à clés symétriques courants incluent AES, Twofish et Serpent. Les alternatives d'algorithme de hachage cryptographique courantes incluent SHA-2 (y compris SHA-224, SHA-256, SHA-384 ET SHA-512) et SHA-3. [crypto_algorithm_agility]

    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



    Le projet DOIT supporter le stockage des informations d'authentification (comme les mots de passe et les jetons dynamiques) et des clés cryptographiques privées dans des fichiers distincts des autres informations (fichiers de configuration, bases de données et journaux) et permettre aux utilisateurs de les mettre à jour et de les remplacer sans recompilation de code. Si le projet ne traite jamais d'informations d'authentification et de clés cryptographiques privées, sélectionnez « non applicable » (N/A). [crypto_credential_agility]

    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



    Le logiciel produit par le projet DEVRAIT supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DEVRAIENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (N/A). [crypto_used_network]

    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



    Le logiciel produit par le projet DEVRAIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_tls12]

    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



    Le logiciel produit par le projet DOIT, s'il prend en charge TLS, effectuer la vérification des certificats TLS par défaut lors de l'utilisation de TLS, y compris sur les sous-ressources. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_certificate_verification]

    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



    Le logiciel produit par le projet DOIT, s'il supporte TLS, effectuer une vérification de certificat avant d'envoyer des en-têtes HTTP avec des informations privées (telles que des cookies sécurisés). Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_verification_private]

    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


  • Livraison sécurisée


    Le projet DOIT signer cryptographiquement les versions des résultats du projet destinées à une utilisation répandue, et il DOIT y avoir un processus documenté expliquant aux utilisateurs comment ils peuvent obtenir les clés de signature publique et vérifier la ou les signatures. La clé privée pour ces signature(s) NE DOIT PAS être sur le(s) site(s) utilisé(s) pour distribuer directement le logiciel au public. Si les versions ne sont pas destinées à une utilisation répandue, sélectionnez « non applicable » (N/A). [signed_releases]

    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



    Il est PROPOSÉ que, dans le système de contrôle de la version, chaque tag d'une version importante (un tag faisant partie d'une version majeure, d'une version mineure ou qui corrige des vulnérabilités notées publiquement) soit cryptographiquement signé et vérifiable comme décrit dans signed_releases. [version_tags_signed]

    Release commits are GPG-signed, but the Git tags themselves are unsigned (the tag pages show no “Verified” badge), so important version tags are not cryptographically verifiable. https://github.com/microsoft/terraform-provider-power-platform/releases/tag/v3.3.0


  • Autres problèmes de sécurité


    Les résultats du projet DOIVENT vérifier toutes les entrées provenant de sources potentiellement non fiables pour s'assurer qu'elles sont valides (une liste blanche) et rejeter les entrées non valides, en cas de restrictions sur les données. [input_validation]

    The provider relies on Terraform’s schema typing for basic type-safety, and some attributes include explicit ValidateFunc rules, but a systematic allow-list validation is not applied to every user-supplied string, number, or collection. Several resource fields (for example display_name, description, and JSON policy blobs) accept free-form text with no length, character-set, or pattern checks, so malformed or out-of-range values could still propagate to API calls. Because comprehensive input whitelisting is absent, the project does not yet satisfy the input_validation requirement.



    Les mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. [hardening]

    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



    Le projet DOIT fournir une analyse de fiabilité qui justifie pourquoi ses exigences de sécurité sont respectées. L'analyse de fiabilité DOIT inclure : une description du modèle de menace, une identification claire des limites de confiance, un argument selon lequel des principes de conception sécurisés ont été appliqués et un argument selon lequel les faiblesses de sécurité courantes de l'implémentation ont été contrées. (URL requise) [assurance_case]
  • Analyse statique de code


    Le projet DOIT utiliser au moins un outil d'analyse statique avec des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé, s'il existe au moins un outil FLOSS qui peut mettre en œuvre ce critère dans le langage sélectionné. [static_analysis_common_vulnerabilities]

    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


  • Analyse dynamique de code


    Si le logiciel produit par le projet inclut un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple C ou C++), alors le projet DOIT utiliser au moins un outil dynamique (par exemple, un fuzzer ou un scanneur d'application Web) utilisé de manière routinière en combinaison avec un mécanisme permettant de détecter des problèmes de sécurité mémoire tels que les dépassement mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, sélectionnez « non applicable » (N/A). [dynamic_analysis_unsafe]

    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



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Matt Dotson and the OpenSSF Best Practices badge contributors.

Soumission du badge du projet appartenant à : Matt Dotson.
Soumission créée le 2024-03-26 23:43:05 UTC, dernière mise à jour le 2025-04-26 07:54:20 UTC. Le dernier badge obtenu l'a été le 2024-03-27 04:40:06 UTC.

Retour