What’s the Deal with CVEs?

Understanding Common Vulnerabilities and Exposures (CVEs) is a non-negotiable skill for software developers, especially those stepping into the realm of DevSecOps. When you ignore CVEs, you’re risking not just your project but also your entire business. In this post, we'll break down the concept of CVEs, step-by-step, so you can level up your
security game.

Let's kick things off by understanding what a CVE actually is.

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It's a standardized
identifier for publicly known cybersecurity vulnerabilities. The public
database of CVEs is maintained by the MITRE Corporation at
https://www.cve.org. Another database,
NIST's National Vulnerability Database
(NVD), syncs with the data from the MITRE’s
CVE list, but enhances the list with more information. These
organizations share information and work in collaboration with the U.S. Department of Homeland Security (DHS).

A CVE is researched and written up by CVE Numbering Authorities (CNAs). These are organizations with cybersecurity professionals who volunteer
their time to research potential vulnerabilities and then report them.

CVE records typically include a unique identifier, a brief description, and references to related vulnerabilities or patches. To make this more concrete, let's walk through an example CVE entry:
CVE-2020-12345.

• CVE ID: The CVE identifier is unique for each and vulnerability, such as CVE-2020-12345.

• Severity scoring: The NVD also provides a severity of the vulnerability based on the common vulnerability scoring system (CVSS). CVSS scores are often used by vulnerability management systems for prioritization.

• Description: The description simply summarizes what the vulnerability is and how it can affect systems. In the case of this CVE, it is: “Improper permissions in the installer for the Intel(R) Data Center Manager Console before version 3.6.2 may allow an authenticated user to potentially enable escalation of privilege via local access.”

• References: These are links to patches, security advisories, or other related vulnerabilities. This particular CVE includes a link to the vendor advisory (from Intel) for this vulnerability.

Now that we've got the basics down, let's dive into the impact of CVEs on your applications.

Impact of CVEs on applications

CVEs can have a profound impact on your applications and, by extension, your business. Understanding these impacts is crucial for effective risk management. Let's break this down into two key areas: security risks and business implications.

Security risks

CVEs detail where and how your application might be exposed to a variety of security risks, bringing potential for data breaches and system compromise.

Imagine a hacker exploiting a vulnerable third-party library that your web application depends on. They could get their hands on sensitive user data, like credit card numbers or personal identification. But it doesn't stop there. They could manipulate system functionalities, disable security features, or even deploy malicious code.

Business implications

Beyond the immediate security concerns, an exploited CVE could devastate your business. A single exploited vulnerability can lead to reputational damage and loss of customer trust. On top of this, you have the financial burden of addressing a security breach, and the potential legal consequences. But they’re also the source of a lot of “noise” for developers. How do you filter the signal from the noise?

Case study: Heartbleed

Heartbleed was a security bug in the OpenSSL cryptography library, a widely-used software for implementing SSL/TLS protocols to secure internet communication. The bug was introduced in OpenSSL's heartbeat extension (which is how it got the name "Heartbleed"). Attackers exploiting this vulnerability could read sensitive data directly from the memory of the target server, gaining
unauthorized access to encryption keys, passwords, and user data.

Heartbleed was officially referenced as
CVE-2014-0160.

The impact of Heartbleed was staggering, affecting a vast number of businesses and individual users. A big reason for this was because just about everybody relies on OpenSSL in some way. When the CVE was disclosed, approximately 17% of the world’s secure web servers (that’s about half a million servers) were believed to be vulnerable—and those were just web servers. Nearly three years after the disclosure, nearly
200,000 internet-connected devices were still found to be vulnerable.

The vulnerability exposed millions of login credentials. Companies worldwide—including Akamai, AWS, GitHub, Pinterest, Reddit, and Stripe—needed to patch their systems and then issue notices advising customers to change their passwords. Websites and services across all sectors, from government agencies to businesses, shut down temporarily to address the security flaws.

What did we learn from Heartbleed? We learned that organizations need these things:

• Regular security audits
• Timely patch management
• An incident response plan
• Transparent communication with their user base during a cybersecurity crisis

Let’s move from example to action. How can you leverage CVEs to your advantage?

Leveraging CVEs

CVEs aren't just doom and gloom. They’re supposed to help you make sure your systems are secure.

So, what should you do when a CVE is disclosed? Here's a quick checklist
of steps:

1. Check for vendor updates. Software vendors often release patches or advisories when a CVE is disclosed. Check with them for updates first.
2. Assess impact. Evaluate how (or whether) the CVE affects your specific environment. Not all CVEs will be relevant to your system. Not affected? Then return to your codebase and your coffee.
3. Apply patches. If a patch is available, apply it immediately to your affected systems.
4. Update dependencies. Sometimes the CVE affects a library or component your software relies on. Make sure to update these dependencies.
5. Notify stakeholders. Keep your team in the loop. If necessary, update your customers with helpful information too. Transparency can go a long way in retaining customer trust.
6. Monitor. After patching, keep an eye on system logs and traffic. Make sure the issue is truly resolved.

Be warned: attackers read CVE databases too. Your inaction could be their opportunity. Attackers will use CVE list information to identify unpatched systems, and they’ll work quickly and efficiently to get their foot in the door before you lock it. Attackers can automate scans for vulnerable systems and exploit them faster than you might think. So,
once a CVE is disclosed, the clock is ticking.

Panoptica: Your CVE Noise Reduction Tool

When it comes to helping you navigate CVEs, Panoptica is a cloud-native application protection platform (CNAPP) that integrates seamlessly with your cloud environment. Some of the key features that Panoptica brings to the table include:

• CVE data enrichment with IntSights: Panoptica's integration with IntSights adds an extra layer of intelligence to your CVE data. Using dark web threat intelligence data from IntSights, Panoptica will provide a risk score—tailored to your unique cloud-native setup—for each CVE, helping you prioritize which vulnerabilities to address first.

• Attack path analysis: Panoptica identifies potential attack paths within your environment. By understanding how an attacker might exploit vulnerabilities, you can take proactive measures to secure your applications.

• Prevention measures: Panoptica offers real-time automated alerts and continuous monitoring. This allows you to measure the effectiveness of your security measures and make data-driven decisions.

Conclusion

CVEs are key to cybersecurity and threat preparedness. Whether you’re a software engineer or on the DevOps team, you can’t afford to ignore the helpful information that comes from CVE disclosures. CVEs can help you manage the security risks—whether those might be compromised credentials, the installation of malicious code, data exfiltration or loss, or other threats.

Panoptica helps you understand the vulnerabilities affecting your cloud environment and provides actionable insights to secure your applications.

We’ve talked about how adopting DevSecOps methodologies is a journey. Remember that security is not a one-and-done thing. It’s an ongoing process. Panoptica will ride along with you, offering the tools you need to deal with CVEs effectively.

Explore what Panoptica has to offer by signing up for free today.