Packages and Risk

The Packages page is the inventory: every package version this workspace has pulled through the proxy or reported through the scanner, with what ShieldedStack knows about each one. It is where you go to answer “what are we actually running, and which parts of it should worry us”.

The package inventory, on a view tuned for triage rather than browsing.

Finding Things

Search matches on package name and license, and narrows as you type. Filters for project and ecosystem stack on top of it. Filters persist as you move around the console, so a project filter set on the inventory is still there when you come back.

Views

The view picker above the table switches the columns and sort in one click, so the same inventory can be read four different ways:

View	Shows	Sorted by
Default	A general-purpose inventory listing	Package name
High Risk	Risk score alongside its contributing signals	Risk score, worst first
Outdated	Version age and how far behind latest each package is	Publication date, oldest first
Security	Advisory counts and CVSS	Highest CVSS first
All	Every available column	Package name

Columns adjusts which columns are shown, and a column selection you expect to reuse can be saved as a named view of your own. Export takes the current filters and columns out as CSV or JSON.

Risk Score

Each package version carries a risk score from 0 to 10, where higher is worse, grouped into Low, Medium, High, and Critical bands. It is a triage aid: a single number that puts a long inventory into a defensible order when you cannot review all of it at once.

The risk score summarises three dimensions. The breakdown behind it is what you act on.

The number is the summary, not the argument. Hover any risk score to see the breakdown: for each dimension, the level it reached, the primary driver behind it, and the reasoning. A 7.8 driven by an unpatched critical advisory and a 7.8 driven by a package that has not shipped in four years are the same number and completely different problems, and the breakdown is what tells them apart.

Do not wire a build gate to the score. Blocking is what Minimum Package Block Level and package filters are for, and those are deterministic and explainable to whoever’s build just failed. See Policy and Enforcement.

Package Details

Selecting any package opens its detail page, with a version picker and four tabs.

• Overview summarises the package: current risk, license, publication dates, and the headline signals.
• Versions lists every version seen, with its advisory count and risk, so you can see whether the problem is the package or the specific version you pinned.
• Security lists the advisories affecting the selected version, with severity, description, and the first patched version. Vulnerability exceptions are added from here as well as from an alert.
• Usage shows which projects use the package and which versions they pull. This is the “who does an upgrade affect” tab.

The Security tab for a single version, where exceptions are recorded against a specific advisory.

Focused Views

Three pages narrow the inventory to one question each.

Risky Packages ranks the inventory by risk score. It is the starting point for a scheduled review when nothing is actively on fire.

Outdated Packages surfaces versions that lag behind current upstream releases, including deprecated ones. Age is a leading indicator: dependencies that fall far enough behind become expensive to patch in the moment you most need to patch them.

CVEs, titled Security Advisories, is the advisory-centric view of the same data. Where the Packages page asks “which of our packages are affected”, this page asks “which advisories affect us, and what do they touch”. Search across package name, advisory identifier, and summary, and filter by project and ecosystem. Use it when a disclosure hits the news and you need to know within a minute whether it reaches you.

Licenses

The Licenses page inventories the licenses in use across the workspace, with a risk classification of High, Medium, Low, or Unknown, the license type, and the projects each one appears in. Filter by project, license type, or risk.

Two things make it worth checking regularly rather than at audit time:

• Unknown is a finding, not a gap in the display. A dependency whose license could not be determined is one you cannot make a compliance statement about.
• A license that changes between versions raises a License Change alert, so a routine upgrade that quietly moves a dependency to a more restrictive license gets caught while the upgrade is still reversible.

For an inventory to hand to legal or a customer, use Exports and SBOM rather than copying from the table.