Dependency Scanning
Overview
Section titled “Overview”Dependency scanning identifies the open-source and third-party packages your repositories rely on, then checks them against known vulnerability databases and license risk criteria. Every time a code scan runs, Fencer catalogs each package — its version, license, ecosystem, and position in your dependency tree — so you can spot outdated, vulnerable, or legally risky components at a glance.
This capability is central to software supply chain security: you cannot fix what you cannot see, and transitive dependencies often carry more risk than direct ones.
Prerequisites
Section titled “Prerequisites”- A plan that includes dependency scanning.
- At least one source code integration connected (GitHub, GitLab, Bitbucket, Azure DevOps, Cursor Origin, or a generic Git repository).
- Repositories imported and scanned via Code Scanning.
How it works
Section titled “How it works”During a code scan, Fencer catalogs every package in your repository, with its version, license, and relationship in the dependency tree, and checks each one for known CVEs.
Each discovered package is recorded as a Package with a unique Package URL (PURL). A Dependency links that Package to a specific repository and file path, tracking when it was first seen and whether it is a root, direct, or transitive dependency. The dependency inventory follows each repository’s default branch: packages that appear only on other branches are not listed. When a dependency disappears from a later scan of the default branch, Fencer marks it as removed rather than deleting it, preserving your audit trail, and it no longer appears in the list.
Usage / Configuration
Section titled “Usage / Configuration”Viewing dependencies
Section titled “Viewing dependencies”- Go to Posture > Dependencies. To see one repository’s dependencies, open the repository on Posture > Code and select its Dependencies tab.
- The All tab lists every current dependency across your scanned repositories, with its package name, current and latest version, visibility, location, ecosystem, repository, license, license category, risk, and when it was first seen.
- The Grouped tab groups dependencies by Package or by Location (use the Group by toggle).
- Click any row to open the dependency details, which show the package information and the dependency graph.
Filtering dependencies
Section titled “Filtering dependencies”Use the advanced filter bar to narrow results by any combination of:
| Filter | Description |
|---|---|
| Repository | The repository asset containing the dependency |
| Package | A specific package by name |
| Ecosystem | The package type reported for the dependency (for example npm, python, or go-module) |
| Language | Programming language — Python, JavaScript, Ruby, PHP, Java, C, C++, C#, Dotnet, Go, Rust, Scala, Kotlin, Swift, Dart, TypeScript, or Other |
| License | The SPDX license identifier |
| License Category | Risk grouping — Unknown, Permissive, Weak Copyleft, Strong Copyleft, Commercial, Proprietary, or Other |
| Visibility | Public or Private |
| Dependency Type | Root, Direct, Transitive, or Unknown |
| Revoked | Whether the package has been revoked from its registry |
| End of life | Whether the package version has reached end of life or will within 30 days |
| Support ended | Whether support for the package version has ended |
| First Seen | Date the dependency was first detected |
You can also use the free-text search to match on package name, version, file path, repository name, or license.
Dependency details and graph
Section titled “Dependency details and graph”The dependency details show:
- Package Information — the package ID (PURL), the source link for public packages, type, ecosystem, visibility, and when it was first and last seen.
- Dependency Graph — a reverse dependency tree showing which packages depend on this one. Click a package in the tree to highlight its path, so you can trace the route from your direct dependencies down to a transitive package.
- Asset Information — the repository, branch, and file location where the dependency was found.
- License Information — the license, its category, and a description of the license risk.
Downloading an SBOM
Section titled “Downloading an SBOM”Fencer can generate a Software Bill of Materials for any scanned repository in industry-standard formats:
- On the Dependencies page, click Download SBOM.
- Select the Repository and choose a Format — CycloneDX or SPDX.
- Click Download. The SBOM is taken from the repository’s most recent finished scan of its default branch and downloads as a JSON file.
Scan failure conditions for dependencies
Section titled “Scan failure conditions for dependencies”You can configure code scans to fail based on dependency criteria. Open the repository’s Settings tab and go to Checks:
- Fail on EOL — fails the scan if a package will soon be end-of-life.
- Fail on license risk — fails when an added package carries a risky license (Strong Copyleft, Any Copyleft license, Any Commercial or Copyleft license, or Any non-proprietary license).
See Code Scanning — Scan Configuration for the full list of failure conditions.
Examples
Section titled “Examples”Finding all strong-copyleft dependencies
Section titled “Finding all strong-copyleft dependencies”- Open the Dependencies page.
- Add a filter: License Category is Strong Copyleft.
- Review the results to identify any GPL or AGPL-licensed packages that may conflict with your project’s licensing terms.
Tracing a transitive vulnerability
Section titled “Tracing a transitive vulnerability”When a vulnerability is reported against a transitive dependency:
- Search for the package name in the Dependencies page.
- Open the dependency details.
- Use the Dependency Graph to identify which direct dependency pulls it in.
- Decide whether to update the direct dependency, pin a patched version, or ignore the vulnerability.
Troubleshooting
Section titled “Troubleshooting”- No dependencies shown — Verify that your repositories have completed at least one successful code scan of their default branch. Dependencies are only populated after a scan finishes.
- SBOM download unavailable — The selected repository needs a finished scan of its default branch. Run a scan if the repository was imported after the last scan cycle.
- Dependency still listed after removal — Removed dependencies drop out of the list after the next finished scan of the default branch. Removing a package on another branch doesn’t change the list until that change reaches the default branch.
- License shown as “Unknown” — Some packages do not declare a machine-readable license. Fencer enriches license data when possible, but manual review may be needed for packages with non-standard license declarations.