Often not. A JAR or DLL referenced by file path carries no registry name or version in the build file, so a manifest scanner has nothing to match. Detection needs file fingerprinting or a manual inventory. Treat checked in binaries as a separate category with its own list.
How binaries end up in repositories
Teams commit libraries when a vendor supplies them directly, when a package is no longer on a registry, or when an old build needed a quick fix. The Gradle documentation shows the pattern for file dependencies: a dependency can name files directly, for example through files with a path such as libs/commons-lang.jar, or a fileTree over a directory. The build works, but the dependency is identified only by a path.
Notice the file names in that documentation example name a library but state no version. Real files often have versions in the name, but that is a convention, not metadata a scanner can trust.
Why a manifest scanner is blind
Registry coordinates such as group, artifact and version let a scanner ask which advisories apply. A path gives none of that. The scanner may see the build line and ignore it, or fail to recognise the library inside the archive.
The Gradle documentation also warns that the order of files in a FileTree is not guaranteed to be stable, even on the same computer, which means builds using file trees can behave inconsistently. Another reason to prefer declared coordinates.
Find them
git ls-files | grep -Ei '\.(jar|war|ear|dll|nupkg)$'
Then search build files for path based dependencies, such as files and fileTree calls in Gradle, system scope in Maven, or direct references in project files.
Identify each one
- Read the archive's own metadata. A JAR usually has a manifest and often a Maven properties file with group, artifact and version.
- Compute a hash and look it up in a public artifact repository index, which can map a hash back to a known release.
- If it is not a known release, it may be a custom build. Record who made it and from what source.
- Note the license too, because it travels with the code.
Fix or record
| Finding | Action |
|---|---|
| Same artifact exists on a registry | Replace with a declared dependency |
| Custom or patched build | Record in inventory with source and diff |
| Vendor supplied only | Record version and vendor contact |
| Nobody knows what it is | Treat as high priority to identify |
Feed the inventory into your SBOM. See copied code and your SBOM and detecting vulnerable code in shaded uber JARs.
Safeguard offers SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan. Test any tool against a committed JAR to see what it reports.
Quick check
Is a version in the file name reliable?
It is a hint. Confirm against the archive's internal metadata or a hash lookup.
Should binaries ever be committed?
Sometimes it is unavoidable. If so, inventory them and review on a schedule.
Sources
Last reviewed: 19 October 2026.
