“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.