Introducing Qwiet AI AutoFix! Reduce the time to secure code by 95% Read More

Every day, another zero-day, previously unknown vulnerability seems to hit the news cycle. As a developer, staying up-to-date with the newest vulnerability is challenging, but they’re only the tip of the vulnerability iceberg. As soon as researchers publish their zero-day vulnerability, the issue transforms into a known vulnerability. Now, security teams and attackers race against each other, one team trying to mitigate risk as the other seeks to exploit the n-day, or known, vulnerability. 

Developers should identify n-day vulnerabilities across source code and remediate the ones that attackers can exploit.

What Are N-day Vulnerabilities?

N-day vulnerabilities are published, known security weaknesses that may or may not have a manufacturer-issued security patch available. The “n” in n-day acts as a placeholder representing the number of days since the Common Vulnerabilities and Exposure (CVE) Program assigned it an identifier. While attackers need time and skills to research zero-day exploits, they only need to monitor the CVE List to learn how to use the n-day vulnerabilities as part of an attack. 

“Just Apply the Update” Isn’t Always Realistic

Installing the software’s or operating system’s security update is a fundamental security control. However, developers may not always have the resources to know all n-days or secure against exploits using them. 

Volume Is Overwhelming

The sheer volume of net-new vulnerabilities makes patching each one an unattainable task. To date, researchers have published

Across vendors that developers work with regularly, this adds up to:

  • 255 vulnerabilities total
  • 31.9 vulnerabilities per month on average
  • 1 vulnerability per day on average

These numbers don’t even begin to dive into the number of vulnerabilities identified across various open-source projects. 

Severity =/= Reachability

When the Common Vulnerability Scoring System (CVSS) identifies a vulnerability as “Critical,” it focuses on the intrinsic technical characteristics that remain constant over time, assuming a worst-case business scenario. Problematically, most environments are unique, meaning that an attacker might be unable to use the vulnerability within a given context. 

When looking at exploitability through the developer lens, the focus turns to whether attackers can “reach” the vulnerability, using it to achieve their objectives within the context of your code. For example, data sanitization or encryption can prevent attackers from using the vulnerability. 

Supply Chains Are Messy

At the end of July, Bleeping Computer published an article outlining the probl