Skip to main content

​
Overview

  • What it Does: Dependency Scanning, also known as Software Composition Analysis (SCA), automatically identifies known security vulnerabilities in your project’s third-party dependencies and libraries. It scans dependency manifest files (like package.json, requirements.txt, pom.xml) and provides detailed vulnerability information including CVE identifiers, CVSS scores, and remediation guidance.
  • Who it’s For: This feature is designed for security teams, developers, DevOps engineers, and anyone responsible for maintaining secure software applications. It’s particularly valuable for teams managing projects with numerous third-party dependencies who need to stay informed about security vulnerabilities that could impact their applications.

​
Key Features and Benefits

  • Comprehensive Ecosystem Coverage: Scans dependencies across 25+ programming languages and ecosystems including Python, JavaScript/Node.js, Java, Go, Ruby, PHP, C#, Swift, and many more
  • Authoritative Data Sources: Leverages multiple trusted vulnerability databases including:
    • GitHub Advisory Database (CC-BY 4.0)
    • PyPI Advisory Database (CC-BY 4.0)
    • Go Vulnerability Database (CC-BY 4.0)
    • Rust Advisory Database (CC0 1.0)
    • Global Security Database (CC0 1.0)
    • OSS-Fuzz (CC-BY 4.0)
    • Rocky Linux (BSD)
    • AlmaLinux (MIT)
    • Haskell Security Advisories (CC0 1.0)
    • RConsortium Advisory Database (Apache 2.0)
    • OpenSSF Malicious Packages (Apache 2.0)
    • Python Software Foundation Database (CC-BY 4.0)
    • Bitnami Vulnerability Database (Apache 2.0)
    • Ubuntu (GPL v3)
    • And many more authoritative sources
  • Rich Vulnerability Intelligence: Provides detailed vulnerability information including:
    • CVE identifiers and alternative vulnerability IDs
    • CVSS scores and severity ratings (Critical, High, Medium, Low)
    • Affected package versions and available fixes
    • Detailed vulnerability descriptions and references
    • Advisory links from sources such as GitHub Advisory Database, NVD, and vendor security advisories when available
    • Publication dates and external links
  • Smart Scanning Logic: Automatically detects when dependency files are present and optimizes scanning performance

​
Setup Instructions

Project must contain at least one supported dependency file and appropriate permissions to run security scans.

​
Configuration Steps

1

Verify Dependency Files

Ensure your project contains supported dependency files:
2

Configure Scan Scope

Choose whether to include dependency scanning in full or partial scans
3

Set Up Notifications

Configure how you want to be notified of new vulnerabilities

​
Usage Guide

Viewing scan dependencies, downloading SBOM files, and exporting dependency CSVs require the View SCA Issue permission. If Project Access Control is enabled, you must also have access to the project.

​
Key Workflows

  1. Automatic Detection: The system automatically identifies dependency files in your project directory
  2. Comprehensive Scanning: Analyzes all supported dependency files and cross-references against vulnerability databases
  3. Vulnerability Processing: Processes scan results and enriches with additional security intelligence
  4. Issue Creation: Creates trackable security issues for each vulnerability found
  5. Reporting: Generates comprehensive vulnerability reports with actionable remediation guidance

​
Dependencies View Filters

Dependencies View Use filters on the Dependencies view to narrow SCA results:
  • Search: Find issues by CVE, package name, or summary
  • Severity: Focus on Critical, High, Medium, or Low findings
  • SLA Status: Focus on dependency issues that are overdue or escalated when an SCA SLA applies
  • Ecosystem: Limit results to a specific package ecosystem
  • Project: Filter to a specific project by name (shows only projects you can access)
  • License: Filter by dependency license
  • Dependency Type: Show direct, transitive, dev, or optional dependencies
  • Reachability: Show issues that are reachable, unreachable, unused, or still being analyzed (see Reachability Analysis)
  • Fix Available: Show only issues with a known fix
Scans Affected counts the distinct scans in which a vulnerability was detected, even when the same scan finds it in multiple packages or manifests.

