scorecard
v5.0.0
Nous avons créé Scorecard pour aider les responsables de l'open source à améliorer leurs meilleures pratiques de sécurité et pour aider les consommateurs open source à juger si leurs dépendances sont sûres.
Scorecard est un outil automatisé qui évalue un certain nombre d'heuristiques (« vérifications ») importantes associées à la sécurité des logiciels et attribue à chaque vérification une note de 0 à 10. Vous pouvez utiliser ces scores pour comprendre les domaines spécifiques à améliorer afin de renforcer la posture de sécurité de votre projet. Vous pouvez également évaluer les risques introduits par les dépendances et prendre des décisions éclairées quant à l'acceptation de ces risques, à l'évaluation de solutions alternatives ou à la collaboration avec les responsables pour apporter des améliorations.
L'inspiration du logo de Scorecard : "Vous avez réussi ! Tous les D... et un A !"
Automatisez l’analyse et faites confiance aux décisions sur la posture de sécurité des projets open source.
Utilisez ces données pour améliorer de manière proactive la posture de sécurité des projets critiques dont dépend le monde.
Agir comme outil de mesure des politiques existantes
Si les consommateurs de logiciels libres exigent certains comportements de la part de leurs dépendances, Scorecard peut être utilisé pour les mesurer. Avec la version V5, nous considérons les résultats structurés comme un moyen d'y parvenir s'il existe une analyse prise en charge. Au lieu de s'appuyer sur un score global de X/10 ou un score maintenu de Y/10, un consommateur de logiciels libres souhaitera peut-être s'assurer que le dépôt dont il dépend n'est pas archivé (ce qui est couvert par la sonde archived ). L'OpenSSF adopte cette approche avec sa propre base de sécurité pour les projets.
Être un rapport définitif ou une exigence que tous les projets doivent suivre.
Scorecard n’est pas destiné à être une solution universelle. Chaque étape de l'obtention de nos résultats est fondée sur une opinion : quels contrôles sont inclus ou exclus, l'importance de chaque contrôle et comment les scores sont calculés. Les contrôles eux-mêmes sont des heuristiques ; il y a des faux positifs et des faux négatifs.
Que ce soit pour des raisons d'applicabilité, de faisabilité ou d'opinion, ce qui est inclus ou exclu des résultats du Scorecard suscite de nombreuses discussions. Il est impossible de créer un tableau de bord qui satisfasse tout le monde, car différents publics se soucieront de différents sous-ensembles de comportement.
Les scores globaux en particulier ne vous disent rien sur les comportements individuels qu'un référentiel fait ou ne fait pas. De nombreux scores de contrôle sont regroupés en un seul score, et il existe plusieurs façons d'arriver au même score. Ces scores changent à mesure que nous ajoutons de nouvelles heuristiques ou affinons celles existantes.
Scorecard a été exécuté sur des milliers de projets pour surveiller et suivre les mesures de sécurité. Les projets importants qui utilisent Scorecard incluent :
Pour voir les scores des projets régulièrement analysés par Scorecard, accédez au visualiseur Web. Vous pouvez également remplacer le texte de l'espace réservé (plate-forme, utilisateur/organisation et nom du référentiel) dans le lien du modèle suivant pour générer un lien Scorecard personnalisé pour un dépôt : https://scorecard.dev/viewer/?uri=<github_or_gitlab>.com/<user_name_or_org>/<repository_name>
Par exemple:
Pour afficher les scores des projets non inclus dans la visionneuse Web, utilisez la CLI Scorecard.
Nous effectuons une analyse hebdomadaire Scorecard du million de projets open source les plus critiques, jugés en fonction de leurs dépendances directes, et publions les résultats dans un ensemble de données public BigQuery.
Ces données sont disponibles dans l'ensemble de données public BigQuery openssf:scorecardcron.scorecard-v2 . Les derniers résultats sont disponibles dans la vue BigQuery openssf:scorecardcron.scorecard-v2_latest .
Vous pouvez interroger les données à l'aide de BigQuery Explorer en accédant à Ajouter des données > Star a project by name > "openssf". Par exemple, vous pourriez être intéressé par l'évolution du score d'un projet au fil du temps :
SELECT date , score FROM ` openssf.scorecardcron.scorecard-v2 ` WHERE repo . name = " github.com/ossf/scorecard " ORDER BY date ASC Vous pouvez extraire les derniers résultats vers le stockage Google Cloud au format JSON à l'aide de l'outil bq :
# Get the latest PARTITION_ID
bq query --nouse_legacy_sql 'SELECT partition_id FROM
openssf.scorecardcron.INFORMATION_SCHEMA.PARTITIONS WHERE table_name="scorecard-v2"
AND partition_id!="__NULL__" ORDER BY partition_id DESC
LIMIT 1'
# Extract to GCS
bq extract --destination_format=NEWLINE_DELIMITED_JSON
'openssf:scorecardcron.scorecard-v2$<partition_id>' gs://bucket-name/filename-*.json
La liste des projets vérifiés est disponible dans le fichier cron/internal/data/projects.csv de ce référentiel. Si vous souhaitez que nous en suivissions davantage, n'hésitez pas à envoyer une Pull Request avec d'autres personnes. Actuellement, cette liste est dérivée de projets hébergés sur GitHub UNIQUEMENT . Nous prévoyons de les étendre dans un avenir proche pour prendre en compte les projets hébergés sur d'autres systèmes de contrôle de code source.
Le moyen le plus simple d'utiliser Scorecard sur les projets GitHub que vous possédez est d'utiliser l'action Scorecard GitHub. L'action s'exécute sur toute modification du référentiel et émet des alertes que les responsables peuvent consulter dans l'onglet Sécurité du référentiel. Pour plus d’informations, consultez les instructions d’installation de Scorecard GitHub Action.
Pour interroger les scores précalculés des projets OSS, utilisez l'API REST.
Pour permettre à votre projet d'être disponible sur l'API REST, définissez publish_results: true dans le paramètre Scorecard GitHub Action.
Les données fournies par l'API REST sont sous licence CDLA Permissive 2.0.
L'activation de publish_results: true dans Scorecard GitHub Actions permet également aux responsables d'afficher un badge Scorecard sur leur référentiel pour montrer leur travail acharné. Ce badge se met également à jour automatiquement pour chaque modification apportée au référentiel. Voir plus de détails sur cet article de blog OSSF.
Pour inclure un badge sur le référentiel de votre projet, ajoutez simplement la démarque suivante à votre README :
[](https://scorecard.dev/viewer/?uri=github.com/{owner}/{repo})
Pour exécuter une analyse Scorecard sur des projets dont vous ne possédez pas, utilisez l'option d'installation de l'interface de ligne de commande.
Plateformes : actuellement, Scorecard prend en charge les plates-formes OSX et Linux. Si vous utilisez un système d'exploitation Windows, vous pourriez rencontrer des problèmes. Les contributions à la prise en charge de Windows sont les bienvenues.
Langue : GoLang doit être installé pour exécuter Scorecard (https://golang.org/doc/install)
scorecard est disponible sous forme de conteneur Docker :
docker pull gcr.io/openssf/scorecard:stablePour utiliser une version spécifique du tableau de bord (par exemple, v3.2.1), exécutez :
docker pull gcr.io/openssf/scorecard:v3.2.1Pour installer Scorecard de manière autonome :
Visitez notre page de dernière version et téléchargez le fichier zip approprié pour votre système d'exploitation.
Ajoutez le binaire à votre répertoire GOPATH/bin (utilisez go env GOPATH pour identifier votre répertoire si nécessaire).
Nous générons des signatures SLSA3 à l'aide du slsa-framework/slsa-github-generator d'OpenSSF pendant le processus de publication. Pour vérifier un binaire de version :
attestation.intoto.jsonl à partir de la page des versions de GitHub.slsa-verifier -artifact-path < the-zip > -provenance attestation.intoto.jsonl -source github.com/ossf/scorecard -tag < the-tag > | Gestionnaire de paquets | Distribution prise en charge | Commande |
|---|---|---|
| Rien | NixOS | nix-shell -p nixpkgs.scorecard |
| Assistant AUR | Arch Linux | Utilisez votre assistant AUR pour installer scorecard |
| Homebrew | macOS ou Linux | brew install scorecard |
GitHub impose des limites de débit API sur les requêtes non authentifiées. Pour éviter ces limites, vous devez authentifier vos demandes avant d'exécuter Scorecard. Il existe deux manières d'authentifier vos demandes : soit créer un jeton d'accès personnel GitHub, soit créer une installation d'application GitHub.
public_repo . Définissez le jeton dans une variable d'environnement appelée GITHUB_AUTH_TOKEN , GITHUB_TOKEN , GH_AUTH_TOKEN ou GH_TOKEN à l'aide des commandes ci-dessous en fonction de votre plateforme. # For posix platforms, e.g. linux, mac:
export GITHUB_AUTH_TOKEN= < your access token >
# Multiple tokens can be provided separated by comma to be utilized
# in a round robin fashion.
export GITHUB_AUTH_TOKEN= < your access token 1> , < your access token 2>
# For windows:
set GITHUB_AUTH_TOKEN= < your access token >
set GITHUB_AUTH_TOKEN= < your access token 1> , < your access token 2>OU
set ou export ) indiquées ci-dessus pour votre plate-forme. GITHUB_APP_KEY_PATH=<path to the key file on disk>
GITHUB_APP_INSTALLATION_ID=<installation id>
GITHUB_APP_ID=<app id>
Ces variables peuvent être obtenues à partir de la page des paramètres du développeur GitHub.
Scorecard peut s'exécuter en utilisant un seul argument, l'URL du dépôt cible :
$ scorecard --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e
Starting [CII-Best-Practices]
Starting [Fuzzing]
Starting [Pinned-Dependencies]
Starting [CI-Tests]
Starting [Maintained]
Starting [Packaging]
Starting [SAST]
Starting [Dependency-Update-Tool]
Starting [Token-Permissions]
Starting [Security-Policy]
Starting [Signed-Releases]
Starting [Binary-Artifacts]
Starting [Branch-Protection]
Starting [Code-Review]
Starting [Contributors]
Starting [Vulnerabilities]
Finished [CI-Tests]
Finished [Maintained]
Finished [Packaging]
Finished [SAST]
Finished [Signed-Releases]
Finished [Binary-Artifacts]
Finished [Branch-Protection]
Finished [Code-Review]
Finished [Contributors]
Finished [Dependency-Update-Tool]
Finished [Token-Permissions]
Finished [Security-Policy]
Finished [Vulnerabilities]
Finished [CII-Best-Practices]
Finished [Fuzzing]
Finished [Pinned-Dependencies]
RESULTS
-------
Aggregate score: 7.9 / 10
Check scores:
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| SCORE | NAME | REASON | DOCUMENTATION/REMEDIATION |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Binary-Artifacts | no binaries found in the repo | github.com/ossf/scorecard/blob/main/docs/checks.md#binary-artifacts |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 9 / 10 | Branch-Protection | branch protection is not | github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection |
| | | maximal on development and all | |
| | | release branches | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| ? | CI-Tests | no pull request found | github.com/ossf/scorecard/blob/main/docs/checks.md#ci-tests |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | CII-Best-Practices | no badge found | github.com/ossf/scorecard/blob/main/docs/checks.md#cii-best-practices |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Code-Review | branch protection for default | github.com/ossf/scorecard/blob/main/docs/checks.md#code-review |
| | | branch is enabled | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Contributors | 0 different companies found -- | github.com/ossf/scorecard/blob/main/docs/checks.md#contributors |
| | | score normalized to 0 | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Dependency-Update-Tool | no update tool detected | github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Fuzzing | project is not fuzzed in | github.com/ossf/scorecard/blob/main/docs/checks.md#fuzzing |
| | | OSS-Fuzz | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 1 / 10 | Maintained | 2 commit(s) found in the last | github.com/ossf/scorecard/blob/main/docs/checks.md#maintained |
| | | 90 days -- score normalized to | |
| | | 1 | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| ? | Packaging | no published package detected | github.com/ossf/scorecard/blob/main/docs/checks.md#packaging |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 8 / 10 | Pinned-Dependencies | unpinned dependencies detected | github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies |
| | | -- score normalized to 8 | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | SAST | no SAST tool detected | github.com/ossf/scorecard/blob/main/docs/checks.md#sast |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 0 / 10 | Security-Policy | security policy file not | github.com/ossf/scorecard/blob/main/docs/checks.md#security-policy |
| | | detected | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| ? | Signed-Releases | no releases found | github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Token-Permissions | tokens are read-only in GitHub | github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions |
| | | workflows | |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
| 10 / 10 | Vulnerabilities | no vulnerabilities detected | github.com/ossf/scorecard/blob/main/docs/checks.md#vulnerabilities |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- | Le GITHUB_AUTH_TOKEN doit être défini sur un jeton valide
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:stable --show-details --repo=https://github.com/ossf/scorecardPour utiliser une version spécifique du tableau de bord (par exemple, v3.2.1), exécutez :
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:v3.2.1 --show-details --repo=https://github.com/ossf/scorecard Pour plus de détails sur les raisons pour lesquelles une vérification échoue, utilisez l'option --show-details :
./scorecard --repo=github.com/ossf-tests/scorecard-check-branch-protection-e2e --checks Branch-Protection --show-details
Starting [Pinned-Dependencies]
Finished [Pinned-Dependencies]
RESULTS
-------
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
| SCORE | NAME | REASON | DETAILS | DOCUMENTATION/REMEDIATION |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
| 9 / 10 | Branch-Protection | branch protection is not | Info: 'force pushes' disabled | github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection |
| | | maximal on development and all | on branch 'main' Info: 'allow | |
| | | release branches | deletion' disabled on branch | |
| | | | 'main' Info: linear history | |
| | | | enabled on branch 'main' Info: | |
| | | | strict status check enabled | |
| | | | on branch 'main' Warn: status | |
| | | | checks for merging have no | |
| | | | specific status to check on | |
| | | | branch 'main' Info: number | |
| | | | of required reviewers is 2 | |
| | | | on branch 'main' Info: Stale | |
| | | | review dismissal enabled on | |
| | | | branch 'main' Info: Owner | |
| | | | review required on branch | |
| | | | 'main' Info: 'administrator' | |
| | | | PRs need reviews before being | |
| | | | merged on branch 'main' | |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
Les annotations du responsable permettent aux responsables d'ajouter du contexte à afficher à côté des résultats de la vérification de la carte de score. Les annotations peuvent fournir aux utilisateurs des informations supplémentaires lorsque Scorecard dispose d'une évaluation incomplète des pratiques de sécurité d'un projet. Pour voir les annotations des responsables pour chaque vérification, utilisez l'option --show-annotations .
Pour plus d'informations sur les annotations disponibles ou comment créer des annotations, consultez la documentation de configuration.
Pour exécuter Scorecard sur un référentiel GitLab, vous devez créer un jeton d'accès GitLab avec les autorisations suivantes :
read_apiread_userread_repository Vous pouvez exécuter Scorecard sur un référentiel GitLab en définissant la variable d'environnement GITLAB_AUTH_TOKEN :
export GITLAB_AUTH_TOKEN=glpat-xxxx
scorecard --repo gitlab.com/ < org > / < project > / < subproject >Pour un exemple d'utilisation de Scorecard dans GitLab CI/CD, voir ici.
Bien que nous nous concentrions sur la prise en charge de GitLab.com, Scorecard fonctionne également avec les installations GitLab auto-hébergées. Si votre plateforme est hébergée sur un sous-domaine (par exemple gitlab.foo.com ), Scorecard devrait fonctionner immédiatement. Si votre plate-forme est hébergée sur un slug (par exemple foo.com/bar/ ), vous devrez définir la variable d'environnement GL_HOST .
export GITLAB_AUTH_TOKEN=glpat-xxxx
export GL_HOST=foo.com/bar
scorecard --repo foo.com/bar/ < org > / < project > Pour utiliser un hôte GitHub Enterprise github.corp.com , utilisez la variable d'environnement GH_HOST .
# Set the GitHub Enterprise host without https prefix or slash with relevant authentication token
export GH_HOST=github.corp.com
export GITHUB_AUTH_TOKEN=token
scorecard --repo=github.corp.com/org/repo
# OR without github host url
scorecard --repo=org/repo Pour les projets des écosystèmes --npm , --pypi , --rubygems ou --nuget , vous avez la possibilité d'exécuter Scorecard à l'aide d'un gestionnaire de packages. Fournissez le nom du package pour exécuter les vérifications sur le code source GitHub correspondant.
Par exemple, --npm=angular .
Pour exécuter uniquement des vérifications spécifiques, ajoutez l'argument --checks avec une liste de noms de vérifications.
Par exemple, --checks=CI-Tests,Code-Review .
Les formats actuellement pris en charge sont default (text) et json .
Ceux-ci peuvent être spécifiés avec l'indicateur --format . Par exemple, --format=json .
Les vérifications suivantes sont toutes exécutées par défaut sur le projet cible :
| Nom | Description | Niveau de risque | Jeton requis | Prise en charge de GitLab | Note |
|---|---|---|---|---|---|
| Artefacts binaires | Le projet est-il exempt de binaires enregistrés ? | Haut | PAT, GITHUB_TOKEN | Soutenu | |
| Protection des branches | Le projet utilise-t-il Branch Protection ? | Haut | PAT ( repo ou repo> public_repo ), GITHUB_TOKEN | Pris en charge (voir notes) | certains paramètres ne sont pris en charge qu'avec un PAT du responsable |
| Tests CI | Le projet exécute-t-il des tests dans CI, par exemple GitHub Actions, Prow ? | Faible | PAT, GITHUB_TOKEN | Soutenu | |
| CII-Bonnes-Pratiques | Le projet a-t-il obtenu un badge de bonnes pratiques OpenSSF (anciennement CII) au niveau réussite, argent ou or ? | Faible | PAT, GITHUB_TOKEN | Validation | |
| Révision du code | Le code des pratiques du projet est-il révisé avant la fusion du code ? | Haut | PAT, GITHUB_TOKEN | Validation | |
| Contributeurs | Le projet compte-t-il des contributeurs d'au moins deux organisations différentes ? | Faible | PAT, GITHUB_TOKEN | Validation | |
| Flux de travail dangereux | Le projet évite-t-il les modèles de codage dangereux dans les workflows GitHub Action ? | Critique | PAT, GITHUB_TOKEN | Non pris en charge | |
| Outil de mise à jour des dépendances | Le projet utilise-t-il des outils pour aider à mettre à jour ses dépendances ? | Haut | PAT, GITHUB_TOKEN | Non pris en charge | |
| Fuzzing | Le projet utilise-t-il des outils de fuzzing, par exemple OSS-Fuzz, QuickCheck ou fast-check ? | Moyen | PAT, GITHUB_TOKEN | Validation | |
| Licence | Le projet déclare-t-il une licence ? | Faible | PAT, GITHUB_TOKEN | Validation | |
| Maintenu | Le projet a-t-il au moins 90 jours et est-il maintenu ? | Haut | PAT, GITHUB_TOKEN | Validation | |
| Dépendances épinglées | Le projet déclare-t-il et épingle-t-il les dépendances ? | Moyen | PAT, GITHUB_TOKEN | Validation | |
| Conditionnement | Le projet crée-t-il et publie-t-il des packages officiels à partir de CI/CD, par exemple GitHub Publishing ? | Moyen | PAT, GITHUB_TOKEN | Validation | |
| SAST | Le projet utilise-t-il des outils d'analyse de code statique, par exemple CodeQL, LGTM (obsolète), SonarCloud ? | Moyen | PAT, GITHUB_TOKEN | Non pris en charge | |
| Politique de sécurité | Le projet contient-il une politique de sécurité ? | Moyen | PAT, GITHUB_TOKEN | Validation | |
| Communiqués signés | Le projet signe-t-il les versions de manière cryptographique ? | Haut | PAT, GITHUB_TOKEN | Validation | |
| Autorisations de jeton | Le projet déclare-t-il les jetons de workflow GitHub en lecture seule ? | Haut | PAT, GITHUB_TOKEN | Non pris en charge | |
| Vulnérabilités | Le projet présente-t-il des vulnérabilités non corrigées ? Utilise le service OSV. | Haut | PAT, GITHUB_TOKEN | Validation | |
| Webhooks | Le webhook défini dans le référentiel dispose-t-il d'un token configuré pour authentifier l'origine des requêtes ? | Critique | responsable PAT ( admin: repo_hook ou admin> read:repo_hook doc | EXPÉRIMENTAL |
Pour voir des informations détaillées sur chaque contrôle, ses critères de notation et les étapes de correction, consultez la page de documentation des contrôles.
Pour un guide des contrôles que vous devez utiliser pour commencer, consultez le guide du débutant sur les contrôles de carte de score.
L'authentification à deux facteurs (2FA) ajoute une couche de sécurité supplémentaire lors de la connexion à des sites Web ou à des applications. 2FA protège votre compte si votre mot de passe est compromis en exigeant une deuxième forme d'authentification, comme des codes envoyés par SMS ou une application d'authentification, ou en touchant une clé de sécurité physique.
Nous vous recommandons fortement d'activer 2FA sur tous les comptes importants où il est disponible. 2FA n’est pas une vérification Scorecard car GitHub et GitLab ne rendent pas publiques ces données sur les comptes d’utilisateurs. On peut soutenir que ces données devraient toujours rester privées, car les comptes sans 2FA sont très vulnérables aux attaques.
Bien qu'il ne s'agisse pas d'un contrôle officiel, nous exhortons tous les responsables de projets à activer 2FA pour protéger leurs projets contre toute compromission.
Suivez les étapes décrites dans Configuration de l'authentification à deux facteurs
Si possible, utilisez soit :
En dernière option, utilisez les SMS. Attention : 2FA utilisant SMS est vulnérable aux attaques par échange de carte SIM.
Chaque contrôle individuel renvoie un score de 0 à 10, 10 représentant le meilleur score possible. Scorecard produit également un score global, qui est une moyenne pondérée des contrôles individuels pondérée par le risque.
Consultez la liste des contrôles Scorecard actuels pour le niveau de risque de chaque contrôle.
Si vous rencontrez ce qui ressemble à un bug, veuillez utiliser le système de suivi des problèmes GitHub. Avant de déposer un problème, veuillez rechercher les problèmes existants pour voir si votre problème est déjà couvert.
Avant de contribuer, veuillez suivre notre code de conduite.
Consultez la documentation de contribution pour savoir comment contribuer au projet.
Si vous souhaitez ajouter un chèque, veuillez consulter les instructions ici.
Si vous souhaitez vous impliquer dans la communauté Scorecard ou si vous avez des idées dont vous aimeriez discuter, nous discutons de ce projet lors des réunions du groupe de travail sur les meilleures pratiques d'OSSF.
| Artefact | Lien |
|---|---|
| Forum des développeurs de cartes de pointage | ossf-scorecard-dev@ |
| Forum d'annonces de cartes de pointage | ossf-scorecard-announce@ |
| Réunion communautaire VC | Lien vers la réunion Zoom |
| Calendrier des réunions communautaires | Tous les jeudis de 13h00 à 14h00, Pacifique (calendrier public OSSF) Appel vidéo : zoom LFX Compatible EMEA Tous les 4 lundis de 7h00 à 8h00 Pacifique (calendrier public OSSF) Appel vidéo : zoom LFX |
| Notes de réunion | Remarques |
| Chaîne Slack | #carte de pointage |
Les responsables sont répertoriés dans le fichier CODEOWNERS.
Pour signaler un problème de sécurité, veuillez suivre les instructions ici.
Tous les jeudis de 13h00 à 14h00, Pacifique (calendrier public OSSF)
Appel vidéo : zoom LFX
Compatible EMEA Tous les 4 lundis de 7h00 à 8h00 Pacifique (calendrier public OSSF)
Appel vidéo : zoom LFX
Vous pouvez consulter l'ordre du jour et les notes de réunion ici.
Consultez la FAQ pour obtenir les réponses aux questions fréquemment posées sur Scorecard.
