Sometimes security systems need their own security system.
SonarQube has been adopted by more than 100,000 organizations, and its popularity is growing further. It is billed as “your teammate for code quality and code security.”
Security Hotspots
Checking code security is one of the major features that makes SonarQube so popular. Not only does it check for vulnerabilities in the code, which alerts a developer to apply a fix, it also checks for Security Hotspots.
According to a reviewer on PeerSpot, “”The most valuable feature is the Security Hotspot feature that identifies where your code is prone to have security issues.”
Security Hotspots may differ from a vulnerability in that they may not impact the overall application security, but the more Hotspots that emerge, the less robust the code is, exposing it to attack. SonarQube has the ability to pinpoint the Hotspots and assign them a level of severity according to the OWASP top ten. This allows a developer to review them and apply a fix.
Clean As You Code
Another preemptive security feature of SonarQube is to “clean as you code,” which is a methodology that allows developers to focus on taking responsibility only for the New Code they are working on. This ensures that they aren’t affecting or taking responsibility for any other code.
Threats to SonarQube
So, code security receives much attention in defining SonarQube’s product objectives, but what if SonarQube itself, deployed on the public cloud, is susceptible to image security vulnerabilities? Does that not undermine the sense of security achieved in strengthening the code? SonarQube may aim to rescue the code from threats and attacks, but who will rescue it from attacks to its Docker image?
For example, the security vulnerability data source, CVE Details, reports that official SonarQube Docker images (pre-Alpine base images) contain a blank password for a root user. Any such image used for a SonarQube Docker container may allow a remote attacker to achieve root access with a blank password.
And SonarQube images are not different than any other application images in being susceptible to vulnerabilities.
The container security firm, Prevasio, conducted an analysis of 4 million public Docker images in 2020. They found that just over half of them had critical vulnerabilities, and 68% of them had vulnerabilities of varying degrees.
A smaller, but still significant, percentage were classified as malicious. They contained malware, hacking tools, flatmap-stream malware, trojanized applications and even cryptocurrency miners. Coin miners target and exploit the Docker images both openly and hiddenly. The open, public nature of Docker Hub means weaker surveillance, and malicious images and metadata are more easily hidden amongst benign ones.
Solution
The solution to this problem lies in exploring the hardening process. Hardening is a very generic term, and can refer to many different strategies to strengthen images against vulnerabilities.
See this article for a detailed explanation of the Hardening Process.
Hardening strategies such as out-of-the-box image scrutiny, continuous scanning and rebuilding images to include security patches, will all strengthen the Docker image against security threats, enabling SonarQube to be secure enough to provide the code security it aims to do.
Click here to learn how Hossted zeroed in on the security risks to SonarQube images, and developed a special Hardened SonarQube offering for cloud marketplace deployment that addresses image vulnerabilities.
Sources: