Untracked dependencies are components within a software project that are not properly identified, monitored, or managed. These dependencies may bypass package management systems or be embedded in upstream components without being documented. For example, they could be snippets of third-party code copied directly into a project, platform-specific binaries included without manifest files, or plugins used during development but overlooked during security reviews.

Because they are "invisible" to traditional tracking and scanning tools, untracked dependencies cannot be assessed for vulnerabilities or updates, increasing the risk of unresolved security flaws, operational disruptions, or licensing conflicts.

In this lesson, you will learn how untracked dependencies arise, why they pose risks to application security, and how to protect your projects against these risks. We will explore a real-world example to demonstrate the challenges posed by untracked dependencies and practical mitigation strategies to manage them effectively.

David is a software engineer working on a web-based financial platform. One of the platform's key features is a client-side data visualization tool that uses a JavaScript charting library. David notices that the chart rendering performance has degraded over time and decides to investigate the library.

While reviewing the project files, David discovers an unexpected fil,. custom_utils.min.js, a minified JavaScript file tucked away in the /libs folder. It was added months ago by a team member to patch a missing feature in the charting library. The problem? It’s not listed in the project’s dependency manifest (package.json), meaning it has flown under the radar during regular dependency scans!

There’s no reference to custom_utils.min.js but David finds it manually referenced in index.html

Curious, David opens the minified file and decodes its contents. To his shock, he finds that the file contains third-party code copied from an outdated version of a well-known library, complete with a comment mentioning the old version number. Further research reveals that this version has a critical vulnerability that could allow attackers to inject malicious scripts into the application.

Realizing the risk, David raises the issue with his team. They agree to:

• Remove the untracked dependency
• Update the charting library to a properly tracked version
• Ensure that any future patches are managed through the package manager to avoid similar issues

Let’s break down what happened in David’s scenario and examine how untracked dependencies like custom_utils.min.js can pose significant risks to a project.

Untracked dependencies often bypass the typical mechanisms used to manage and monitor components in a software system. In David's case, the inclusion of a minified file directly into the project’s lib directory created a blind spot. The file wasn’t declared in the dependency manifest (package.json), so it was invisible to the SCA tools scanning the project for vulnerabilities and updates.

How the untracked dependency became a risk

Initially, instead of utilizing the charting library's official APIs or extensions, a team member opted to copy an outdated utility function from another library and include it as a standalone file. This approach, known as "vendoring," bypassed the safeguards of package managers and versioning systems, leaving the code disconnected from updates or vulnerability monitoring. The outdated utility function in the library contained a known vulnerability that allowed attackers to inject arbitrary JavaScript. This flaw exposed the financial platform to the possibility of cross-site scripting (XSS) attacks, potentially compromising users. Because the dependency wasn’t documented or tracked, the development team remained oblivious to this critical security weakness.

To add to this, the custom_utils.min.js file was excluded from the project's package.json or any other dependency manifests. This lack of visibility rendered it invisible to regular audits and security scans, which would have otherwise flagged the file for vulnerabilities or updates.

This snippet demonstrates how an outdated utility file (custom_utils.min.js) was manually added to the project and used in the code. The escapeHTML function attempts to sanitize user input but fails to account for cases like embedded event handlers (e.g., <img src="#" onerror="alert(1)">). Since the dependency is untracked and not included in package.json, it remains hidden from SCA tools and vulnerability scans, allowing exploitable flaws to persist unnoticed.

In this Python example, an untracked script (unmanaged_dependency.py) contains a basic function for sanitizing HTML input. The function uses a naive replacement strategy that fails to address complex attack vectors like encoded scripts or event handlers. This dependency wasn’t added through a package manager like pip, so it escapes regular updates and scans, leaving the application exposed to XSS vulnerabilities.

This PHP script includes an untracked file, custom_helpers.php, which contains an outdated sanitizeInput function. While htmlspecialchars is generally useful, it doesn’t protect against all modern XSS vectors, such as <img src="#" onerror="...">. The manual addition of this file without proper version control or inclusion in composer.json ensures that it remains invisible to dependency management and vulnerability assessments.

This C# code uses a helper file (LegacyHelper.cs) added manually to the project without proper tracking in tools like NuGet. The escaping logic within EscapeHtml is overly simplistic and doesn’t address more sophisticated attack methods. This unmanaged dependency is not part of any central repository or package manager, making updates and vulnerability scans difficult.

In this Go example, the file unmanaged_helpers.go was manually added to the project and is not tracked in a dependency manifest like go.mod. The EscapeHTML function uses simple string replacements to sanitize HTML input but does not account for encoded or nested scripts. This outdated and untracked dependency bypasses regular vulnerability scans, exposing the application to XSS risks.

The UnmanagedUtils.java file was manually added to the project and isn’t managed through a build tool like Maven or Gradle. The sanitizeInput method implements an outdated and simplistic approach to sanitization, leaving the application vulnerable to injection attacks. Because the file is not declared in pom.xml or build.gradle, it remains outside the scope of dependency checks and updates.

The file unmanaged_helpers.h contains a manually added function that performs basic HTML escaping. This simplistic function does not properly handle encoded scripts or nested tags. Because the file is not part of a managed build system like CMake or a package manager like vcpkg, it remains untracked and overlooked during vulnerability scans, leaving the application susceptible to XSS attacks.

Untracked dependencies pose significant risks to the security, maintainability, and functionality of software projects. Since these dependencies bypass standard tracking mechanisms, they are often excluded from vulnerability assessments and software composition analysis (SCA). This can lead to outdated or vulnerable code persisting unnoticed in a system. In the event of a security breach, identifying the root cause becomes challenging, prolonging the time needed for remediation.

Furthermore, untracked dependencies can result in software licensing conflicts. Without proper documentation, teams might unknowingly use code under restrictive licenses, leading to potential legal and financial liabilities. Additionally, operational risks emerge when updates or patches for these dependencies are missed, causing compatibility issues or software failures. Overall, untracked dependencies undermine the integrity of the software supply chain, making systems more susceptible to security threats and operational inefficiencies.

In the example above, David and his team tackled the issue by addressing both the immediate risk and the underlying practices that had allowed it to occur. Their first step was to remove the custom_utils.min.js file entirely, replacing its functionality with an officially supported and updated feature from the charting library. This ensured that the application relied only on secure and actively maintained components.

To prevent similar incidents in the future, the team enhanced their software composition analysis (SCA) tooling. By reconfiguring the tools to include non-manifest files in their scans, they ensured that previously overlooked dependencies would now be detected during audits. A new policy was implemented requiring that all dependencies, regardless of their origin or purpose, be declared in a manifest file and thoroughly reviewed before being integrated into the project. These changes not only addressed the current issue but also fortified the team’s processes against future risks.

General mitigation strategies

Mitigating the risks associated with untracked dependencies requires a combination of better tooling, stricter processes, and proactive monitoring. Implementing a comprehensive software composition analysis (SCA) tool that scans for files outside of dependency manifests is a critical first step. These tools should be configured to identify hidden libraries, embedded binaries, or source code fragments that may have been manually included.

Integrating robust governance practices into the development lifecycle is equally essential. Teams should establish policies mandating that all dependencies be explicitly declared in manifest files such as package.json, requirements.txt, or pom.xml. Any third-party code, even temporary additions, should undergo the same scrutiny as formally managed dependencies. Regular reviews of the project’s software bill of materials (SBOM) help ensure complete transparency and traceability of all components.

Finally, promoting a culture of awareness around secure development practices can help prevent untracked dependencies from entering a project. This includes educating developers on the risks of manual inclusion of code and encouraging the use of official package repositories and APIs whenever possible.

Mitigated code

The outdated custom_utils.min.js file has been replaced with the widely used and actively maintained sanitize-html library from npm. This ensures the dependency is tracked in the package.json file, regularly audited by SCA tools, and kept up-to-date to address potential vulnerabilities.

The untracked unmanaged_dependency.py file has been replaced with bleach, a widely trusted Python library for sanitizing HTML. By using a dependency installed via pip, it becomes part of the requirements.txt file and is subject to regular audits and updates.

The manually added custom_helpers.php file has been replaced with the voku/portable-ascii package, a reliable library installed via Composer. This ensures the dependency is listed in composer.json, making it easier to monitor and update.

The untracked LegacyHelper.cs file has been replaced with HtmlSanitizer, a well-maintained library added via NuGet. The dependency is now included in the project’s dependency manifest (*.csproj) and benefits from regular updates and audits.

The manually added unmanaged_helpers.go file has been replaced with the bluemonday library, which is installed and tracked via the Go module system (go.mod). This ensures the dependency is included in dependency scans and benefits from upstream updates.

The UnmanagedUtils.java file has been replaced with OWASP Java Encoder, a reliable library included in the Maven build system (pom.xml). This ensures the dependency is centrally managed and benefits from regular updates and vulnerability assessments.

The outdated unmanaged_helpers.h file is replaced with a third-party library like htmlcxx, installed via a package manager and included in the CMakeLists.txt. This ensures the dependency is tracked, updated, and regularly scanned for vulnerabilities.

To deepen your understanding of untracked dependencies and related risks, explore these resources:

• OWASP Software Component Verification Standard (SCVS): Learn about inventory and bill of materials best practices.
• The National Vulnerability Database (NVD): Search for known vulnerabilities affecting software dependencies.
• Learn more about this specific vulnerability from OWASP