TraceGuardDocs

Inventory

Components, dependencies, and licenses across your projects.

Once a BOM is parsed, its contents become a searchable inventory you can explore at the project and organization level.

Components

The Components view lists every package and part across your BOMs, with the projects and versions where each appears. Use it to answer "where do we use this package?" in seconds — essential when a new advisory drops.

Open a component to see its versions, the BOMs it came from, associated vulnerabilities, and any component overrides you've applied (for example, to correct or annotate metadata that a generator got wrong).

A part that shows no vulnerabilities is not always safe: it may be unidentified. See Identifying components for what to fill in.

Secure
app.traceguard.io/…/components

Dependencies

Dependencies capture the relationships between components — direct vs. transitive, and who pulls in what. This is what lets TraceGuard tell you whether a vulnerable package is something you depend on directly or inherited several layers down.

Licenses

The Licenses view aggregates the licenses found across your components, so you can spot copyleft or unknown-license obligations. Open a license to see exactly which components carry it.

Is it all good? The Licences page opens with one verdict line, org-wide and per project: All licences allowed by your policy, N components need review (M without licence information), or N components use a licence that is not allowed by your policy. The line is computed from the same dispositions as the table below it, so it never disagrees with the detail. Components whose BOM carries no licence information (NOASSERTION, NONE, empty) count as "without licence information" and are treated as review until someone records a decision. The management view and the MCP tool license_exposure return the same verdict.

Every component gets a license verdict: Allowed, Needs review, Not allowed or Not applicable. It is decided in this order:

  1. A manual review on the component (Approved, Needs review or Rejected), set in its BOM. Nothing sets this automatically.
  2. Your organization's license policy for the component's license category (Decisions → License policy; owners and admins can change it).
  3. The default policy:
CategoryExamplesDefault
PermissiveMIT, Apache-2.0, BSD, ISCAllowed
Public domainCC0, UnlicenseAllowed
Weak copyleftLGPL, MPL, EPL, EUPLAllowed (the category stays visible)
Strong copyleftGPLNeeds review
Network copyleftAGPL, SSPLNeeds review
Proprietary or source-availableProprietary, BUSL, non-commercialNeeds review
UnknownNo license declared, unrecognisedNeeds review

The default never says Not allowed; only your own policy can. A hardware part without a license is Not applicable and is not counted as a license risk; firmware without a license still needs review.

A license expression is read with SPDX precedence: parentheses first, and AND binds tighter than OR. Each OR branch counts as its most restrictive license (every AND obligation applies), and the expression takes the least restrictive branch, because you may choose it. So MIT OR Apache-2.0 and MIT OR (GPL-3.0-or-later AND MIT) are permissive, GPL-2.0-only AND LGPL-2.1-only is strong copyleft, and LGPL-3.0-or-later AND Apache-2.0 is weak copyleft. A branch with an unrecognised license is only taken when no branch is recognised. "Or later" or "or greater" in a license name is part of that license, not a choice. "All rights reserved" reads as proprietary only when the license text has no permissive grant: a pasted BSD or MIT text starts with that copyright line.

The default policy is a starting point, not legal advice. Review it with your legal counsel.

Inventory is read-through from your BOMs: upload a newer BOM and the inventory updates. Per-org data like overrides and decisions lives separately from the shared component records.

Next

Vulnerabilities & scanning turns this inventory into prioritized risk.