Creamos Scorecard para ayudar a los mantenedores de código abierto a mejorar sus mejores prácticas de seguridad y para ayudar a los consumidores de código abierto a juzgar si sus dependencias son seguras.
Scorecard es una herramienta automatizada que evalúa una serie de heurísticas importantes ("verificaciones") asociadas con la seguridad del software y asigna a cada verificación una puntuación de 0 a 10. Puede utilizar estos puntajes para comprender áreas específicas que deben mejorarse para fortalecer la postura de seguridad de su proyecto. También puede evaluar los riesgos que introducen las dependencias y tomar decisiones informadas sobre cómo aceptar estos riesgos, evaluar soluciones alternativas o trabajar con los mantenedores para realizar mejoras.
La inspiración para el logo de Scorecard: "¡Aprobaste! Todas las D... ¡y una A!"
Automatice el análisis y las decisiones de confianza sobre la postura de seguridad de los proyectos de código abierto.
Utilice estos datos para mejorar de forma proactiva la postura de seguridad de los proyectos críticos de los que depende el mundo.
Actuar como herramienta de medición de las políticas existentes.
Si los consumidores de OSS requieren ciertos comportamientos de sus dependencias, se puede utilizar Scorecard para medirlos. Con la versión V5, vemos resultados estructurados como una forma de hacerlo si hay un análisis compatible. En lugar de depender de una puntuación agregada de X/10 o una puntuación mantenida de Y/10, un consumidor de OSS puede querer asegurarse de que el repositorio del que depende no esté archivado (lo cual está cubierto por la sonda archived
). OpenSSF adopta este enfoque con su propia línea de base de seguridad para proyectos.
Ser un informe definitivo o requisito que todos los proyectos deben seguir.
El cuadro de mando no pretende ser una solución única para todos. Cada paso para generar nuestros resultados está basado en opiniones: qué controles se incluyen o excluyen, la importancia de cada control y cómo se calculan las puntuaciones. Las comprobaciones en sí son heurísticas; hay falsos positivos y falsos negativos.
Ya sea por aplicabilidad, viabilidad o una cuestión de opinión, lo que se incluye o excluye en los resultados del cuadro de mando genera mucha discusión. Es imposible crear un cuadro de mando que satisfaga a todos porque diferentes audiencias se preocuparán por diferentes subconjuntos de comportamiento.
Las puntuaciones agregadas en particular no dicen nada sobre qué comportamientos individuales está o no está haciendo un repositorio. Muchas puntuaciones de verificación se agregan en una sola puntuación y hay varias formas de llegar a la misma puntuación. Estas puntuaciones cambian a medida que agregamos nuevas heurísticas o refinamos las existentes.
Scorecard se ha ejecutado en miles de proyectos para monitorear y rastrear métricas de seguridad. Los proyectos destacados que utilizan Scorecard incluyen:
Para ver las puntuaciones de los proyectos escaneados periódicamente por Scorecard, navegue hasta el visor web. También puede reemplazar el texto del marcador de posición (plataforma, usuario/organización y nombre del repositorio) en el siguiente enlace de plantilla para generar un enlace de cuadro de mando personalizado para un repositorio: https://scorecard.dev/viewer/?uri=<github_or_gitlab>.com/<user_name_or_org>/<repository_name>
Por ejemplo:
Para ver puntuaciones de proyectos no incluidos en el visor web, utilice la CLI de Scorecard.
Realizamos un escaneo semanal del cuadro de mando del millón de proyectos de código abierto más críticos juzgados por sus dependencias directas y publicamos los resultados en un conjunto de datos públicos de BigQuery.
Estos datos están disponibles en el conjunto de datos público de BigQuery openssf:scorecardcron.scorecard-v2
. Los resultados más recientes están disponibles en la vista de BigQuery openssf:scorecardcron.scorecard-v2_latest
.
Puedes consultar los datos usando BigQuery Explorer navegando a Agregar datos > Destacar un proyecto por nombre > 'openssf'. Por ejemplo, es posible que le interese saber cómo ha cambiado la puntuación de un proyecto con el tiempo:
SELECT date , score FROM ` openssf.scorecardcron.scorecard-v2 ` WHERE repo . name = " github.com/ossf/scorecard " ORDER BY date ASC
Puedes extraer los últimos resultados al almacenamiento de Google Cloud en formato JSON utilizando la herramienta 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 lista de proyectos marcados está disponible en el archivo cron/internal/data/projects.csv
de este repositorio. Si desea que realicemos un seguimiento de más, no dude en enviar una solicitud de extracción con otras personas. Actualmente, esta lista se deriva de proyectos alojados en GitHub SOLAMENTE . Planeamos expandirlos en un futuro próximo para dar cuenta de proyectos alojados en otros sistemas de control de fuente.
La forma más sencilla de utilizar Scorecard en proyectos de GitHub de su propiedad es con Scorecard GitHub Action. La acción se ejecuta en cualquier cambio en el repositorio y emite alertas que los mantenedores pueden ver en la pestaña Seguridad del repositorio. Para obtener más información, consulte las instrucciones de instalación de Scorecard GitHub Action.
Para consultar puntuaciones precalculadas de proyectos OSS, utilice la API REST.
Para permitir que su proyecto esté disponible en la API REST, establezca publish_results: true
en la configuración de Acción de GitHub del cuadro de mando.
Los datos proporcionados por la API REST tienen licencia CDLA Permissive 2.0.
Habilitar publish_results: true
en Scorecard GitHub Actions también permite a los mantenedores mostrar una insignia de Scorecard en su repositorio para mostrar su arduo trabajo. Esta insignia también se actualiza automáticamente con cada cambio realizado en el repositorio. Vea más detalles en esta publicación de blog de OSSF.
Para incluir una insignia en el repositorio de su proyecto, simplemente agregue el siguiente descuento a su README:
[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/{owner}/{repo}/badge)](https://scorecard.dev/viewer/?uri=github.com/{owner}/{repo})
Para ejecutar un análisis de Scorecard en proyectos que no le pertenecen, utilice la opción de instalación de la interfaz de línea de comandos.
Plataformas: Actualmente, Scorecard es compatible con las plataformas OSX y Linux. Si está utilizando un sistema operativo Windows, puede experimentar problemas. Las contribuciones para el soporte de Windows son bienvenidas.
Idioma: Debe tener GoLang instalado para ejecutar Scorecard (https://golang.org/doc/install)
scorecard
está disponible como contenedor Docker:
docker pull gcr.io/openssf/scorecard:stable
Para utilizar una versión específica del cuadro de mando (por ejemplo, v3.2.1), ejecute:
docker pull gcr.io/openssf/scorecard:v3.2.1
Para instalar Scorecard de forma independiente:
Visite nuestra página de la última versión y descargue el archivo zip correcto para su sistema operativo.
Agregue el binario a su directorio GOPATH/bin
(use go env GOPATH
para identificar su directorio si es necesario).
Generamos firmas SLSA3 utilizando slsa-framework/slsa-github-generator de OpenSSF durante el proceso de lanzamiento. Para verificar un binario de versión:
attestation.intoto.jsonl
desde la página de lanzamientos de GitHub.slsa-verifier -artifact-path < the-zip > -provenance attestation.intoto.jsonl -source github.com/ossf/scorecard -tag < the-tag >
Administrador de paquetes | Distribución admitida | Dominio |
---|---|---|
Nada | NixOS | nix-shell -p nixpkgs.scorecard |
ayudante AUR | Arco Linux | Utilice su ayudante AUR para instalar scorecard |
cerveza casera | macOS o Linux | brew install scorecard |
GitHub impone límites de tasa de API a solicitudes no autenticadas. Para evitar estos límites, debe autenticar sus solicitudes antes de ejecutar Scorecard. Hay dos formas de autenticar sus solicitudes: crear un token de acceso personal de GitHub o crear una instalación de aplicación GitHub.
public_repo
. Configure el token en una variable de entorno llamada GITHUB_AUTH_TOKEN
, GITHUB_TOKEN
, GH_AUTH_TOKEN
o GH_TOKEN
usando los siguientes comandos según su 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>
O
set
o export
) que se muestran arriba para su plataforma. GITHUB_APP_KEY_PATH=<path to the key file on disk>
GITHUB_APP_INSTALLATION_ID=<installation id>
GITHUB_APP_ID=<app id>
Estas variables se pueden obtener desde la página de configuración del desarrollador de GitHub.
El cuadro de mando se puede ejecutar usando un solo argumento, la URL del repositorio 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 |
| --------- | ------------------------ | -------------------------------- | --------------------------------------------------------------------------- |
El GITHUB_AUTH_TOKEN
debe configurarse como un token válido
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:stable --show-details --repo=https://github.com/ossf/scorecard
Para utilizar una versión específica del cuadro de mando (por ejemplo, v3.2.1), ejecute:
docker run -e GITHUB_AUTH_TOKEN=token gcr.io/openssf/scorecard:v3.2.1 --show-details --repo=https://github.com/ossf/scorecard
Para obtener más detalles sobre por qué falla una verificación, use la opción --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' | |
|---------|------------------------|--------------------------------|--------------------------------|---------------------------------------------------------------------------|
Las anotaciones del mantenedor permiten a los mantenedores agregar contexto para mostrar junto con los resultados de la verificación del cuadro de mando. Las anotaciones pueden proporcionar a los usuarios información adicional cuando Scorecard tiene una evaluación incompleta de las prácticas de seguridad de un proyecto. Para ver las anotaciones de los mantenedores para cada verificación, use la opción --show-annotations
.
Para obtener más información sobre las anotaciones disponibles o cómo realizar anotaciones, consulte el documento de configuración.
Para ejecutar Scorecard en un repositorio de GitLab, debe crear un token de acceso de GitLab con los siguientes permisos:
read_api
read_user
read_repository
Puede ejecutar Scorecard en un repositorio de GitLab configurando la variable de entorno GITLAB_AUTH_TOKEN
:
export GITLAB_AUTH_TOKEN=glpat-xxxx
scorecard --repo gitlab.com/ < org > / < project > / < subproject >
Para ver un ejemplo del uso de Scorecard en GitLab CI/CD, consulte aquí.
Si bien nos centramos en la compatibilidad con GitLab.com, Scorecard también funciona con instalaciones de GitLab autohospedadas. Si su plataforma está alojada en un subdominio (por ejemplo, gitlab.foo.com
), Scorecard debería funcionar de inmediato. Si su plataforma está alojada en algún slug (por ejemplo, foo.com/bar/
), deberá configurar la variable de entorno GL_HOST
.
export GITLAB_AUTH_TOKEN=glpat-xxxx
export GL_HOST=foo.com/bar
scorecard --repo foo.com/bar/ < org > / < project >
Para usar un host de GitHub Enterprise github.corp.com
, use la variable de entorno 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 proyectos en los ecosistemas --npm
, --pypi
, --rubygems
o --nuget
, tiene la opción de ejecutar Scorecard utilizando un administrador de paquetes. Proporcione el nombre del paquete para ejecutar las comprobaciones en el código fuente de GitHub correspondiente.
Por ejemplo, --npm=angular
.
Para ejecutar solo comprobaciones específicas, agregue el argumento --checks
con una lista de nombres de comprobaciones.
Por ejemplo, --checks=CI-Tests,Code-Review
.
Los formatos admitidos actualmente son default
(texto) y json
.
Estos se pueden especificar con el indicador --format
. Por ejemplo, --format=json
.
De forma predeterminada, se ejecutan las siguientes comprobaciones en el proyecto de destino:
Nombre | Descripción | Nivel de riesgo | Token requerido | Soporte GitLab | Nota |
---|---|---|---|---|---|
Artefactos binarios | ¿El proyecto está libre de archivos binarios registrados? | Alto | PAT, GITHUB_TOKEN | Apoyado | |
Protección de sucursales | ¿El proyecto utiliza protección de sucursales? | Alto | PAT ( repo o repo> public_repo ), GITHUB_TOKEN | Compatible (ver notas) | ciertas configuraciones solo son compatibles con una PAT de mantenedor |
Pruebas CI | ¿El proyecto ejecuta pruebas en CI, por ejemplo, GitHub Actions, Prow? | Bajo | PAT, GITHUB_TOKEN | Apoyado | |
CII-Mejores-Prácticas | ¿El proyecto ha obtenido una insignia de mejores prácticas de OpenSSF (anteriormente CII) en el nivel aprobado, plata u oro? | Bajo | PAT, GITHUB_TOKEN | Validando | |
Revisión de código | ¿El proyecto practica la revisión del código antes de fusionarlo? | Alto | PAT, GITHUB_TOKEN | Validando | |
Colaboradores | ¿El proyecto tiene contribuyentes de al menos dos organizaciones diferentes? | Bajo | PAT, GITHUB_TOKEN | Validando | |
Flujo de trabajo peligroso | ¿El proyecto evita patrones de codificación peligrosos en los flujos de trabajo de GitHub Action? | Crítico | PAT, GITHUB_TOKEN | No compatible | |
Herramienta de actualización de dependencia | ¿El proyecto utiliza herramientas para ayudar a actualizar sus dependencias? | Alto | PAT, GITHUB_TOKEN | No compatible | |
Fuzzing | ¿El proyecto utiliza herramientas de fuzzing, por ejemplo OSS-Fuzz, QuickCheck o fast-check? | Medio | PAT, GITHUB_TOKEN | Validando | |
Licencia | ¿El proyecto declara licencia? | Bajo | PAT, GITHUB_TOKEN | Validando | |
mantenido | ¿El proyecto tiene al menos 90 días de antigüedad y se mantiene? | Alto | PAT, GITHUB_TOKEN | Validando | |
Dependencias fijadas | ¿El proyecto declara y fija dependencias? | Medio | PAT, GITHUB_TOKEN | Validando | |
Embalaje | ¿El proyecto crea y publica paquetes oficiales de CI/CD, por ejemplo, GitHub Publishing? | Medio | PAT, GITHUB_TOKEN | Validando | |
SAST | ¿El proyecto utiliza herramientas de análisis de código estático, por ejemplo, CodeQL, LGTM (obsoleto), SonarCloud? | Medio | PAT, GITHUB_TOKEN | No compatible | |
Política de seguridad | ¿El proyecto contiene una política de seguridad? | Medio | PAT, GITHUB_TOKEN | Validando | |
Comunicaciones firmadas | ¿El proyecto firma criptográficamente los comunicados? | Alto | PAT, GITHUB_TOKEN | Validando | |
Permisos de token | ¿El proyecto declara los tokens de flujo de trabajo de GitHub como de solo lectura? | Alto | PAT, GITHUB_TOKEN | No compatible | |
Vulnerabilidades | ¿El proyecto tiene vulnerabilidades no solucionadas? Utiliza el servicio OSV. | Alto | PAT, GITHUB_TOKEN | Validando | |
Ganchos web | ¿El webhook definido en el repositorio tiene un token configurado para autenticar los orígenes de las solicitudes? | Crítico | PAT mantenedor ( admin: repo_hook o admin> read:repo_hook doc | EXPERIMENTAL |
Para ver información detallada sobre cada cheque, sus criterios de puntuación y los pasos de solución, consulte la página de documentación de cheques.
Para obtener una guía sobre las comprobaciones que debe utilizar al comenzar, consulte la guía para principiantes sobre comprobaciones del cuadro de mando.
La autenticación de dos factores (2FA) agrega una capa adicional de seguridad al iniciar sesión en sitios web o aplicaciones. 2FA protege su cuenta si su contraseña se ve comprometida al requerir una segunda forma de autenticación, como códigos enviados por SMS o una aplicación de autenticación, o tocar una llave de seguridad física.
Le recomendamos encarecidamente que habilite 2FA en cualquier cuenta importante donde esté disponible. 2FA no es una verificación de cuadro de mando porque GitHub y GitLab no hacen públicos los datos sobre las cuentas de usuario. Podría decirse que estos datos siempre deberían permanecer privados, ya que las cuentas sin 2FA son muy vulnerables a los ataques.
Aunque no es una verificación oficial, instamos a todos los mantenedores de proyectos a que habiliten 2FA para proteger sus proyectos contra compromisos.
Siga los pasos descritos en Configuración de la autenticación de dos factores
Si es posible, utilice:
Como última opción, utiliza los SMS. Cuidado: 2FA que usa SMS es vulnerable a ataques de intercambio de SIM.
Cada verificación individual arroja una puntuación de 0 a 10, donde 10 representa la mejor puntuación posible. El cuadro de mando también produce una puntuación agregada, que es un promedio basado en el peso de los controles individuales ponderados por riesgo.
Consulte la lista de controles actuales del Cuadro de mando para conocer el nivel de riesgo de cada control.
Si tiene lo que parece un error, utilice el sistema de seguimiento de problemas de GitHub. Antes de presentar un problema, busque los problemas existentes para ver si su problema ya está cubierto.
Antes de contribuir, siga nuestro Código de conducta.
Consulte la documentación de contribución para obtener orientación sobre cómo contribuir al proyecto.
Si desea agregar un cheque, consulte la guía aquí.
Si desea involucrarse en la comunidad de Scorecard o tiene ideas sobre las que le gustaría conversar, discutimos este proyecto en las reuniones del Grupo de Trabajo de Mejores Prácticas de OSSF.
Artefacto | Enlace |
---|---|
Foro de desarrollo de cuadros de mando | ossf-scorecard-dev@ |
Foro de anuncios del cuadro de mando | ossf-scorecard-announce@ |
Reunión comunitaria VC | Enlace a la reunión de zoom |
Calendario de reuniones comunitarias | Quincenal apto para APAC los jueves de 1:00 a 2:00 p. m. Pacífico (calendario público de OSSF) Videollamada: Zoom LFX Apto para EMEA Cada 4 lunes de 7:00 a. m. a 8:00 a. m. hora del Pacífico (calendario público de OSSF) Videollamada: Zoom LFX |
Notas de la reunión | Notas |
Canal flojo | #tanteador |
Los mantenedores se enumeran en el archivo CODEOWNERS.
Para informar un problema de seguridad, siga las instrucciones aquí.
Quincenal apto para APAC los jueves de 1:00 a 2:00 p. m. Pacífico (calendario público de OSSF)
Videollamada: zoom LFX
Apto para EMEA Cada 4 lunes de 7:00 a. m. a 8:00 a. m. hora del Pacífico (calendario público de OSSF)
Videollamada: zoom LFX
Puedes ver la agenda y las notas de la reunión aquí.
Consulte las preguntas frecuentes para obtener respuestas a las preguntas más frecuentes sobre el cuadro de mando.