Issues with container images
When a Snyk Project has a dockerfile, an image SHA may be available in the Webhook transports for that project. If an image SHA is available, we set the New Relic security event's entityLookupType to the SHA image, and the entityLookupType to ContainerImage.
The intent is for you to be able to correlate issues from Snyk that correspond to a specific container image with other security events in New Relic.
Issues with repositories
If an SHA image isn't available, we set the New Relic security event's entityLookupType to the repository. Across security tools, we use the remote URL from the repository as a universal identifier for a Repository in New Relic. However, the repository URL is only set on Snyk projects that you import through the Snyk CLI.
When the repository URL isn't available in the webhook payload, we set each New Relic security event's entityLookupType to the Snyk project's name. When you import projects to Snyk through an SCM integration, the project name defaults to the repository name given by the SCM. In the case of Github Enterprise, it's formatted as REPO_OWNER/REPO_NAME.
Establishing a baseline
Snyk webhook transports report only new or removed issues since the last test. When setting up a Snyk webhook to New Relic, you won't see all the current outstanding Snyk issues in New Relic.
One solution to establishing your baseline in New Relic is to export your current Snyk issues to JSON, and post them to the general-purpose security ingest processor endpoint in New Relic. Export your current issues, save them in a JSON file and run the following command to send them to New Relic:
$"https://security-ingest-processor.service.newrelic.com/v1/security/process" \> -X POST \> -H "Api-Key: YOUR_NEW_RELIC_LICENSE_KEY>" \> -H "Content-Type: application/json" \> -H "X-Scanner: Snyk_Webhook" \> -d @YOUR_JSON_FILE_NAME.json