​
Export Dependencies to CSV

Click Export CSV on the Dependencies view to download the results that match your current search and filters. The export includes package and vulnerability details, dependency type and reachability, project and branch, and the affected manifest path. When Project Access Control is enabled, the export includes only projects you can access.

​
Transitive Dependencies

Most vulnerabilities in modern projects live in transitive dependencies — packages you never added directly, but that were pulled in by the packages you did add. Corgea resolves the full dependency graph so you can see exactly what your application depends on and why.

​
Dependency Types

In scan results, package groups include badges that show where a vulnerable dependency comes from:
  • Direct: The vulnerable package is a direct dependency declared in your manifest (for example, package.json or pom.xml).
  • Transitive: The vulnerable package is pulled in indirectly through another dependency.
  • Dev: The vulnerable package is used as a development dependency (build, test, or tooling) rather than at runtime.
  • Optional: The vulnerable package is marked as an optional dependency.
On the SCA issue details page, the dependency type is shown alongside issue details. A Sub-dependencies badge is shown when the selected package has nested dependencies.

​
How the Dependency Graph Is Built

Corgea builds the dependency tree by combining the packages you declare with the packages your build actually resolves:
  1. Direct dependencies are read from your manifest files (package.json, pom.xml, requirements.txt, go.mod, Gemfile, and others).
  2. Transitive dependencies are resolved from lock files (such as package-lock.json, yarn.lock, poetry.lock, go.sum) and a generated Software Bill of Materials (SBOM), which capture the exact resolved versions and their parent-child relationships.
  3. When a lock file is missing, Corgea attempts to generate one automatically for supported ecosystems (for example, resolving Python or .NET dependencies) so transitive packages can still be analyzed.
Each dependency records the parent that introduced it and the root direct dependency it traces back to, which lets Corgea show the complete path from your manifest to the vulnerable package.

​
Dependency Tree View

The Dependencies view can render your dependencies as a collapsible tree, so you can expand a direct dependency to see everything it pulls in:
Searching in the tree view highlights matching packages and keeps their ancestors visible, so you can always see why a vulnerable package is present. For very large projects (more than ~10,000 dependencies), the tree view is not rendered for performance reasons; use the list and search views instead.

​
Supported Ecosystems

The dependency scanning feature supports the following ecosystems:
  • AlmaLinux - Enterprise Linux packages
  • Alpine - Alpine Linux packages
  • Android - Android app dependencies
  • Bitnami - Bitnami application packages
  • crates.io - Rust packages
  • Curl - cURL library vulnerabilities
  • Debian GNU/Linux - Debian packages
  • Git - Git repositories (including C/C++)
  • GitHub Actions - GitHub Action workflows
  • Go - Go modules and packages
  • Haskell - Haskell packages
  • Hex - Elixir packages
  • Linux kernel - Linux kernel vulnerabilities
  • Maven - Java Maven dependencies
  • npm - Node.js packages
  • NuGet - .NET packages
  • OSS-Fuzz - Google’s continuous fuzzing service
  • Packagist - PHP packages
  • Pub - Dart packages
  • PyPI - Python packages
  • Python - Python language vulnerabilities
  • R - R packages (CRAN and Bioconductor)
  • Rocky Linux - Rocky Linux packages
  • RubyGems - Ruby packages
  • SwiftURL - Swift packages
  • Ubuntu OS - Ubuntu packages

​
Multi-Ecosystem Project Example

Enterprise Application Structure

​
Vulnerability Severity Breakdown

Critical: Immediate action required, potential for complete system compromise
  • High: Should be addressed promptly, significant security impact
  • Medium: Should be addressed in regular maintenance cycles
  • Low: Minor issues that can be addressed when convenient

​
Reachability Analysis

A vulnerable package in your dependency tree does not always mean your application is actually exposed. Reachability analysis helps you prioritize by determining whether a vulnerability can actually be triggered by your code. For each vulnerable direct dependency, Corgea answers two questions:
  1. Is the package used? Corgea looks for imports and usages of the package in your code. A package that is declared but never imported carries much lower risk.
  2. Is the vulnerable function reachable? For packages that are used, Corgea analyzes whether your code actually calls the specific functions affected by the vulnerability.
