With the launch of Xray, JFrog has pioneered the binary scanning space providing radical transparency and unparalleled insight into your software architecture. Snyk’s integration into Xray expands on that to take Xray up the stack and provide scanning for known vulnerabilities in your open source software (OSS) dependencies. A basic subset of Snyk’s vulnerability database (“Snyk Basic”) comes pre-integrated into Xray out of the box, with no add-ons or API keys required to activate it.
Securing open source libraries using JFrog Xray and Snyk Basic is good, but in this article we’ll show you how you can tackle this risk better by leveraging Snyk’s premium vulnerabilities DB (available with “Snyk Enterprise”), and how to do it best by discovering early, easier remediation and preventing vulnerabilities in the first place.
Basic vs. Premium
JFrog Xray comes prebundled with the Snyk Basic database that encompases vulnerabilties that are tracked from open public structured databases across multiple ecosystems: npm, java, ruby, python, scala, go, .net, php.
However, not all vulnerabilities are found in public databases, and in fact most don’t. Just as an example, only ~15% of the total Node.js package (npm) vulnerabilities in the Snyk Enterprise database have a CVE assigned to them!
By upgrading to Snyk Enterprise, you will be able to upgrade your JFrog Xray scans to include the complete set of vulnerabilities from the Snyk Enterprise database simply by entering your Snyk API key into Xray.
Continuous Monitoring and Alerts
New vulnerabilities get introduced to the Snyk Basic and Snyk Enterprise databases every day. Next time you scan any of your artifacts, these newly added vulnerabilities will show up in the scan results.
But waiting for your next scan might prove to be a bad strategy for building awareness to these vulnerabilities, especially for artifacts that don’t get worked on and scanned frequently.
Thus comes the need for continuous monitoring. Any time you add artifacts to JFrog Xray, it takes note of all the dependencies you are using, and when a new vulnerability that affects your artifacts is captured by Snyk Basic or Snyk Enterprise you will be immediately alerted about it (via email or with custom watches).
Early Vuln Discovery and the cost of addressing issues
It has been proven again and again that the cost of fixing a bug grows exponentially the later you find it in your SDLC. Similarly, the cost of addressing a known vulnerability grows the later you discover it!
Consider finding a new vulnerability in one of your deployed applications. Since the application is running in production there is great urgency to fix it. To do so, you would typically need to find an engineer that has worked on this application, stop them from what they’re working on, get them to build context on the vulnerability and the application, and then to search for a solution. Quite disruptive for this individual’s workflow.
When you upgrade to Snyk Enterprise you can move the detection of vulnerable libraries to earlier in the development cycle, using Snyk’s integration with Source Code Managers (SCMs) like Github Enterprise, Bitbucket Server and GitLab, as well as Snyk’s CLI. When scanning and discovery happen earlier in the SDLC, developers are already actively working on the project and have the time, desire and context to deal with the issue efficiently. The CLI can even be used as an advisory tool allowing developers to be preemptive and pick packages with no known vulnerabilities ahead of time.
Vuln Prevention
While discovering issues earlier makes them cheaper to fix, the absolute lowest cost of remediation is achieved by preventing new vulnerabilities from being introduced into your artifacts in the first place.
With Snyk’s SCM integration, Snyk runs tests on pull requests, and rejects the pull request if the edits suggested in it are introducing new vulnerabilities. Since Snyk distinguishes between ‘existing’ vulnerabilities (i.e your baseline) and ‘new’ vulnerabilities introduced from changes, you can use these tests to set a baseline and ensure your security posture is not getting worse even before you fix the existing security flaws.
Most importantly, pull requests tests have much better visibility than build time tests, acting as an effective and constant security reminder to your development team
Vuln Remediation
Your workflow isn’t complete until you’ve actually remediated the vulnerabilities. The challenge with fixing these vulnerabilities is that it is typically time consuming to research what each vulnerability means, and what are the options to get rid of it. This process gets especially complex when dealing with indirect dependencies and potential conflicts, and it often requires expertise that doesn’t exist broadly across the organization, resulting in issues being channeled to a few experts who quickly become bottlenecks. Blindly upgrading to latest versions of dependencies also has risks to it, and is generally not a recommended approach.
For this purpose Snyk’s SCM integration offers remediation with just a few clicks using a “Fix Pull Request”.
With the fix pull request, Snyk figures out the required code changes to eliminate the vulnerabilities and delivers them back into your SCM as a pull request for your engineers to approve.
Simplifying upgrades is helpful, but sometimes you cannot upgrade, for instance if there’s no upgrade available, or the fix requires a major upgrade you can’t currently accept. For these purposes, Snyk Enterprise also offers patches, minimal modifications to your packages that fix the vulnerability but hold no other changes. Patches are a great way to fix vulnerabilities you cannot otherwise solve, but can also act as a lower risk alternative to upgrading. All patches are open-source and available for auditing.
Monitor Deployed Code
We talked about the value of testing early before the build, but what happens after the build completes? The line between a build and a deployed application is not always a straight one, and many applications get deployed or modified through non-standard channels. With Snyk Enterprise, you can expand your testing to also connect directly to runtime platforms such as Cloud Foundry, AWS Lambda and more, and inspect directly for the presence of vulnerable libraries in your deployed applications. Such an integration gives you more confidence you are monitoring all of your applications, and monitoring what was truly deployed, and not just what you think was deployed.
Summary
To summarize, we’ve seen securing open source libraries using JFrog Xray and Snyk Basic is good, but with the fractional coverage of CVEs, you can tackle this risk better by leveraging Snyk’s premium vulnerabilities DB, and tackle it in the best way by upgrading to Snyk Enterprise and unlocking early vulnerability discovery, easier remediation, vulnerability prevention and monitoring of your deployed apps.