Another week, another high severity vulnerability in a popular open source component. This one, discovered by Qualys Threat Research Unit, is a remote code execution (RCE) vulnerability in OpenSSH.
The good news: it is not trivial to exploit because it is a race condition issue.
The bad news: Qualys claims they have “identified over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet”.
The worst news: Every organization concerned needs to spend the next couple of weeks running vulnerability scans over their entire environment to learn if they have an exploitable instance.
Every time a new vulnerability is disclosed, we build a rule, put it in a scanner, then scan our entire IT environment to look for a vulnerable instance of the component. The next day, we do it all over again for the newest vulnerabilities.
Imagine that automobile manufacturers did things our way. When an airbag was found to have a defect (call it a vulnerability), every vehicle in the world would have to be brought into a shop and hooked up to a scanner (call it a vulnerability scanner) to see if the defective part was present. The next day, when a starter motor was found to have a problem, the same process would start again.
Automobile manufacturers solved this problem 100 years ago with a bill of materials. Today, they know which components from which vendors are in each vehicle, down to the serial number of the component and the VIN number of the car. When a defective part is identified, they can quickly determine precisely which vehicles are affected and notify the individual consumers of the need for a recall.
The software industry has made great strides in producing and publishing Software Bills of Material (SBOM) for applications. These allow organizations and software consumers to know which components make up the applications they use and provides visibility to software supply chain risk.
Why not IT?
IT infrastructure is largely made up of open-source software like OpenSSH, OpenSSL (remember Heartbleed?), and various Linux distributions. Teams spin up new containers on old base layers and bypass the Secure Development Lifecycle even in organizations with mature software security programs. The result is they don’t have a good understanding of what they are running. As we have seen, this causes organizations to react by scanning for vulnerabilities over and over again.
Producing a Software Bill of Materials for your IT infrastructure allows more proactive security practices. When an issue like RegreSSHion occurs, IT and security can refer to their SBOMs to determine which systems include the vulnerable component and, if they choose, scan those systems to confirm exploitability.
SBOM creation and management requires support from automated tools to detect what’s actually installed and running on your servers. But the traditional SCA tools, typically integrated in the CI/CD pipeline, and designed for managing the SBOMs for developed software, won’t help much in this endeavor. Our technology partner Insignary developed Clarity to generate SBOMs for compiled applications, including software and firmware running your IT infrastructure. It quickly and continuously builds SBOMs without the need for source code or interrupting your operations. It creates alerts when new vulnerabilities are disclosed for any component in any of your SBOMs without the need to rescan.
Start now with proactively securing your IT infrastructure. If you’re tired of always playing catch up every time a new vulnerability is disclosed, contact us today.
Contact us