ChatGPT Deep Research - How to get vulnerability details from Snyk API

About this report

Warning - This report was generated by ChatGPT's Deep Research feature. It may contain errors, so the sources are listed as links beside each assertion.

Prompt:

This is the prompt I used to generate this:

Using the snyk api how do I get details of code analysis scan? If it detects a problem like “use of broken or risky cryptographic algorithm” in the gui I can see the recommended fix but I can’t seem to access it through the snyk gui. How do I get it through snyk api? Check snyk documentation about its api

Deep Research Answer:

Overview

Snyk Code is Snyk’s static application security testing (SAST) feature that finds code issues (like using weak cryptographic algorithms) and provides recommendations on how to fix them. In the Snyk web UI, each Snyk Code issue comes with a detailed technical explanation and suggested fix – for example, a warning that “Cipher Block Chaining (CBC) mode does not provide integrity. Consider using Galois/Counter mode.” However, retrieving this same level of detail via the Snyk REST API v1 is challenging. The current v1 API for issues will list Snyk Code issues with basic metadata (title, severity, CWE, etc.), but it does not include the full recommended fix text or in-depth explanation that you see in the UI【1†】. This has been a common point of confusion for users trying to programmatically access Snyk Code results.

In summary: while you can use the Snyk API v1 to get a list of code issues, the detailed recommended fix guidance (like the suggestion to use Galois/Counter Mode for encryption) is not directly exposed in the v1 API response. Below, we’ll outline which API endpoints/fields are available, what information you can get, and the limitations. We’ll also discuss workarounds or alternative approaches for obtaining those missing details.

API Endpoints to Use

To retrieve Snyk Code issues via the REST API v1, you will primarily use the “List Issues” endpoint on a given project. The typical endpoint format is:

GET /api/v1/orgs/{orgId}/projects/{projectId}/issues

This call (with the appropriate org and project identifiers and authorization) will return all issues for that project, including Snyk Code issues alongside any open source vulnerabilities or other issue types. Key points about using this endpoint for Snyk Code results:

• Include descriptions (if available): You can append query parameters such as includeDescriptions=true and includeIntroducedThrough=true in the request. For example:
  http GET /api/v1/orgs/{orgId}/projects/{projectId}/issues?includeDescriptions=true
  However, note that includeDescriptions mainly affects open-source dependency vulnerabilities (providing their public CVE/CWE descriptions). For Snyk Code issues, this parameter does not add the detailed code fix recommendation text; it typically only ensures the presence of the issue’s title and maybe a generic description placeholder【1†】.

• Filter by issue type (optional): Snyk Code issues are categorized as "issueType": "code" (or sometimes "issueType": "codeIssue" in the JSON). If you want to specifically retrieve only Snyk Code issues, you could filter the results client-side by checking issueData.id or issueType for those that indicate Snyk Code. (Snyk Code issue IDs often have the format snyk:code:<unique-id>.) The API itself does not offer a direct query param to fetch only code issues – you’ll get all issues for the project and then differentiate by type in your processing.

• Single-issue detail endpoint: Unlike open source vulnerabilities, there isn’t a documented v1 endpoint to fetch one code issue’s full details by ID. (For open source vulns, one can query something like /v1/org/{orgId}/issue/{issueId} to get extended data from Snyk’s vulnerability DB, but Snyk Code issues are not in that DB.) So, your main option in v1 is the project-level issues listing.

In practice, you would call the /issues endpoint on the project and parse the JSON for each issue. Among these, find the issue with title “Use of a Broken or Risky Cryptographic Algorithm” (or by its issue ID/CWE). The API will provide the high-level data about this issue.

Fields to Retrieve

In the JSON response from the /issues endpoint, each issue object contains an issueData section with various fields. For Snyk Code issues, here are the relevant fields you can expect and what they contain:

• issueData.title – The title of the issue, e.g. “Use of a Broken or Risky Cryptographic Algorithm”. This is the same title shown in the UI for the issue.【1†】

• issueData.severity – The severity level (e.g. medium, high) of the issue.【1†】

• issueData.identifiers – Identifiers like CWE numbers associated with the issue. For example, CWE-327 will appear here, confirming it’s the “Use of a Broken or Risky Cryptographic Algorithm” weakness category.【1†】

• issueData.id – A unique Snyk identifier for the issue rule. Snyk Code issues have IDs starting with snyk:code: followed by a hash or identifier. (This ID references the specific code quality/security rule in Snyk’s database.)

• issueData.url – A URL to Snyk’s knowledge base or more info about the issue, if available. Often this might point to a Snyk page or CWE description. For Snyk Code issues, the URL may be a generic page (or might even be blank/null in some cases).

• paths / locations – The list of places in your code where the issue was found. This includes file paths and line numbers. For example, it might show that the insecure crypto usage is in packages/fortuna/src/utils/crypto.ts at a certain line【1†】. Each path entry can contain the snippet of code or function call (though in many cases, it just gives location; the actual code snippet might not be included in the API response).

What’s not included: The crucial point is that the detailed description or recommended fix text is not present in these fields. In the UI, you see an explanation like: “Cipher Block Chaining mode (used in crypto.createCipheriv) does not provide integrity. Consider using Galois/Counter mode.” This explanatory text is part of Snyk Code’s rule description, but the v1 API does not expose this in the response. There is no field like issueData.description or remediationText for Snyk Code issues in the v1 API output【1†】. By contrast, if this were an open source dependency vulnerability, the description field (when includeDescriptions=true) would contain a detailed vulnerability description and sometimes remediation guidance – but for Snyk Code issues, that field is essentially empty or non-applicable.

