Published on December 22nd, 2019 | by Sunit Nandi

What Happens When Someone Discovers a Software Vulnerability?

Vulnerabilities in software can make it easier for cybercriminals to hack or compromise a system. Fortunately, most development teams have specialists constantly testing their software for weaknesses. But what happens when they find a vulnerability? And what happens when a piece of open source software, which may not have a round-the-clock team of developers, contains a vulnerability?

How Vulnerabilities Work

First, it’s important to understand how software vulnerabilities work. Vulnerabilities usually involve some kind of a bug in the code of the software—an error, missing functional element, or other functional possibility that wasn’t intended by developers. All forms of software have bugs, but not all bugs represent vulnerabilities; some only result in superficial annoyances.

Some bugs cause the system to crash or cause a failure in the chain of connectivity; these can be exploited to render a system inoperable, and/or hold it hostage. Some bugs allow information leakage—in other words, they make it possible for a third party to monitor communications or glean information that would ordinarily be kept private. These bugs are often used to gain login credentials or other personal information. Other bugs could elevate user privileges, or allow ordinarily unauthorized access to an app.

Discovering Vulnerabilities

There are a few common methods used by developers to try and proactively discover weaknesses and vulnerabilities. Thanks to the Common Weakness Enumeration (CWE) category system, there are more than 600 commonly known and understood classes of software weaknesses, including buffer overflows, path/directory tree traversal errors, cross-site scripting, vulnerabilities with hard-coded passwords, and predictable or otherwise insecure random numbers. Developers can use these patterns to audit their own software, and some developers go a step further by creating their own automated tools for detecting vulnerabilities.

However, not all vulnerabilities can be detected by these methods—especially those that don’t adhere to previously known and understood patterns. Unfortunately, many vulnerabilities aren’t discovered proactively; they’re first discovered by hackers or cybercriminals, who manage to do some damage before developers realize what’s going on.

Learning and Patching

Regardless of how the vulnerability is discovered, one of the first jobs of a development team is to learn more about the vulnerability. Once known, a vulnerability database becomes an indispensable tool in better understanding the nature of the vulnerability—and how to fix it.

Keeping these databases updated is good for everyone in the cybersecurity and development community. It’s a shared bank of knowledge that consumers, developers, and cybersecurity experts can use to stay abreast of the latest weaknesses and guard against them.

After learning about the vulnerability, developers typically begin working on a patch as quickly as possible. “Patches” are simply snippets of code that either modify what’s already there or provide additional functionality to circumvent whatever problem is responsible for the weakness. In the modern era, most of these patches can be distributed through semi-forced automatic updates. However, there are situations where committing a patch is much trickier.

The Open Source Dilemma

Security vulnerabilities are much more complicated and much more serious when they’re found in open source software and tech elements. There are several reasons for this:

Open source availability. “Open source” means that the element is freely available for public use. Accordingly, if the element is especially useful or innovative, it’s probably going to be used by a wide variety of developers for different apps. This instantly magnifies the potential problem.
Lack of dedicated team. Though some open source software elements do have dedicated teams, pouring full-time hours into their ongoing development, there are also some open source elements that are simply pet projects, and those that are collectively worked on by a volunteer community. This makes it hard to find a single party responsible for committing updates.
Multiple dependencies. The biggest problem is that open source products are usually used in a bigger context; they’re modified, reconfigured, and integrated into bigger, more complex products. Accordingly, a single software vulnerability in the core product could end up influencing hundreds, if not thousands of different applications, all of which may have dozens of intricate, built-in dependencies.

Fortunately, the most popular open source software elements also have a thriving and passionate community of developers. If quickly reported to a vulnerability database, it’s only a matter of time before someone finds (and shares) a solution; from there, developers attuned to the latest issues should be able to resolve the problem within their own systems.

There’s never going to be a perfect system for discovering, reporting, and patching software vulnerabilities because vulnerabilities can come in so many different forms. However, thanks to commonly referenced vulnerability databases, attentive teams, and quick work to issue patches, many of today’s biggest potential security flaws are found and resolved before they even become an issue.

Tags: discovers, vulnerability

About the Author

Sunit Nandi I'm the leader of Techno FAQ. Also an engineering college student with immense interest in science and technology. Other interests include literature, coin collecting, gardening and photography. Always wish to live life like there's no tomorrow.