Rezilion has added mitigation and remedial recommendations to its open source MI-X vulnerability identification tool. Additionally, the tool may now generate output that is machine-readable in either JSON or CSV format.
Finally, the company introduced support for Windows environments that are vulnerable to the Heartbleed and SpookySSL flaws. More than 20 well-known common vulnerabilities and exposures can be found and determined to be exploitable using the command line interface (CLI) tool provided by MI-X. (CVEs).
Rezilion developed the tool as a part of its attempts to provide a platform that enables businesses to more effectively secure their software supply chains, according to Yotam Perkal, director of vulnerability research at Rezilion. According to him, the platform’s main goal is to stop vulnerabilities from ever being added to apps by giving developers the context they need to evaluate the potential severity of a vulnerability.
Developers unquestionably need tools that make it simple for them to spot vulnerabilities while they write code. However, assigning developers sole responsibility for vulnerabilities is not a foolproof solution to programme security. To guarantee that the build produced by several developers is secure and that the runtime environment in which apps execute is malware-free, DevOps teams must adopt DevSecOps best practises.
The problem is that reaching that objective requires more than simply incorporating new tools into a DevOps workflow. The largest obstacle is bridging the historical cultural gap between cybersecurity teams looking for vulnerabilities and developers. Because most cybersecurity experts don’t understand how apps are created, regardless of whether the real source code is accessible from the outside, every instance of vulnerability detected in an application appears the same to them.
Meanwhile, DevOps teams are attempting to strike a careful balance between creating and releasing new applications and correcting many vulnerabilities. The ability of those teams to prioritise their patching work depending on the actual vs hypothetical severity of a vulnerability is crucial, according to Perkal.
All of the application security debt that application environments have accumulated over time may never be paid off. But as more apps are developed and application security vulnerabilities are dealt with more pro-actively, cybersecurity should get better. The problem, of course, is that cybercriminals are now focusing on software supply chains; by introducing malware into a DevOps workflow, there is a chance that numerous downstream applications could be compromised. In order to secure their software supply chains, organisations are currently in a race against time.
The good news is that no programmer sets out to create an insecure application on purpose. Simply said, a disproportionate number of them have been trained to view security as a challenge to be conquered rather than a problem to be solved. However, it will benefit everyone if they are given as many tools as possible to fix as many vulnerabilities as they can.