Corgea treats utility libraries and frameworks differently. For utility libraries, it can look for direct calls to the vulnerable functions. For frameworks — where the vulnerable code runs deep inside the framework’s own internals rather than through a function you call directly — reachability is reported as unsure, because a definitive answer isn’t possible from your code alone.
Reachability analysis runs on direct dependencies. Vulnerabilities in transitive dependencies are reported and can be fixed (see Fix Recommendations) but are not individually reachability-analyzed.

​
Reachability States

Each analyzed issue resolves to one of the following states, which you can also use as filters on the Dependencies view:
  • Reachable: Your code calls the vulnerable functionality. These are the highest priority — especially for direct dependencies.
  • Unreachable: The package is used, but the vulnerable functions are not called.
  • Unused: The package is declared but not used in your code.
  • Analyzing: Reachability analysis for the issue is still in progress.

​
Reachability Visualization

For reachable issues, Corgea can render the path from your application’s entry points to the vulnerable code — showing how execution flows from endpoints through intermediate functions to the vulnerable function. This makes it easy to understand and validate exactly why an issue is reachable.

​
Fix Recommendations

When a fix is available, Corgea recommends the nearest fixed version — the lowest version that resolves the vulnerability — shown alongside the version you currently have installed. Recommending the nearest safe version keeps the upgrade as small as possible and reduces the chance of breaking changes. For direct dependencies, you can apply the fix by updating the version in your manifest. For transitive dependencies, you often cannot bump the version directly because it is controlled by a parent package. In these cases, Corgea surfaces the dependency path and the parent dependency you need to upgrade so the fixed transitive version is pulled in. See Transitive Dependencies for how the dependency path is built.
Fix recommendations for dependencies are guidance for how to remediate. Review upgrades for compatibility before applying them.

​
License Scanning

During dependency scanning, Corgea captures the software license associated with each dependency, giving you visibility into the licenses present across your project. Licenses are surfaced in two ways:
License scanning provides a license inventory for visibility and reporting. It does not automatically enforce license-compliance policies.

​
Container Image Scanning

Corgea also scans the container images your project depends on, identifying vulnerabilities in base operating system packages and other software installed within image layers. Images are automatically discovered from Dockerfile and Docker Compose files — no configuration required. For details on discovery, supported registries, and limits, see Container Image Scanning.

​
Malicious Package Detection

As part of dependency scanning, Corgea flags known malicious and compromised packages — such as typosquats, hijacked releases, and backdoored versions — using the OpenSSF Malicious Packages database and related advisory feeds. For details, see Malicious Package Detection.

​
Best Practices

Enable automatic scanning to catch new vulnerabilities as they are disclosed in real-time.
  • Regular Scanning: Enable automatic scanning to catch new vulnerabilities as they are disclosed
  • Dependency Updates: Promptly update dependencies when fixes are available for identified vulnerabilities
  • Severity Prioritization: Focus on addressing Critical and High severity vulnerabilities first
  • Risk Assessment: Evaluate whether vulnerabilities actually affect your application’s attack surface
  • Dependency Hygiene: Regularly review and remove unused dependencies to reduce attack surface
  • Version Pinning: Use specific version numbers in dependency files for consistent scanning results
  • Monitoring: Set up alerts for new vulnerabilities discovered in your dependencies
  • Documentation: Maintain records of accepted risks and remediation decisions

​
Troubleshooting

Solution: Verify that dependency files are in supported formats and contain valid package informationCheck: Ensure dependency files are not corrupted or contain syntax errors
Solution: Check that all dependency files are included in the scan scopeCheck: Verify that dependency files are properly formatted and accessible
Solution: Review vulnerability details to determine if they actually affect your applicationCheck: Consider the specific usage patterns and attack vectors in your application
Solution: This is normal for large projects with many dependenciesCheck: Consider using incremental scanning for changed files only