This week NSA published a list of the top 25 vulnerabilities that Chinese hackers are actively exploiting, and unsurprisingly the list included some of the most prominent CVEs that we’ve covered in our previous risk based vulnerability management blogs.

Using open source code makes it easier to build applications, but the freely available nature of open source code introduces the risk of pulling potential security vulnerabilities into your environment. Knowing whether or not customers are actually accessing the vulnerable parts of your application is key to triaging security threats without spending hours fixing an issue that doesn’t affect end users.

Common Vulnerability Scoring System (CVSS) scores have been viewed as the de facto measure to prioritize vulnerabilities. Vulnerabilities are assigned CVSS scores ranging from one to 10, with 10 being the most severe. However, they were never intended as a means of risk prioritization. If you’ve relied on CVSS scores alone to safeguard your organization, here’s why you’re probably using them incorrectly.

Full stack development is all the rage these days, and for good reason: developers with both front-end web development skills and back-end/server coding prowess clearly offer substantially more value to their respective organizations. The ability to traverse the entire stack competently also makes interacting and cooperating with operations and security an easier affair—a key tenet of DevOps culture.

An Elastic Security Advisory (ESA) is a notice from Elastic to its users of a new Elasticsearch vulnerability. The vendor assigns both a CVE and an ESA identifier to each advisory along with a summary and remediation details. When Elastic receives an issue, they evaluate it and, if the vendor decides it is a vulnerability, work to fix it before releasing a remediation in a timeframe that matches the severity.

While auditing the Kubernetes source code, I recently discovered an issue (CVE-2020-8563) in Kubernetes that may cause sensitive data leakage. You would be affected by CVE-2020-8563 if you created a Kubernetes cluster over vSphere, and enabled vSphere as a cloud provider with logging level set to 4 or above. In that case, your vSphere user credentials will be leaked in the cloud-controller-manager‘s log.

A critical Active Directory vulnerability (CVE-2020-1472) has been making headlines for being the most notorious elevation of privilege bug because it can affect all computers and domain controllers in an organization. This high-risk vulnerability, dubbed Zerologon, gives threat actors easy, instant access to domain controllers without requiring any additional privileges. This attack does not even require a user to be authenticated; the user just needs to be connected to the internal network.

This time around, the MySQL vulnerabilities caught our attention because of their low CVSS scores compared to their high likelihood risk rating. This is something we see often when working with our customers, and demonstrates how a risk based approach to vulnerability management changes as organizations focus on where there is a real risk of compromise.

Every day we discover new vulnerabilities in our systems, cracks in the fence the adversaries take advantage of to get into your organization and wreak havoc. Understanding what you have in your environment (e.g., types of devices, systems equipment, etc.) is very important in order to make sure the controls in place are working and more importantly, keeping up with the threat landscape.