Blocking Downloads with Artifactory and Xray
Nobody wants to get sick, so we’ll wear jackets when it gets cold, take our vitamin C and avoid going out in the snow with wet hair. We all do different things to stay clear of nasty viruses and bacteria because we know that the loss in productivity and efforts we’ll have to make to get our bodily systems well again are a far greater burden than these preventive measures we take all the time.
Detect security vulnerabilities so your systems don’t “catch a cold”
The same goes for your software systems. If an artifact with a known issue or vulnerability gets into your ecosystem, it’s going to cost you to get rid of it. Sure, now that you have JFrog Xray, you can detect security vulnerabilities, performance issues and even custom issues that you defined, but if you only detect these once they are already being used, you’ll have some work to do. Your components have already gone through X development and QA cycles, you may be just about ready to release to production, and then someone remembers that Xray exposed a security vulnerability in one of the dependencies a couple of weeks ago. Whoops, stop development, find an alternative component, refactor your code, develop-QA-repeat-X-times, and it’s taken you weeks to make your code well again. Wouldn’t it be great if you could avoid this scenario? Well, now you can!
Prevention is Better than Cure
Until now, these things were handled manually. When an artifact is downloaded to a remote repository cache, Xray is triggered to run a scan, and if any issues are detected, your DevSec staff gets notified. Then you had to decide whether to release the artifact for download or not, and manage that manually. The latest release of JFrog Artifactory lets you take DevSec out of the loop. You can now automatically block the download of artifacts for which Xray has detected security vulnerabilities.
There are two levels of protection. First, you can specify that artifacts introduced to Artifactory (whether they have been cached in a remote repository, or uploaded to a local repository) cannot be downloaded until they have been indexed and scanned by Xray. This is akin to the background check run by credit card companies before they grant you a credit card. Similarly, you don’t want to give artifacts any credit to be downloaded until you run a background check (Xray scan) on them.
The second level of protection gives you finer control over which artifacts should be blocked if any. The issues discovered in artifacts are graded with a severity level: minor, major, or critical. Not every minor issue has to be a deal-breaker for you. That’s something you control. You’ll receive a notification when the issue is exposed, but you might not want to halt development right away until you’ve had a chance to investigate the issue further. Conversely, there’s a pretty good chance that you’ll want to block any artifacts with critical issues, and your developers will just have to look for something else. So you can specify at which severity level you want an artifact to be blocked if Xray detects an issue.
Whichever of these settings you choose to utilize, as soon as you set them, Xray is triggered to scan the whole repository so any components that don’t pass the credit check will be blocked right away.
And to avoid befuddling your developers about why they’re coming up empty-handed, Artifactory displays a notification about blocked artifacts in the tree browser, and gives an informative error message for REST API calls that fail because an artifact has been blocked.
So Xray together with Artifactory are your software systems’ jacket, wool hat or dietary supplements. They are the tireless sentry preventing any unchecked, suspicious, and potentially harmful artifacts from getting anywhere near your precious production systems. With download blocking, your systems are inoculated against artifact disease, so you can trust them to perform at their best and do what they’re supposed to do. And it all happens automatically and in the background without you having to lift a finger.
Additional resources:
Read about the Log4j Log4shell volnurability
