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

“It was a dark and stormy night…” While this introduction works for spooky stories, no developer wants their app to become nightmare fuel. While you might be able to grab a flashlight to comfort yourself around a campfire, you don’t have the same protection when you’re working on an application. Increasingly, developers use third-party code that presents a security threat. Since developers primarily focus on the application’s core functionality, they may not realize these risky code snippets exist. 

To improve your app’s security, you can shed light on shadow code with continuous source code scanning and vulnerability prioritization. 

What is Shadow Code?

Shadow code consists of the unapproved or unauthorized scripts embedded in third-party code and libraries that developers unknowingly integrate into their software. Shadow code creates security and compliance risks. Since developers don’t realize their source code contains these snippets, they may not identify vulnerabilities that attackers can exploit. 

Shadow code leaves applications vulnerable to various threats, including:

  • Malicious code injection
  • Website defacement
  • Data exfiltration
  • Script attacks
  • SQL injections
  • Clickjacking
  • Sideloading
  • Cross-site scripting

For example, the Magecart attacks arose from vulnerable third-party JavaScipt shadow code executing on the client-side that attackers exploited, enabling them to collect sensitive data every time customers entered data.

Threats Hiding in the Shadows

Shadow code isn’t new. Developers have almost always used previously developed code to help them incorporate useful functionalities into their software and apps. In some cases, they include this code because it speeds up time-to-market. In other cases, the third-party code may work better with previously existing components. 

The explosion of open-source third-party components changes shadow code’s impact on an application’s security. For example, research estimates that any given piece of modern software consists of 70%-90% Free and Open Source Software (FOSS). 

Developers don’t need to stop using third-party code. However, they do need to identify potentially dangerous vulnerabilities and implement appropriate security measures. 

Fourth-party scripts and beyond

When an application calls a third-party script, it executes directly from the third-party’s web server. Loaded into the user’s browser, the malicious code executes from the third-party’s remote server, meaning it can bypass traditional security protections. 

If threat actors insert malicious code into the third-party script, they can successfully:

  • Exfiltrate data to remote servers they control
  • Redirect users to malicious websites 
  • Harvest credentials
  • Deploy digital skimming attacks

Code libraries

The code supply chain is analogous to the business supply chain. Nearly every developer includes third-party code scripts, including the developers of the script that you’re using. The further away from the original developer you are, the harder it becomes to trace the original script.

For example, Developer A uses code from the repository “FreeStuff.” Meanwhile, the “FreeStuff” developer incorporated code from the repository “TotallyFreeCode.” However, for Developer A, the code from “TotallyFreeCode” is a difficult to discover fourth-party script. 

Over time, identifying the original script may be nearly impossible. However, it can still contain a vulnerability that attackers can exploit. 

Get Out of the Shadow (Code)

You don’t have to stop using third-party scripts or libraries, but you should have processes and tools to help you secure your source code. 

Start with Trusted Sources

You can’t stop threat actors from poisoning the code supply stream. However, you should start by vetting all third-party libraries and sources. When reviewing sources, you should look at:

  • Package age and revision history
  • Author’s reputation
  • Number of clones and forks
  • Number of CVEs and resolution times
  • Number of dependencies

Identify All Components

You can’t protect your app against shadow code if you don’t know what you’re using. The lack of visibility across these integrated components is a fundamental reason that the Cybersecurity and Infrastructure Security Agency (CISA) requires a Software Bill of Materials (SBOM) as part of its “Secure Software Self-Attestation Common Form” and “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default” publications. 

Identify All Dependencies

To mitigate risks arising from the additional code sources your third-party components rely on, you should identify all dependencies across your source code. For example, you should look for dependencies across:

  • User inputs
  • Log files
  • Databases
  • Custom code
  • Open-source libraries
  • Software Development Kits (SDKs)
  • Application Programming Interfaces (APIs)
  • Microservices

Automate Vulnerability Scans

You should regularly scan your source code to identify any vulnerabilities across your third-party components and their dependencies. By automating this process, you more accurately identify threats and ship secure applications faster.

Prioritize Remediation Around Reachability

A vulnerability’s existence isn’t always a high priority. You need to know whether attackers can exploit that vulnerability within the context of your source code. With visibility into this reachability, you can reduce the number of vulnerability tickets while speeding time-to-market. 

Qwiet AI: The Light Uncovering Shadow Code

With Qwiet AI’s preZero platform, you can scan millions of lines of code in minutes for visibility into all components, dependencies, and reachable vulnerabilities. Our platform quickly returns accurate and detailed findings while significantly reducing false positives. With our Code Property Graph (CPG), you gain a holistic view of your code, including data flows across the application, to quickly determine reachability and risk impact. 


Take our preZero platform for a free spin to see how Qwiet AI can help you identify shadow code. 

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:


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