Skip to main content
Snyk Blog

In this article

Como usar a API da Snyk para encontrar e corrigir vulnerabilidades

Escrito por
Headshot of Josh Emerson

Josh Emerson

3 de janeiro de 2018

0 minutos de leitura
Quebra-cabeça desenhado à mão, com peças estampadas e uma peça preta central com um rosto branco que lembra um animal

Ilustração de Lou Reade.

Neste post, você vai aprender a usar a API da Snyk para recuperar todos os problemas associados a um determinado projeto. Isso pode ser útil por vários motivos, especialmente para incluí-los em relatórios e painéis, dando a gestores e desenvolvedores visibilidade sobre o status das vulnerabilidades nos portais e fluxos de trabalho que já usam.

Nas etapas a seguir, vamos usar a API para:

  • Buscar a lista de organizações às quais você tem acesso

  • Buscar todos os projetos de uma organização

  • Buscar a lista de problemas dos seus projetos

Pré-requisitos

A API da Snyk está disponível para clientes de um dos nossos planos pagos. Para começar a usar a API, faça login ou crie uma conta e obtenha sua chave de API em https://app.snyk.io. Você pode consultar todos os endpoints disponibilizados pela API em https://snyk.docs.apiary.io.

Se ainda não criou projetos, você pode fazer isso executando snyk monitor pela ferramenta de linha de comando da Snyk ou adicionar projetos de várias fontes (como GitHub, GitLab e Heroku) pelo site.

Você também precisa copiar sua chave de API em https://snyk.io/account e usá-la em todos os exemplos abaixo.

Como buscar organizações

O primeiro passo é usar o endpoint de organizações em https://snyk.io/api/v1/orgs.

curl --include \
     --header "Content-Type: application/json; charset=utf-8" \
     --header "Authorization: token <API_KEY>" \
  'https://snyk.io/api/v1/orgs'

Isso retornará uma lista das suas organizações.

{
  "orgs": [
    {
      "name": "defaultOrg",
      "id": "689ce7f9-7943-4a71-b704-2ba575f01089"
    },
    {
      "name": "My Other Org",
      "id": "a04d9cbd-ae6e-44af-b573-0556b0ad4bd2"
    }
  ]
}

Como buscar projetos

Agora, pegue o ID da organização cujos problemas de projeto você quer consultar e use-o no endpoint da API de projetos em https://snyk.io/api/v1/org//projects (substitua pela ID da sua organização).

curl --include \
     --header "Content-Type: application/json" \
     --header "Authorization: token <API_KEY>" \
  'https://snyk.io/api/v1/org/<ORG_ID>/projects'

Isso retornará uma lista dos seus projetos.

{
  "org": {
    "name": "defaultOrg",
    "id": "689ce7f9-7943-4a71-b704-2ba575f01089"
  },
  "projects": [
    {
      "name": "atokeneduser/goof",
      "id": "6d5813be-7e6d-4ab8-80c2-1e3e2a454545"
    },
    {
      "name": "atokeneduser/clojure",
      "id": "af127b96-6966-46c1-826b-2e79ac49bbd9"
    }
  ]
}

Como buscar problemas de projetos

Agora que temos uma lista de projetos, podemos buscar os problemas de qualquer projeto que nos interesse, acessando o endpoint de problemas mostrado abaixo e substituindo pela ID do projeto cujos problemas você quer consultar:

curl --include \
     --request POST \
     --header "Content-Type: application/json" \
     --header "Authorization: token <API_KEY>" \
  'https://snyk.io/api/v1/org/orgId/project/<PROJECT_ID>/aggregated-issues'

Isso retornará uma resposta JSON com um objeto de problemas que contém um array de vulnerabilidades e, se as licenças estiverem habilitadas para sua organização, um array de problemas de licença encontrados no projeto quando o último snapshot foi gerado.

O endpoint da API de problemas de projetos também permite filtrar por tipo de problema (vulnerabilidade ou problema de licença), gravidade (alta, média ou baixa) e por problemas ignorados ou corrigidos. Se quiséssemos ver apenas vulnerabilidades de alta gravidade que não foram corrigidas nem ignoradas, poderíamos fazer a seguinte solicitação:

'https://snyk.io/api/v1/org/orgId/project/<PROJECT_ID>/aggregated-issues'curl --include \
     --request POST \
     --header "Content-Type: application/json" \
     --header "Authorization: token <API_KEY>" \
     --data-binary '{
       "filters": {
        "severities": [ "high" ],
        "types": [ "vuln" ],
        "ignored": false,
        "patched": false
      }
    }' \
  'https://snyk.io/api/v1/org/orgId/project/<PROJECT_ID>/aggregated-issues'

A resposta não incluirá problemas de licença e mostrará apenas vulnerabilidades de alta gravidade que não foram ignoradas nem corrigidas.

Como usar a resposta

Agora que você recuperou os problemas do projeto, terá um payload JSON como este:

