Cortex Cloud Application Security discovers and inventories every open-source and third-party software package declared in dependency manifest files across onboarded repositories. Each package detected through Software Composition Analysis (SCA) scanning appears in the unified asset inventory as a governed component of the software supply chain, carrying its identity metadata, version, license type, dependency classification, operational risk rating, and associated CVE vulnerabilities.
The software package asset enables security teams to answer three questions about every dependency: What third-party code does the codebase consume? What is the operational and license risk of each dependency? What known vulnerabilities does each dependency introduce?
Programmatic SBOM export: To support supply chain auditing and compliance workflows, the dependency data inventoried here can be programmatically exported as a machine-readable Software Bill of Materials (SBOM). For automation details, refer to APIs for SBOM management.
Scope: The software package asset represents an open-source or third-party dependency discovered through SCA scanning of onboarded repositories. The software package asset does not represent first-party application code, container image layers, or cloud runtime packages; those asset categories are managed under their respective asset classes.
What software package assets deliver
The software package asset is the foundational unit of supply chain governance in the Cortex Cloud Application Security posture. The software package inventory provides the identity, dependency context, operational risk, and vulnerability telemetry needed to manage every third-party dependency as a governed asset, from discovery through remediation.
Core achievements and use cases
Dependency discovery and identity: Every open-source package declared in a dependency manifest file is automatically discovered and registered in the unified asset inventory with a unique asset identifier, package name, version, package manager, and programming language to serve as the persistent identity record
Supply chain visibility: The asset provides a complete view of the third-party code consumed by each repository, including direct and transitive dependencies, enabling teams to identify which direct dependency introduced a vulnerable leaf package
Operational risk assessment: Each asset carries a risk rating derived from maintenance activity, community popularity, and deprecation status to identify libraries that pose a risk independent of known CVEs
License compliance: The inventory surfaces license types to enable enforcement of organizational policies against strong copyleft or non-permissive licenses
Code to cloud lineage: The package asset participates in the relationship graph as a child of the repository, establishing traceability from the code declaration through to deployed cloud resources
Functional responsibilities
The software package asset model facilitates a structured delegation between Governance and Operations:
AppSec managers (Governance): Review the inventory to identify systemic supply chain risks such as deprecated packages or license violations and define unified policies to enforce compliance standards
AppSec practitioners (Operations): Investigate package-level vulnerabilities, trace dependency chains to identify root causes, and upgrade or replace vulnerable packages to meet SLA requirements
Relationship model
The Cortex Cloud platform models the following relationships between the software package asset and other asset categories:
Related asset category | Inherited metadata and description |
|---|---|
Repository (Parent) | The repository that declares the software package in a dependency manifest file, providing the inherited business criticality and application association |
Software package (Sibling) | Other software packages declared in the same repository that share the same repository context and tags |
CVE vulnerability issue (Downstream) | CVE vulnerabilities detected in the software package by the SCA scanner |
License issue (Downstream) | License compliance violations detected in the software package by the SCA scanner |
Operational risk issue (Downstream) | Operational risk findings such as deprecation or low maintenance detected in the software package |
Limitations
Review the following limitations before investigating and managing software package assets:
Limitation | Description |
|---|---|
SCA scanner required | Software package assets are only created through SCA scanning. Repositories with the SCA scanner disabled do not generate software package assets in the asset inventory |
Dependency manifest scope | Software packages are discovered from dependency manifest files, so packages installed through non-standard mechanisms, vendored dependencies, or dynamically resolved dependencies may not be detected |
Transitive dependency depth | The depth of transitive dependency resolution depends on the package manager and the dependency manifest format |
Operational risk data freshness | Operational risk ratings are updated during periodic scans and may not reflect real-time changes in the package registry between scan cycles |
License detection accuracy | License types are extracted from package metadata in the registry, meaning packages with missing or ambiguous declarations may display incomplete information, and manual verification is recommended for compliance |
Third-party SCA data integration scope | Third-party SCA integrations contribute CVE vulnerability findings to software package assets but do not create the assets in the inventory, nor do they provide operational risk or license data |