ES
Empezar prueba de 30 días

Documentación de Guardrail Ledger

Conecte su pipeline

Los escáneres se ejecutan en sus agentes o runners. La tarea o la Action recoge su SARIF, lo envía a su espacio de trabajo y lee el resultado de la puerta.

1. Generar un token de ingesta

Un propietario o administrador abre la página Pipeline, introduce un nombre de token y elige Generar token de ingesta. El token se muestra una sola vez. Guárdelo como la variable secreta GUARDRAIL_TOKEN en Azure Pipelines, o como el secreto de repositorio GUARDRAIL_INGEST_TOKEN en GitHub.

2. Instalar los cuatro escáneres

Trivy, Gitleaks, Checkov y Opengrep deben estar en el PATH del agente o runner. La tarea no los instala.

3a. Azure DevOps

  1. En la página Pipeline, introduzca el nombre de su organización de Azure DevOps (el nombre en dev.azure.com/<organisation>) y elija Compartir la extensión con esta organización.
  2. Abra el enlace del Marketplace que aparece allí, elija Obtener gratis y seleccione la organización. Para instalarla se necesita permiso para gestionar extensiones en esa organización. Mientras la extensión no se comparta, el enlace no se muestra.
  3. Añada el paso a azure-pipelines.yml y ejecute el pipeline en los pull requests.
- task: GuardrailLedgerScan@0
  inputs:
    guardrailUrl: 'https://<workspace>.guardrail-ledger.com'
    ingestToken: '$(GUARDRAIL_TOKEN)'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

La línea env permite que la tarea comente el resultado de la puerta en el pull request. La identidad del servicio de compilación del proyecto también necesita el permiso Contribute to pull requests en el repositorio.

3b. GitHub Actions

  1. En la página Pipeline, descargue action.yml e index.js. Confírmelos como .github/actions/guardrail-ledger/action.yml y .github/actions/guardrail-ledger/dist/index.js.
  2. Añada el workflow que muestra la página Pipeline. Instala los escáneres y después ejecuta la Action con la dirección de su espacio de trabajo y el secreto GUARDRAIL_INGEST_TOKEN.
  3. Ejecute el escaneo en pull requests de ramas del propio repositorio. En los forks, GitHub no da secretos al job.

El job necesita estos permisos para que la Action pueda leer el código y comentar en el pull request:

permissions:
  contents: read
  pull-requests: write

Cualquier otro CI

Cualquier CI que escriba SARIF puede enviarlo a su espacio de trabajo. El cuerpo es JSON con repo y sarif, y el token va en una cabecera Bearer.

curl -sS -X POST 'https://<workspace>.guardrail-ledger.com/api/v1/ingest/sarif' \
  -H "Authorization: Bearer $GUARDRAIL_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"repo":"example-repo","sarif":{"version":"2.1.0","runs":[...]}}'

Cuando falla un escáner

El paso falla, y nombra el escáner, cuando un escáner falta, se bloquea, termina con un error o no escribe un SARIF utilizable. En ese caso no se envía nada. Para continuar con los demás escáneres, establezca allowMissingScanners: true en la tarea de Azure DevOps, o allow-missing-scanners: true en la Action. La ejecución se envía entonces como incompleta, de modo que no se resuelve ningún hallazgo con ella y la puerta no se supera con lo que falta.

Qué se envía

La tarea envía los resultados SARIF de los escáneres, el nombre del repositorio, el commit, el número del pull request, el login de la persona que ejecutó la compilación y las rutas de los archivos de herramientas de IA como AGENTS.md o mcp.json. Elimina los fragmentos de código y las líneas de contexto del SARIF antes de enviarlo. No sube el repositorio. La salida de los escáneres se escribe en el directorio temporal del agente, fuera de las fuentes, y se elimina después de leerse.