What Really Burns? The 4 Elements of Library Lifecycle
By
Roi Abitboul
In the world of applications, libraries pass through four distinct stages that mirror the elements of nature—air, earth, water, and fire. Just as in nature, each stage has its characteristics, but only one stage can BURN. In this blog we will explore these four stages and assess the risks—or lack thereof—that each one poses to your application.
Stage 1: In Repository (Air)
In the first stage, libraries exist only as ideas. They are defined in configuration files, but they don’t yet have substance. They float in the project’s dependencies, invisible but present, just waiting for the opportunity to become part of the environment. It’s easy to see why repository presence is very similar to the Air element.
Stage 2: Deployed to Disk (Earth)
When a library moves from the repository and is installed onto the system, it is grounded and has a physical presence, like the earth element. It is stored on disk, ready to be used, but still poses no immediate threat. In this phase, libraries are visible to the system, but their mere presence does not pose any risk. Many security tools flag these libraries, even though at this stage they are not a threat.
Stage 3: Loaded into Memory (Water)
Now the libraries start flowing into the application, meaning that the application has access to these libraries. Just like the water element, the libraries are adaptable and fluid. At this stage, the code is loaded into memory by the application during runtime, making it available for use, but not yet activated, therefore these libraries are not a security risk at this stage. The potential for action increases, but it is not a risk unless invoked. However, many security systems fail to differentiate between libraries that are loaded and those that are actually executed.
Stage 4: Actual Execution (Fire)
Finally, we reach the critical stage—execution. When the application invokes functions from the library, it’s like fire sparking into existence—capable of causing real harm.
The Problem with Traditional Security Approaches
At this point, it is clear that only executed libraries pose a real threat to the application. Libraries that are in repository, deployed to disk and loaded to memory are harmless. Even if a library has known vulnerabilities with a known exploit and a high CVSS score, it still represents a potentialfuture risk, if it’s never executed, it poses no real threat. That said, traditional security approaches generate vulnerability warnings for all of these libraries which cause significant wasted resources as developers and security teams are forced to address these alerts. This is especially true when the transitive vulnerabilities are found in non-executed stages.
If your organization has infinite engineering resources, by all means, fix every vulnerability in your code. Since most organizations have limited resources, fixing vulnerabilities in code that is not executed is not just inefficient; it’s counterproductive. This diverts critical resources from innovation and real security risks.
Raven’s Approach: Only Fire Burns
At Raven, we deprioritize over 90% of vulnerabilities by analyzing runtime code and focus on the executed stage. By doing this, your teams can prioritize the real risks.
Until we meet, you might want to check out our blog
Oops! Something went wrong while submitting the form.
Security
7 Reasons Why Attackers Shifted Towards Cloud Applications
Attackers are increasingly shifting their focus from infrastructure to applications, exploiting vulnerabilities that traditional security measures cannot protect.
The Critical Need for Cloud Runtime Application Security
While shift left strategies are essential for building secure applications, they are not sufficient on their own. Cloud runtime application security, or protect right, is crucial especially as attackers are increasingly shifting their focus to applications.
.svg)
.svg)
.svg)
.avif)
.avif)
.png)
