scorecard
v5.0.0
Criamos o Scorecard para ajudar os mantenedores de código aberto a melhorar suas práticas recomendadas de segurança e para ajudar os consumidores de código aberto a avaliar se suas dependências são seguras.
Scorecard é uma ferramenta automatizada que avalia uma série de heurísticas importantes ("verificações") associadas à segurança de software e atribui a cada verificação uma pontuação de 0 a 10. Você pode usar essas pontuações para compreender áreas específicas que precisam ser melhoradas para fortalecer a postura de segurança do seu projeto. Você também pode avaliar os riscos que as dependências apresentam e tomar decisões informadas sobre como aceitar esses riscos, avaliar soluções alternativas ou trabalhar com os mantenedores para fazer melhorias.
A inspiração para o logotipo do Scorecard: "Você passou! Todos os D's... e um A!"
Automatize análises e decisões confiáveis sobre a postura de segurança de projetos de código aberto.
Use esses dados para melhorar proativamente a postura de segurança dos projetos críticos dos quais o mundo depende.
Atuar como uma ferramenta de medição para políticas existentes
Se os consumidores de OSS exigirem determinados comportamentos de suas dependências, o Scorecard poderá ser usado para medi-los. Com a versão V5, vemos os Resultados Estruturados como uma forma de fazer isso se houver uma análise suportada. Em vez de confiar em uma pontuação agregada de X/10 ou em uma pontuação mantida de Y/10, um consumidor de OSS pode querer garantir que o repositório do qual depende não seja arquivado (o que é coberto pela investigação archived ). O OpenSSF adota essa abordagem com sua própria linha de base de segurança para projetos.
Ser um relatório ou requisito definitivo que todos os projetos devem seguir.
O Scorecard não pretende ser uma solução única para todos. Cada etapa da produção de nossos resultados é opinativa: quais verificações são incluídas ou excluídas, a importância de cada verificação e como as pontuações são calculadas. As verificações em si são heurísticas; existem falsos positivos e falsos negativos.
Seja por questão de aplicabilidade, ou viabilidade, ou por uma questão de opinião, o que é incluído ou excluído dos resultados do Scorecard gera muita discussão. É impossível criar um Scorecard que satisfaça a todos porque diferentes públicos se preocuparão com diferentes subconjuntos de comportamento.
As pontuações agregadas, em particular, não informam nada sobre quais comportamentos individuais um repositório está ou não realizando. Muitas pontuações de verificação são agregadas em uma única pontuação e há várias maneiras de chegar à mesma pontuação. Essas pontuações mudam à medida que adicionamos novas heurísticas ou refinamos as existentes.
O Scorecard foi executado em milhares de projetos para monitorar e rastrear métricas de segurança. Projetos proeminentes que usam o Scorecard incluem:
Para ver as pontuações dos projetos verificados regularmente pelo Scorecard, navegue até o webviewer. Você também pode substituir o texto do espaço reservado (plataforma, usuário/org e nome do repositório) no link do modelo a seguir para gerar um link de Scorecard customizado para um repositório: https://scorecard.dev/viewer/?uri=<github_or_gitlab>.com/<user_name_or_org>/<repository_name>
Por exemplo:
Para visualizar pontuações de projetos não incluídos no webviewer, use a CLI do Scorecard.
Executamos uma verificação semanal do Scorecard dos 1 milhão de projetos de código aberto mais críticos, avaliados por suas dependências diretas, e publicamos os resultados em um conjunto de dados público do BigQuery.
Esses dados estão disponíveis no conjunto de dados público do BigQuery openssf:scorecardcron.scorecard-v2 . Os resultados mais recentes estão disponíveis na visualização do BigQuery openssf:scorecardcron.scorecard-v2_latest .
Você pode consultar os dados usando o BigQuery Explorer navegando até Adicionar dados > Marcar um projeto com estrela por nome > 'openssf'. Por exemplo, você pode estar interessado em saber como a pontuação de um projeto mudou ao longo do tempo:
SELECT date , score FROM ` openssf.scorecardcron.scorecard-v2 ` WHERE repo . name = " github.com/ossf/scorecard " ORDER BY date ASC Você pode extrair os resultados mais recentes para o armazenamento do Google Cloud em formato JSON usando a ferramenta 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
A lista de projetos verificados está disponível no arquivo cron/internal/data/projects.csv neste repositório. Se você quiser que rastreemos mais, sinta-se à vontade para enviar uma solicitação pull com outras pessoas. Atualmente, esta lista é derivada SOMENTE de projetos hospedados no GitHub . Planejamos expandi-los em um futuro próximo para dar conta de projetos hospedados em outros sistemas de controle de origem.
A maneira mais fácil de usar o Scorecard em projetos GitHub que você possui é com o Scorecard GitHub Action. A Action é executada em qualquer alteração no repositório e emite alertas que os mantenedores podem visualizar na guia Segurança do repositório. Para obter mais informações, consulte as instruções de instalação do Scorecard GitHub Action.
Para consultar pontuações pré-calculadas de projetos OSS, use a API REST.
Para permitir que seu projeto esteja disponível na API REST, defina publish_results: true na configuração Scorecard GitHub Action.
Os dados fornecidos pela API REST são licenciados sob o CDLA Permissive 2.0.
publish_results: true no Scorecard GitHub Actions também permite que os mantenedores exibam um emblema do Scorecard em seu repositório para mostrar seu trabalho árduo. Este emblema também é atualizado automaticamente para cada alteração feita no repositório. Veja mais detalhes nesta postagem do blog OSSF.
Para incluir um emblema no repositório do seu projeto, basta adicionar o seguinte markdown ao seu README:
[](https://scorecard.dev/viewer/?uri=github.com/{owner}/{repo})
Para executar uma varredura do Scorecard em projetos que não são de sua propriedade, use a opção de instalação da interface da linha de comandos.
Plataformas: Atualmente, o Scorecard suporta plataformas OSX e Linux. Se você estiver usando um sistema operacional Windows, poderá ter problemas. Contribuições para suporte ao Windows são bem-vindas.
Idioma: Você deve ter o GoLang instalado para executar o Scorecard (https://golang.org/doc/install)
scorecard está disponível como um contêiner Docker:
docker pull gcr.io/openssf/scorecard:stablePara usar uma versão específica do scorecard (por exemplo, v3.2.1), execute:
docker pull gcr.io/openssf/scorecard:v3.2.1Para instalar o Scorecard como independente:
Visite nossa página de lançamento mais recente e baixe o arquivo zip correto para o seu sistema operacional.
Adicione o binário ao seu diretório GOPATH/bin (use go env GOPATH para identificar seu diretório, se necessário).
Geramos assinaturas SLSA3 usando o slsa-framework/slsa-github-generator do OpenSSF durante o processo de lançamento. Para verificar um binário de lançamento:
attestation.intoto.jsonl na página de lançamentos do GitHub.slsa-verifier -artifact-path < the-zip > -provenance attestation.intoto.jsonl -source github.com/ossf/scorecard -tag < the-tag > | Gerenciador de pacotes | Distribuição Suportada | Comando |
|---|---|---|
| Nix | NixOS | nix-shell -p nixpkgs.scorecard |
| Ajudante AUR | Arco Linux | Use seu auxiliar AUR para instalar scorecard |
| Cerveja caseira | macOS ou Linux | brew install scorecard |
GitHub impõe limites de taxa de API em solicitações não autenticadas. Para evitar esses limites, você deve autenticar suas solicitações antes de executar o Scorecard. Há duas maneiras de autenticar suas solicitações: criar um token de acesso pessoal do GitHub ou criar uma instalação do aplicativo GitHub.
public_repo . Defina o token em uma variável de ambiente chamada GITHUB_AUTH_TOKEN , GITHUB_TOKEN , GH_AUTH_TOKEN ou GH_TOKEN usando os comandos abaixo de acordo com sua plataforma. # 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 ) mostrados acima para sua plataforma. GITHUB_APP_KEY_PATH=<path to the key file on disk>
GITHUB_APP_INSTALLATION_ID=<installation id>
GITHUB_APP_ID=<app id>
Essas variáveis podem ser obtidas na página de configurações do desenvolvedor GitHub.
O Scorecard pode ser executado usando apenas um argumento, a URL do repositório de destino:
$ 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 |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- | O GITHUB_AUTH_TOKEN deve ser definido como um token válido
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:stable --show-details --repo=https://github.com/ossf/scorecardPara usar uma versão específica do scorecard (por exemplo, v3.2.1), execute:
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:v3.2.1 --show-details --repo=https://github.com/ossf/scorecard Para obter mais detalhes sobre por que uma verificação falha, use a opção --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' | |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
As Anotações do Mantenedor permitem que os mantenedores adicionem contexto para exibição junto com os resultados da verificação do Scorecard. As anotações podem fornecer informações adicionais aos usuários quando o Scorecard tiver uma avaliação incompleta das práticas de segurança de um projeto. Para ver as anotações dos mantenedores para cada verificação, use a opção --show-annotations .
Para obter mais informações sobre as anotações disponíveis ou como fazer anotações, consulte o documento de configuração.
Para executar o Scorecard em um repositório GitLab, você deve criar um token de acesso GitLab com as seguintes permissões:
read_apiread_userread_repository Você pode executar o Scorecard em um repositório GitLab definindo a variável de ambiente GITLAB_AUTH_TOKEN :
export GITLAB_AUTH_TOKEN=glpat-xxxx
scorecard --repo gitlab.com/ < org > / < project > / < subproject >Para obter um exemplo de uso do Scorecard no GitLab CI/CD, veja aqui.
Embora nos concentremos no suporte do GitLab.com, o Scorecard também funciona com instalações auto-hospedadas do GitLab. Se sua plataforma estiver hospedada em um subdomínio (por exemplo, gitlab.foo.com ), o Scorecard deverá funcionar imediatamente. Se sua plataforma estiver hospedada em algum slug (por exemplo, foo.com/bar/ ), você precisará definir a variável de ambiente GL_HOST .
export GITLAB_AUTH_TOKEN=glpat-xxxx
export GL_HOST=foo.com/bar
scorecard --repo foo.com/bar/ < org > / < project > Para usar um host do GitHub Enterprise github.corp.com , use a variável de ambiente 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 Para projetos nos ecossistemas --npm , --pypi , --rubygems ou --nuget , você tem a opção de executar o Scorecard usando um gerenciador de pacotes. Forneça o nome do pacote para executar as verificações no código-fonte GitHub correspondente.
Por exemplo, --npm=angular .
Para executar apenas verificações específicas, adicione o argumento --checks com uma lista de nomes de verificações.
Por exemplo, --checks=CI-Tests,Code-Review .
Os formatos atualmente suportados são default (texto) e json .
Eles podem ser especificados com o sinalizador --format . Por exemplo, --format=json .
As verificações a seguir são executadas no projeto de destino por padrão:
| Nome | Descrição | Nível de risco | Token obrigatório | Suporte GitLab | Observação |
|---|---|---|---|---|---|
| Artefatos Binários | O projeto está livre de binários com check-in? | Alto | PAT, GITHUB_TOKEN | Suportado | |
| Proteção de Filial | O projeto utiliza proteção de filiais? | Alto | PAT ( repo ou repo> public_repo ), GITHUB_TOKEN | Suportado (ver notas) | certas configurações são suportadas apenas com um PAT do mantenedor |
| Testes CI | O projeto executa testes em CI, por exemplo, GitHub Actions, Prow? | Baixo | PAT, GITHUB_TOKEN | Suportado | |
| CII-Melhores Práticas | O projeto ganhou um emblema de práticas recomendadas do OpenSSF (anteriormente CII) nos níveis de aprovação, prata ou ouro? | Baixo | PAT, GITHUB_TOKEN | Validando | |
| Revisão de código | O projeto pratica a revisão do código antes da mesclagem do código? | Alto | PAT, GITHUB_TOKEN | Validando | |
| Colaboradores | O projeto conta com colaboradores de pelo menos duas organizações diferentes? | Baixo | PAT, GITHUB_TOKEN | Validando | |
| Fluxo de trabalho perigoso | O projeto evita padrões de codificação perigosos nos fluxos de trabalho do GitHub Action? | Crítico | PAT, GITHUB_TOKEN | Não compatível | |
| Ferramenta de atualização de dependência | O projeto utiliza ferramentas para ajudar a atualizar suas dependências? | Alto | PAT, GITHUB_TOKEN | Não compatível | |
| Confuso | O projeto utiliza ferramentas de difusão, por exemplo, OSS-Fuzz, QuickCheck ou fast-check? | Médio | PAT, GITHUB_TOKEN | Validando | |
| Licença | O projeto declara uma licença? | Baixo | PAT, GITHUB_TOKEN | Validando | |
| Mantido | O projeto tem pelo menos 90 dias e é mantido? | Alto | PAT, GITHUB_TOKEN | Validando | |
| Dependências Fixadas | O projeto declara e fixa dependências? | Médio | PAT, GITHUB_TOKEN | Validando | |
| Embalagem | O projeto constrói e publica pacotes oficiais de CI/CD, por exemplo, GitHub Publishing? | Médio | PAT, GITHUB_TOKEN | Validando | |
| SAST | O projeto usa ferramentas de análise de código estático, por exemplo, CodeQL, LGTM (obsoleto), SonarCloud? | Médio | PAT, GITHUB_TOKEN | Não compatível | |
| Política de Segurança | O projeto contém uma política de segurança? | Médio | PAT, GITHUB_TOKEN | Validando | |
| Liberações assinadas | O projeto assina liberações criptograficamente? | Alto | PAT, GITHUB_TOKEN | Validando | |
| Permissões de token | O projeto declara tokens de fluxo de trabalho do GitHub como somente leitura? | Alto | PAT, GITHUB_TOKEN | Não compatível | |
| Vulnerabilidades | O projeto possui vulnerabilidades não corrigidas? Usa o serviço OSV. | Alto | PAT, GITHUB_TOKEN | Validando | |
| Webhooks | O webhook definido no repositório possui um token configurado para autenticar as origens das solicitações? | Crítico | mantenedor PAT ( admin: repo_hook ou admin> read:repo_hook doc | EXPERIMENTAL |
Para ver informações detalhadas sobre cada verificação, seus critérios de pontuação e etapas de correção, confira a página de documentação das verificações.
Para obter um guia sobre as verificações que você deve usar ao começar, consulte o guia para iniciantes em verificações de scorecard.
A autenticação de dois fatores (2FA) adiciona uma camada extra de segurança ao fazer login em sites ou aplicativos. O 2FA protege sua conta se sua senha for comprometida, exigindo uma segunda forma de autenticação, como códigos enviados via SMS ou aplicativo de autenticação, ou tocando em uma chave de segurança física.
Recomendamos fortemente que você habilite o 2FA em todas as contas importantes onde estiver disponível. 2FA não é uma verificação de Scorecard porque GitHub e GitLab não tornam públicos esses dados sobre contas de usuários. Indiscutivelmente, estes dados devem sempre permanecer privados, uma vez que contas sem 2FA são muito vulneráveis a ataques.
Embora não seja uma verificação oficial, pedimos a todos os mantenedores do projeto que permitam que o 2FA proteja seus projetos contra comprometimentos.
Siga as etapas descritas em Configurando a autenticação de dois fatores
Se possível, use:
Como última opção, use SMS. Cuidado: 2FA usando SMS é vulnerável a ataques de troca de SIM.
Cada verificação individual retorna uma pontuação de 0 a 10, com 10 representando a melhor pontuação possível. O Scorecard também produz uma pontuação agregada, que é uma média baseada no peso das verificações individuais ponderadas pelo risco.
Veja a lista de verificações atuais do Scorecard para cada nível de risco de verificação.
Se você tiver o que parece ser um bug, use o sistema de rastreamento de problemas do GitHub. Antes de registrar um problema, pesquise os problemas existentes para ver se ele já foi resolvido.
Antes de contribuir, siga nosso Código de Conduta.
Consulte a documentação de contribuição para obter orientação sobre como contribuir para o projeto.
Se desejar adicionar um cheque, consulte as orientações aqui.
Se você quiser se envolver na comunidade do Scorecard ou tiver ideias sobre as quais gostaria de conversar, discutiremos esse projeto nas reuniões do Grupo de Trabalho de Melhores Práticas da OSSF.
| Artefato | Link |
|---|---|
| Fórum de desenvolvimento de scorecard | ossf-scorecard-dev@ |
| Fórum de anúncios de scorecard | ossf-scorecard-anunciar@ |
| VC de reunião comunitária | Link para zoom da reunião |
| Calendário de reuniões comunitárias | Quinzenalmente compatível com a APAC, às quintas-feiras, das 13h às 14h, Pacífico (Calendário Público OSSF) Chamada de vídeo: Zoom LFX Compatível com EMEA Todas as 4 segundas-feiras, das 7h às 8h, Pacífico (calendário público OSSF) Chamada de vídeo: Zoom LFX |
| Notas de reunião | Notas |
| Canal Slack | #scorecard |
Os mantenedores estão listados no arquivo CODEOWNERS.
Para relatar um problema de segurança, siga as instruções aqui.
Quinzenalmente compatível com a APAC, às quintas-feiras, das 13h às 14h, Pacífico (Calendário Público OSSF)
Chamada de vídeo: zoom LFX
Compatível com EMEA Todas as 4 segundas-feiras, das 7h às 8h, Pacífico (calendário público OSSF)
Chamada de vídeo: zoom LFX
Você pode ver a agenda e as notas da reunião aqui.
Consulte o FAQ para obter respostas às perguntas frequentes sobre o Scorecard.
