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
- 221 Linux vulnerabilities
- 18 GitHub vulnerabilities
- 9 Kubernetes vulnerabilities
- 7 Docker vulnerabilities
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.