CVE: facts, challenges and our strategy

cves header

CVE: Three letters have kept you and us busy for some time and will probably continue to do so forever. Common Vulnerablities und Exposures is the full name behind this abbreviation which covers several aspects.

CVE is an organization that has been involved in cybersecurity for 25 years. It calls itself a program that works with partners around the world. Financial support comes from

  • the U.S. Department of Homeland Security (DHS)
  • the Cybersecurity and Infrastructure Security Agency (CISA) and
  • Mitre, an US-based international company, being present in Germany in Ramstein, Stuttgart and Wiesbaden, working on a bunch of global challenges such as 5G/6G, GPS, cybersecurity, health care and aviation securiy.

CVE-List

This CVE-organisation has a list of CVE-IDs, describing known security gaps. The ID is composed of the year and a random number, eg. CVE-2024-38821. This ID will be assigned on request when a security gap was found and published. As soon as a minimum of informations is available, the CVE entry will be published in the CVE list.

We are talking about CVEs, and in doing so we mean a bunch of those IDs, coming from different international sources. Other central players and names are:

  • The OWASP-Foundation, having the wasp in their logo, but doing more useful things than annoying people, as they are dealing with Open Worldwide Application Security Project. It is an international project for education, tools and cooperation towards their vision of a world without unsecure software. They publish a Top Ten List of the most critical security gaps for web applications.
  • The CVSS, the Commun Vulnerability Scoring System, by FiRST-Teams, the Forum of Incident Response and Security Teams. This CVSS evaluates the security gaps in accordance with their severity in low, medium, high and critical.
The CVE-ID in the list combined with the severity – that is a reasonable couple guiding us in our decisions and activities.
 
CVEs can be found in lots of different places, in single files, in services, applications, frameworks, libraries and even entire operating systems.

 

We are watching the CVE-lists

We are using the tool Dependency Track, which helps us to keep track of our SBOM. That is the abbreviation for Software Bill of Materials,  in short the list of all software components we are using.

The dashboard with lots of colorful diagrams gives a first impression of the current situation:

dashboard-cve

Other views provide details for our applications, stating affected versions and severities. We prefer blue, not only because it is the color of our logo, but because it tells us, that everything is fine.

dependency track projektebene

Another view shows the list of CVE-IDs and links to pages with further informations helping us to decide whether the affected element is part of our applications, whether we need to act, which new versions are available and how urgent the situation is.
In order to keep our project managers up to date, a mail service was set up to inform about CVEs found. The subject line indicates whether the mail can be deleted because none of the components we use are affected or whether it is a false positive message. Nevertheless, some mails will stay and need evaluation by the development team.
We will discuss the CVEs that need to be eliminated urgently at the latest in the estimation meeting of the next sprint. In most cases, they are immediately given the status “inSprint” to be eliminated in the next few days.

Our project managers will then agree with their customers about the delivery date of the new package.

The balancing act between CVEs and patches

“In Triage”, that is the name of the state for CVEs, the development is checking. It is not really a decision between life and death, but the decision may have serious consequences.

What is the worst case result if

  • the security gap will not be closed? 
  • an upgrade to close the security gap affects other functionalities?

 

We already had a situation which was probably due to the second reason. So we watch out for cases like this. We will always check which functionalities are using the affected component and how much time and resources are available for testing.

We had another case where a closed security gap required far-reaching changes in the application. It took some time, as we first had to find the cause for the unexpected behaviour of the system and then a new solution.

Hopefully the truth lies between both worst-case-settings. We are actively working on the matter by keeping libraries and components as up-to-date as possible so that any new patch only means little changes allowing to abolish the CVEs as quickly as possible.

cves header

Labeling at Scherdel

How Cartago Software GmbH supports SCHERDEL in mastering all special barcode requirements and making them

Cookie Consent with Real Cookie Banner