{
  "ok": false,
  "issues": {
    "vulnerabilities": [
      {
        "id": "npm:ms:20170412",
        "url": "https://snyk.io/vuln/npm:ms:20170412",
        "title": "Regular Expression Denial of Service (ReDoS)",
        "type": "vuln",
        "description": "## Overview\n[`ms`](https://www.npmjs.com/package/ms) is a tiny millisecond conversion utility.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to an incomplete fix for previously reported vulnerability [npm:ms:20151024](https://snyk.io/vuln/npm:ms:20151024). The fix limited the length of accepted input string to 10,000 characters, and turned to be insufficient making it possible to block the event loop for 0.3 seconds (on a typical laptop) with a specially crafted string passed to `ms()` function.\n\n*Proof of concept*\n```js\nms = require('ms');\nms('1'.repeat(9998) + 'Q') // Takes about ~0.3s\n```\n\n**Note:** Snyk's patch for this vulnerability limits input length to 100 characters. This new limit was deemed to be a breaking change by the author.\nBased on user feedback, we believe the risk of breakage is _very_ low, while the value to your security is much greater, and therefore opted to still capture this change in a patch for earlier versions as well.  Whenever patching security issues, we always suggest to run tests on your code to validate that nothing has been broken.\n\nFor more information on `Regular Expression Denial of Service (ReDoS)` attacks, go to our [blog](https://snyk.io/blog/redos-and-catastrophic-backtracking/).\n\n## Disclosure Timeline\n- Feb 9th, 2017 - Reported the issue to package owner.\n- Feb 11th, 2017 - Issue acknowledged by package owner.\n- April 12th, 2017 - Fix PR opened by Snyk Security Team.\n- May 15th, 2017 - Vulnerability published.\n- May 16th, 2017 - Issue fixed and version `2.0.0` released.\n- May 21th, 2017 - Patches released for versions `>=0.7.1, <=1.0.0`.\n\n## Remediation\nUpgrade `ms` to version 2.0.0 or higher.\n\n## References\n- [GitHub PR](https://github.com/zeit/ms/pull/89)\n- [GitHub Commit](https://github.com/zeit/ms/pull/89/commits/305f2ddcd4eff7cc7c518aca6bb2b2d2daad8fef)\n",
        "from": [
          "mongoose@4.2.4",
          "mquery@1.6.3",
          "debug@2.2.0",
          "ms@0.7.1"
        ],
        "package": "ms",
        "version": "0.7.1",
        "severity": "low",
        "language": "js",
        "packageManager": "npm",
        "semver": {
          "unaffected": ">=2.0.0",
          "vulnerable": "<2.0.0"
        },
        "publicationTime": "2017-05-15T06:02:45.497Z",
        "disclosureTime": "2017-04-11T21:00:00.000Z",
        "isUpgradable": true,
        "isPatchable": true,
        "identifiers": {
          "CVE": [],
          "CWE": [
            "CWE-400"
          ],
          "ALTERNATIVE": [
            "SNYK-JS-MS-10509"
          ]
        },
        "credit": [
          "Snyk Security Research Team"
        ],
        "CVSSv3": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
        "cvssScore": 3.7,
        "patches": [
          {
            "id": "patch:npm:ms:20170412:0",
            "urls": [
              "https://s3.amazonaws.com/snyk-rules-pre-repository/snapshots/develop/patches/npm/ms/20170412/ms_100.patch"
            ],
            "version": "=1.0.0",
            "comments": [],
            "modificationTime": "2017-05-16T10:12:18.990Z"
          },
          {
            "id": "patch:npm:ms:20170412:1",
            "urls": [
              "https://s3.amazonaws.com/snyk-rules-pre-repository/snapshots/develop/patches/npm/ms/20170412/ms_072-073.patch"
            ],
            "version": "=0.7.2 || =0.7.3",
            "comments": [],
            "modificationTime": "2017-05-16T10:12:18.990Z"
          },
          {
            "id": "patch:npm:ms:20170412:2",
            "urls": [
              "https://s3.amazonaws.com/snyk-rules-pre-repository/snapshots/develop/patches/npm/ms/20170412/ms_071.patch"
            ],
            "version": "=0.7.1",
            "comments": [],
            "modificationTime": "2017-05-16T10:12:18.990Z"
          }
        ],
        "isIgnored": true,
        "isPatched": false,
        "upgradePath": [
          "mongoose@4.10.2",
          "mquery@2.3.1",
          "debug@2.6.8",
          "ms@2.0.0"
        ]
      }
    ],
    "licenses": []
  },
  "dependencyCount": 250,
  "packageManager": "npm"
}

Digamos que você queira exibir o nome da vulnerabilidade, o pacote vulnerável e a URL para saber mais sobre cada vulnerabilidade. Usando jq como exemplo, você poderia fazer o seguinte:

curl --request POST \
   --header "Content-Type: application/json" \
   --header "Authorization: token <API_KEY>" \
  'https://snyk.io/api/v1/org/orgId/project/<PROJECT_ID>/issues' \
  | jq '"Vulnerability: \(.issues.vulnerabilities[].title) in \(.issues.vulnerabilities[].package)@\(.issues.vulnerabilities[].version) - \(.issues.vulnerabilities[].url)"'

E o resultado seria:

Regular Expression Denial of Service (ReDoS) in ms@0.7.1 - https://snyk.io/vuln/npm:ms:20170412

A API de relatórios

Em um próximo post, mostraremos como usar a API de relatórios empresarial para ir além do que é possível com o endpoint de problemas de projetos. Se quiser acompanhar os problemas ao longo do tempo, ver o tempo até a resolução e contar com recursos de filtragem mais avançados, entre em contato pelo e-mail enterprise@snyk.io para experimentar nossa API de relatórios.

Publicado em:
Segurança de aplicativos