In summary, the fields you can retrieve will tell you what the issue is and where it is, but not the full “why/how to fix” guidance. You’ll see the CWE number and the title (which hints at the problem), but the specific recommendation (e.g. “use Galois/Counter mode”) is missing from the API response.

Limitations and Workarounds

Limitations of Snyk REST API v1 for Code issues: The absence of the detailed recommended fix and technical explanation in the API response is a known limitation. This happens because the Snyk REST API v1 was originally designed around issues like open source vulns and license issues, and Snyk Code (which was integrated later) doesn’t fully expose its rule descriptions through the same endpoints【1†】. Essentially, the API’s contract for an “issue” object doesn’t yet include the Snyk Code rule’s descriptive text. So even though the Snyk web UI clearly displays guidance (drawn from Snyk’s internal rule description), the v1 API will not return that part of the data.

There are also fields that appear missing or empty for Snyk Code issues via API:

• description or message field: If you look for a description field in the issue object, it may be blank or a very short generic text for code issues. The rich explanation is not there.
• Remediation suggestions: Unlike open source issues which may have a fixInfo or suggested upgrade version, Snyk Code issues would ideally have a textual suggestion. This is not present in v1 output.

These limitations explain why, as you observed, the Snyk UI shows information that the API doesn’t give you. The UI likely pulls that from an internal source (for example, Snyk’s own GraphQL service or a knowledge base) which is not exposed in the public REST API v1.

Workarounds / Alternative Approaches:

• Snyk CLI (Command Line Interface): One practical workaround is to use the Snyk CLI to scan the code and output results in JSON, which might include the detailed message. For instance, running snyk code test --json on the project may produce a JSON report that contains the explanation text for each issue. Many users have leveraged the CLI output when the REST API was lacking. This isn’t as straightforward as an API call (since you need to have the code and run the CLI locally or in CI), but it can programmatically give you the data you need, including those “consider using XYZ” suggestions.

• Snyk GraphQL / v3 API (if available): Snyk has been working on new APIs and there have been mentions of a GraphQL API for advanced data access. As of the latest updates, some of Snyk’s newer features (and possibly Snyk Code data) might be accessible through a GraphQL endpoint or a newer versioned REST API (sometimes referred to as v2/v3 in Snyk docs). Check Snyk’s API documentation or ask Snyk support if there is a beta or GA API that exposes Snyk Code rules’ full details. For example, Snyk’s GraphQL API (if your account has access) might allow querying code issues and could include fields like description or helpText for the rules. This is not enabled by default for all users, but it’s worth inquiring.

• Contacting Snyk Support / Feature Request: If the information is crucial for your use case, contacting Snyk support is recommended. They can confirm the current capabilities of the API and might offer solutions. Snyk is aware that users want parity between what the UI shows and what the API returns【1†】. By reaching out, you might learn about upcoming API improvements or even get access to a private beta. At the very least, logging this need with support helps prioritize the feature in their roadmap.

• Documentation and Knowledge Base: While not a direct solution, remember that the Snyk UI’s “Learn about this vulnerability” link for Snyk Code issues often goes to a documentation page or CWE entry. In the example of CWE-327 (risky crypto algorithm), that link might point to a general article on why CBC mode is unsafe. You could use the CWE ID from the API (identifiers.CWE) to fetch information from external databases like MITRE’s CWE database or other security knowledge bases. This won’t give the Snyk-specific recommendation text, but it can provide background. For instance, CWE-327 is documented as “Use of a Broken or Risky Cryptographic Algorithm,” which explains that older ciphers or modes may be weak【1†】. Combining that with your own knowledge (that GCM is a safer mode than CBC) could be a partial workaround if absolutely needed.

Is it possible at all via v1? Currently, with v1 of the REST API alone, you cannot retrieve the UI’s full recommended fix text for Snyk Code issues. No combination of query parameters will expose that missing snippet about Galois/Counter mode. This appears to be an intentional or known gap – the v1 API was not fully updated to carry all Snyk Code rule details. There is no separate documented endpoint like /issues/{issueId}/details for code issues in v1. All signs indicate that it’s a limitation of the API as of now.

Alternatives if not via v1: If you require these details in an automated fashion, consider these approaches:

• Use the Snyk CLI’s JSON output (which includes the guidance) as part of your pipeline and parse that.
• Check if Snyk has an updated REST API version (v2/v3) or GraphQL API that your account can use – these might provide more fields.
• As a last resort, if you only need a handful of specific rules’ guidance, you could maintain a small mapping in your code (for example, if you know CWE-327 corresponds to using CBC, your tool could advise about GCM). This is not ideal, of course, as it hardcodes knowledge that Snyk actually has internally.

In conclusion, the Snyk REST API v1 cannot directly give you the detailed “how to fix” snippet for Snyk Code issues like “consider using Galois/Counter mode.” You can retrieve the issue metadata (which confirms what the issue is and where), but the recommended fix narrative is missing due to API limitations【1†】. To get that information, you would need to use alternative methods (CLI or check with Snyk about newer APIs). Many users in the Snyk community have noted this gap, and it’s something to watch in Snyk’s future API updates. If this feature is critical, don’t hesitate to reach out to Snyk support and express the need – they may provide guidance or even timeline if a fix is on the horizon.