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 problems that the Android patch gap created. For example, Google or another vendor may develop a patch, but manufacturers may delay rolling it out on their devices. Just as gaps exist between upstream and downstream manufacturers, gaps exist across third-party libraries and frameworks. Without the ability to identify all components and trace all connections, you can’t understand whether attackers can exploit upstream risks in downstream projects. 

Securing Your Code from the Flood of N-day Vulnerabilities

Just like people prepare their homes for a flood before a hurricane, you can prepare your team to protect against n-day vulnerabilities in their source code. 

Identify Components

Cybersecurity professionals always say, “you can’t secure what you don’t know you have.” 

With compliance directives seeking to hold developers responsible for the open-source components used in their products, you need an inventory of all code “assets” across your source code. When you have a Software Bill of Materials (SBOM) detailing the open-source software (OSS) you have, you can identify the ones with vulnerabilities. 

Map Data Flows

When you use multiple libraries, you need visibility into functional elements and data flow paths. When you map data flows across the application, you can detect dependencies across:

  • User inputs
  • Log files
  • Databases
  • Custom code
  • Open-source libraries
  • SDKs
  • APIs
  • Microservices

Prioritize Reachable Vulnerabilities

To solve the n-day vulnerability problem, you should focus on the vulnerabilities that pose the highest risk to your application. By mapping all components and data flows, you can leverage automation to trace all the potential paths from an insecure input to the sensitive data. When you can determine reachability across the entire code path sequence, you can identify and prioritize the vulnerabilities that attackers could actually use to compromise data. 

Incorporate Threat Intelligence

Vulnerabilities are only dangerous when attackers use them to achieve their nefarious goals. Even a reachable vulnerability may not be actively exploited in the wild. With threat feeds, you gain information about vulnerabilities that pose a real, rather than potentially reachable, threat. When prioritizing remediation actions, threat intelligence gives you data about real-world malicious actor activities like:

  • Exploits
  • Threat actors
  • Ransomware
  • Botnets

Qwiet AI: Helping Solve the N-day Vulnerability Problem

With Qwiet AI’s preZero platform, you get the visibility and data necessary to identify and prioritize vulnerabilities across your source code. Our preZero application security testing platform gives you context around whether attackers can reach a vulnerability with more accurate findings by mapping data flows across the entire application. Our Blacklight threat intelligence feed enables you to incorporate real-world attack information so that you can pinpoint your next steps more precisely, focusing on the same vulnerabilities that malicious actors care about. 

Try Qwiet AI’s preZero platform for free to see how it can help you identify and remediate n-day vulnerabilities. 

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit: www.shiftleft.io.


See for yourself – run a scan on your code right now