Findings in the portal

The portal keeps each scan that you send, matches it with the advisory data and the TuxCare catalogue, and shows what to fix first. This page tells you how to read the findings, triage them, track the fix deadlines and the CRA clocks, record releases, and get alerts.

Go to your workspace address, for example https://name.sc.tuxcare.cloud, and select the button of your sign-in provider. If an admin added a single sign-on provider, the page shows its button too. You can also sign in at sc.tuxcare.cloud and open the workspace from Your workspaces. A person who has not accepted the terms sees the terms page after the first sign-in. Read it, then select Accept and continue. The portal asks one time for each workspace, and again only when TuxCare publishes new terms. The acceptance covers the SecureChain CLI for this workspace. An admin sees the date of each person in the Terms accepted column of the Users page.

The workspace menu is the button at the right of the header. It shows your role. It holds the pages that manage the workspace, Help (this guide), and Sign out.

The header of the portal with the workspace menu open: the email address and the role, the Manage list, Help, and Sign out. — The workspace menu, open.

The button of the menu. It shows your role, and on a wide screen your email address.

Manage: the pages that manage the workspace. An admin sees all of them.

Help opens this guide. Sign out ends the session.

The theme control: System, Light, or Dark. On a narrow screen, it is in the workspace menu.

To end a session on another device, open Access tokens in the workspace menu and select Sign out on the row of the session in Browser sessions.

When you ask TuxCare for help, a TuxCare engineer can open a read-only view of your workspace. A banner shows TuxCare staff — read only during that view.

Roles #

Each user has one role for the whole workspace.

Action	Admin	Member	Viewer
Read repositories, scans, and findings	Yes	Yes	Yes
Send scans	Yes	Yes	No
Triage findings, set the default branch, mark releases, record a CRA decision	Yes	Yes	No
Make and revoke their own tokens	Yes	Yes	Yes
Make scoped tokens and tokens for other users	Yes	No	No
Register, rename, and delete repositories; manage products and product releases	Yes	No	No
Manage users, departments, notifications, fix deadlines, and settings; read the audit log	Yes	No	No

A member or a viewer with a seat in a department sees only the repositories of that department. A user with no seat sees every repository. Every number in the portal counts only the repositories that you can see.

Find your way #

The top bar has six pages. Each page answers one question:

Page	The question
Overview	How is the workspace now, and does it get better or worse?
Repositories	Which repositories need work, and what is wrong in one repository?
Vulnerabilities	Which advisories affect us, and where? Are we affected by a given CVE?
Packages	Where do we use a package, and at which versions? What do the TuxCare builds cover?
Remediation	Do the teams fix the findings before the fix deadline?
Compliance	Which findings start a CRA clock, and which reports does an auditor need?

On a narrow screen, select Menu to see the six pages and the search field.

Search #

The search field in the header finds an advisory, a package, or a repository. Press / to go to it. Type the text, then select the page to search. Press Enter to open the first choice.

An advisory id, for example CVE-2021-23337 or GHSA-35jh-r3h4-6jhm, searches Vulnerabilities first.
A name and a version range, for example lodash@<4.17.21, searches Packages first.
A path, for example acme/web-shop, searches Repositories first.

Most pages keep their filters in the page address. Copy the address to share a filtered view. Select the ? button next to a label to read what the label means.

Overview #

The Overview is the first page. It shows the security state of the workspace for a department and a period (the last 30, 90, or 180 days).

Open findings: The open findings of every repository, the change in the period, and a bar of the severities.
Critical · known exploited: The open critical findings and the open known-exploited findings. The line under them counts the open CRA clocks.
Past fix deadline: The open findings that are older than their fix deadline, and the share of findings that closed in time.
Fixable now: The open findings that have a fix: an upstream version or a TuxCare build.
Scan coverage: The repositories that sent a scan in the last 7 days. It also counts the stale repositories (no scan for 14 days), the repositories with no scan, and the repositories with a release that is not evaluated.

Open findings by severity shows the open findings of each day. The portal counts them once a day, from the first day of the count.
New and resolved findings shows, for each week, the new findings above the line and the resolved findings below it. An upgrade to a version that has the same advisory does not resolve the finding.
Fix first lists five package upgrades: the package, the repositories, the findings that the upgrade closes, the version to move to, and the source of the fix (upstream, TuxCare ELS, or TuxCare SecureChain). A package with a known-exploited finding comes first. major version marks an upgrade to a new major version.
Repositories that need attention lists the repositories with the worst grade. New in the last 7 days lists the repositories with new open findings.

Repositories #

The Repositories page lists each repository of the workspace. A repository appears when its first scan arrives. An admin can also add one before the first scan with Register repository.

Each row shows the grade, the open findings by severity (for example 1 C · 4 H · 7 M · 0 L), the fixable findings, a 6-week trend, the branch that the row counts, and the age of the last scan. A last scan older than 14 days shows in an amber chip: check the CI job of that repository.

The quick filters keep the rows of one kind: Has critical, Known exploited, Stale scan, or Never scanned. Sort sorts by Risk, Last scan, or Name.

The grade #

Each repository gets a grade from A (good) to F (bad), from the open findings of its tracked refs. The worst rule that applies sets the grade.

Grade	Rule
A	No open critical or high finding, and at most 10 open medium findings.
B	One or more open high findings, all within the fix deadline.
C	An open high finding is past the fix deadline, or more than 10 medium findings are open.
D	One or more open critical findings.
F	An open critical finding is past the fix deadline, or an open finding is known to be exploited.

A repository with no complete, matched scan has no grade. A repository with a release whose match failed never gets grade A. The rules use the fix deadlines of your workspace.

A repository #

Select a repository to open its page. The header shows the grade, the name, the departments, the count of components, the last scan, and the commit. It also names the token and the CLI version that sent the scan, for example sent by ci-main (tux_…ab12), CLI 0.1.18.

The page of the repository github.com/acme/web-shop, with the Findings tab open, the findings grouped by package, and one package selected for bulk triage. — The page of a repository, with the Findings tab open and one package selected.

The branch selector, Compliance report, and More.

The four tiles.

The tabs. Each tab shows its count.

The filters of the findings, and the choice By package or Flat list.

The bar of the bulk triage. It shows when you select a finding.

The header row of a package: the findings, the worst severity, and the upgrade that closes all of them.

Branch: Selects a branch or a tag. All refs (tracked branch) shows the tracked branch: the default branch, else main, else master, else the newest complete scan. The default branch shows · default.
Slot: A slot is one project path and one set of ecosystems. A monorepo branch can have one slot for each CI job that scans it. When a branch has two or more slots, the page shows a Slot list. See More than one project in a repository.
More: Opens the export and the download of the SBOM of the scan. A member or an admin can make the selected branch the default branch. An admin can rename the repository, set its departments, or delete it. A delete removes all scans, findings, and repository tokens of the repository, and cannot be undone.

Right after a scan, the page says that the scan is being matched and shows the last matched scan. The page updates by itself when the match is done.

The tiles show the open findings, the changes since the previous scan (see Changes), the findings that you can fix now, and the findings past their fix deadline.

The Findings tab #

The tab lists each known vulnerability in the scan, the worst first.

Filter by text (a CVE, a package, or a title), by severity, by Exploited, New since last scan, or Past deadline, and by triage state. The default triage filter is not ignored.
By package groups the findings under one header row for each package. The header row shows the upgrade, and closes all when the upgrade closes every finding of the package. Flat list shows one row for each finding.
Select an advisory to open the page of the finding. A member or an admin sees check boxes for bulk triage.

The Fix plan tab #

The fix plan has one row for each package to change: the current version, the version to move to, the source of the fix (a TuxCare build or upstream), the findings that the change closes, and the worst severity. A package with a known-exploited finding comes first. To apply the plan, see Fix vulnerabilities.

The Dependencies tab lists each package of the scan with its version, its ecosystem, its scope (direct or transitive, with the packages that pull it in), its open findings, and its TuxCare status: TuxCare build, TuxCare build available, No TuxCare build, or Not assessed.

The Dependencies tab of a repository, with seven packages. The TuxCare column names the TuxCare build of each package. — The Dependencies tab. The TuxCare column names the build that each package can move to.

Changes since the last scan #

The tile Since scan #N compares the scan with the previous scan of the same branch: for example +3 new and −3 resolved findings. Select Show the changes to see the lists. When a new advisory comes out, the portal checks the stored scans again, so a new finding can show with no new scan.

The Scans tab #

The tab lists each scan of the repository, with its branch, commit, path, status, and dates. Select a scan number to see its findings, dependencies, and fix plan, read only. Select Back to the newest scan to leave that view. Select SBOM to download the scan as a CycloneDX file. A member or an admin can select Mark as release on a complete scan. See Releases.

Only a complete scan feeds the findings and the comparisons. A partial, empty, or failed scan is not a clean result, and the page shows a warning for it.

The base image of a container image #

The page of a container image shows the Base image panel above the tabs. The panel shows:

The base image that the portal found, for example node:20-bookworm, and the start of its digest. Outdated build shows when the tag now points at a newer build.
How many open findings come from the base, for example 2 of 3 open findings come from the base image. The other findings come from the layers that your Dockerfile adds.
A table of the base images that you can move to, and the findings that each one removes and adds.

The Base image panel: the base node:20-bookworm, an outdated build, 2 of 3 open findings from the base, and three upgrade rows: Rebuild with the same tag, Next major version, and Smaller variant. — The Base image panel of an image with an outdated `node:20-bookworm` base.

TuxCare keeps a list of known base images: the official Docker images and the TuxCare images, with the layers and the packages of each build. The portal finds the base of your image in two ways:

By the layers. The portal compares the layers of your image with the layers of each known base image. The base image whose layers start your image, with the most layers, is the base. A match needs two layers or more.
By the declared base. When no layers match, the portal reads the base that the image declares: the annotations org.opencontainers.image.base.name and org.opencontainers.image.base.digest. A digest must be the digest of a known build. A name alone selects the build that the tag points at now.

A finding comes from the base when its package is in the base image. With a match by the layers, a finding also comes from the base when its package is in a layer of the base. The other findings with a known layer come from your layers.

Each row of the table is one kind of upgrade. A row shows only when it removes a finding, except Rebuild with the same tag. When two rows name the same image, the image shows once.

Rebuild with the same tag: The newest build of your tag. It shows when your image uses an older build. Often a rebuild of your image is enough.
Newest in the same line: The newest version with the same major version and variant, for example node:20.18.0-bookworm for node:20-bookworm.
Next major version: The newest build of the highest major version above yours, with the same variant, for example node:22.11.0-bookworm. A major version can change how your application runs: test it.
Smaller variant: A slim or alpine variant of the same major version. It has fewer packages, so it can have fewer findings.
TuxCare image: A TuxCare image of the same operating system family that removes the most findings.
Keep this base with TuxCare ELS: Shows when the operating system of the base is past its end of life and TuxCare Endless Lifecycle Support covers it. The count is the base findings that have an ELS fix. The row links to the ELS page.

Removes counts the open findings of the base that the upgrade does not have. Adds counts the findings of the upgrade that the base of your image does not have now. Critical and High count the removed findings of that severity. The counts compare the advisory and the package, not the version. An ignored finding does not count. Select Copy to copy the FROM line of the upgrade, for example FROM node:22.11.0-bookworm.

When the portal cannot give advice, the panel tells you why:

The panel says	Why	What to do
This scan has no layer data.	The scan does not list the layers of the image.	Scan the image again with a current scan-worker or CLI.
The base image is not in the list of known base images.	No known base image matches the layers, and the declared base, if any, is not in the list.	Nothing in the portal. The findings of the image still show, with the origin Unknown.
The scan does not say which layer holds each package.	The portal found the base, but the scan does not give the layer of each package, and no package with a finding is in the base image. The portal cannot split the findings.	Scan the image again with a current scan-worker or syft.
Base-image advice is not set up for this workspace.	The portal does not read the list of known base images.	On your own install, the operator sets `sync.base_images_url`.
The portal could not match this scan.	The match of the scan failed.	Scan the image again. If the error stays, get help.

When the list of known base images is more than 3 days old, the panel says that the advice may be out of date.

On the page of an image, the Findings tab has an Origin filter: All, Base image, Your layers, and Unknown. Unknown is a finding whose package is not in the base image and whose layer the scan does not give, or a finding of an image with no known base.

A finding #

A finding is one advisory in one package of one scan. Its page tells you how to fix it and where else it is.

The page of the finding CVE-2021-23337 in lodash, with How to fix, the description, the list Affected in this workspace, the triage card with Ignored and 90 days selected, and the timeline. — The page of a finding.

How to fix: the recommended fix, the alternatives, and the command.

Affected in this workspace: each repository that has this advisory.

The triage card: the state, the reason, and for an ignore, the time.

The timeline of the finding.

The header shows the advisory, the severity, the status, the triage state, and the fix deadline, for example due in 29 days. Select the advisory id to see every repository that it affects.
How to fix: Recommended is a TuxCare build when one exists, else the lowest upstream version with the fix. Command applies it: securechain harden for a TuxCare build, or the install command of npm or pip for an upstream version. Already fixed means that you already ship a TuxCare build with the fix. No known fix means that no fix exists.
Affected in this workspace lists the same advisory in the other repositories that you can see.
Advisory details has the CVSS vectors, the weakness (CWE), the affected versions, the aliases, and the references. Dependency paths shows how your project pulls in the package, when the scan has the dependency graph.
The side column has the triage card, the timeline, and Exploit signals: the sources that list the advisory as exploited.

A viewer sees the same page with no triage controls.

Triage findings #

A member or an admin sets the triage state of a finding. The state stays with the finding in later scans of the same branch.

new: Nobody has looked at the finding yet.
acknowledged: Somebody looked at it and accepts it for now. It stays open: it still sends alerts and counts toward its fix deadline.
ignored: The finding is muted. It is not open, sends no alerts, and is never past its deadline. Give a reason. The ignore ends after 30 days, after 90 days, on a date, or never. Then the finding goes back to new.

To triage one finding, open its page. In the Triage card, select the state, type the Reason, and for Ignored select the time under Ignore for. Select Save.

Apply to all N repositories sets the decision on each open finding of the same advisory in the repositories that you can see.
Also apply to the default branch and the active releases is checked at first. Clear it to change this ref only.
The audit log records each decision. The CLI reads the ignored findings as a baseline, so a CI gate can skip them. See Choose the gate.

Triage many findings #

Open the Findings tab of a repository, and filter it.
Select the check box of each finding. The box of a package header row selects all findings of the package. The box in the table header selects every finding that the filters show.
In the bar above the table, select Acknowledge, Ignore…, or Mark new.
For Ignore…, type the Reason, select the time, and select Ignore.

One change applies to at most 500 findings. If the portal refuses one finding, no finding changes, and the page shows the error.

The justification of an ignore #

An ignore can also have a Justification. It tells a reader why the finding does not affect you, and the VEX file uses it. The values come from CycloneDX: the code is not present; the code is not reachable; it needs a configuration, a dependency, or an environment that you do not have; or it is protected by the compiler, at run time, at the perimeter, or by another control.

Vulnerabilities #

The Vulnerabilities page lists each advisory one time, with every repository that it affects. Use it to answer are we affected by this CVE?

The funnel narrows the open findings in four steps: Open, Fix available, Critical or high, and Known exploited. Fix the last step first.
Filter by id or package, severity, Known exploited, Fix available, TuxCare fix, Not triaged, and department.
Each row shows the advisory, the severity, the exploit signals, the repositories, the fix, the age of the oldest open finding, and the share triaged (1/5). Select the count of repositories to see each finding.

Search for an advisory id that no scan has, and the page says Not affected.

Packages #

The Packages page lists every package of the tracked refs. The Inventory tab shows where each package is used.

The search field takes a name, or a name and a range: lodash@<4.17.21, django@>=3, react@18.x, or left-pad@1.3.0.
A red version chip has open findings. A green chip is a TuxCare build.
Select a package name to see each repository that uses it, with the version, the branch, and the dependency kind.

TuxCare coverage #

The TuxCare coverage tab counts the packages by TuxCare verdict:

Covered: You already ship a TuxCare build.
Hardenable: A TuxCare build with the fixes exists, and your subscription includes it. Run securechain harden.
Unprotected: A TuxCare build with the fixes exists, and your subscription does not include it.
No coverage: No TuxCare release line covers the package. TuxCare counts it as a request for coverage.
Frozen, Sunset: A frozen line keeps its last build and gets no new fixes. A sunset line gets no more fixes.

Remediation #

The Remediation page shows how fast the teams fix findings, against the fix deadlines.

Fixed in time: The findings that closed before their deadline, divided by the findings that closed in the period.
Mean time to fix: The mean time from open to close of the findings that closed in the period. A finding opens at its first sighting in its slot, and closes at the first complete, matched scan of the slot that does not have it.
Past the fix deadline: The open findings that are older than their deadline. Fix these first.

Fix deadlines #

A fix deadline is the number of days to fix an open finding, from its first sighting.

Severity	Default deadline
Critical, and every known-exploited finding	7 days
High	30 days
Medium	90 days
Low, and a finding with no rating	180 days

An acknowledged finding can pass its deadline. An ignored finding cannot. An admin changes the deadlines in Settings › Fix deadlines: 1 to 3650 days, and a worse severity cannot have a longer deadline. The grades and the counts use the new values at once.

The Fix deadlines card of the Settings page, with one field for each severity and the Save button. — Settings › Fix deadlines.

Releases #

A release is a scan that you mark as a build that you ship. The portal keeps it and checks it against each new advisory. Record a release from CI with securechain sca --release NAME (see Record a release), or select Mark as release on the Scans tab.

State	Alerts	In the workspace views	Checked against new advisories
Supported	Yes	Yes	Yes
Deprecated	No	Yes	Yes
Archived	No	No	No: the portal freezes the findings in a snapshot.

The Releases tab of the repository web-shop with two releases. v2.3.1 is deprecated, and its row has Report, VEX, a state control, and Delete. v2.4.0 is supported, from Acme 3.2, and its state control is off, with the text The state comes from Acme 3.2. — The Releases tab of a repository, as an admin sees it.

The Releases tab. The number counts the releases that are not archived.

Show archived adds the archived releases to the list.

The state of each release, for example supported, from Acme 3.2.

Report opens the release report. VEX saves the VEX file.

The state control and Delete. Only an admin sees Delete.

A product release decides the state of this release, so its state control is off.

The tracked refs of a repository are the default branch and its supported and deprecated releases. Every view of the workspace counts these refs only. A feature branch and an archived release are not counted.
A member or an admin changes the state of one release, or of many releases at once with the check boxes and Apply to. One change takes at most 100 releases, or 25 for an archive.
A release name does not move. The same name from another commit is refused, unless the job uses --force-release.
Only an admin can delete a release. Its scans stay. The portal never prunes a scan that a release holds.

A release that is not evaluated #

When the portal checks a release again and the check fails or has not finished, the release is not evaluated. The row of the repository shows Not evaluated, the release, and the cause: matching or match failed. Its findings are not in the counts, and it is not clean. matching is normal for some seconds after a CI job sends the release. After match failed, the repository cannot get grade A until a later check succeeds. If the mark stays, contact TuxCare.

Product releases #

A product release is the set of releases that you ship together, one release of each repository of a product. For example, Acme 3.2 holds v1.3 of the web repository and v2.0 of the api repository.

Open Compliance and select Releases on the product.
As an admin, type a name under Name of the new product release, and select New product release.
Select Edit members, pick one release for each repository, and save.

The product Acme Shop on the Compliance page with its Releases panel open. The panel has Show archived, the field Name of the new product release with the button New product release, and the product release Acme 3.2: state supported, members web-shop v2.4.0 and billing-api v1.8.0, with Report, VEX, a state control, Edit members, and Delete. — The product releases of a product, as an admin sees them.

Releases opens and closes the list of product releases.

The name of a new product release, and New product release. Only an admin sees them.

A product release: its name, its state, its date, and its members.

Report opens the product release report. VEX saves the VEX file.

The state control, Edit members, and Delete. Only an admin sees them.

The state of a product release decides the state of each release that it holds. A release in two product releases takes the more active state: supported, then deprecated, then archived.
An archived product release refuses new members and new scans of its releases, and keeps a snapshot of each member.
A CI job can join a release to a product release with --product-release "Acme 3.2". The portal makes the product release on first use when the repository is in exactly one product.

Export VEX #

A VEX file tells your customers which known advisories affect a release. Select VEX on a release or a product release. The file is CycloneDX 1.6 JSON. Every role can export it. The state of each advisory comes from the triage:

What the portal knows	VEX state
Open and new, or an ignore that has ended	`in_triage`
Acknowledged	`exploitable`
Ignored, and the ignore has not ended	`not_affected`, with the justification and the reason
Fixed by a TuxCare build	`resolved`, with the response `update`

An advisory in two packages of the release has one entry, with the most open state. A known-exploited advisory has the property tuxcare:exploited. The file of an archived release is frozen at the time of the archive (tuxcare:frozen_at). A script gets the file at GET /api/v1/releases/{id}/vex or /api/v1/product-releases/{id}/vex.

The release report #

Select Report on a release or a product release to open its compliance report. The report of a supported or deprecated release shows the findings of today. The report of an archived release shows Frozen at and the findings at the time of the archive. A script gets the data at GET /api/v1/releases/{id}/report.

Compliance #

The Compliance page holds the EU Cyber Resilience Act (CRA) clocks, the products, and the reports for an auditor.

CRA clocks #

Article 14 of the CRA tells a manufacturer to report an actively exploited vulnerability in a product: an early warning in 24 hours, and a notification in 72 hours. The portal starts a clock for each open known-exploited finding.

Clock start is the later of two times: the first sighting in your scans, and the first listing by a source. The card shows the start plus 24 hours and plus 72 hours, in UTC.
The card names the package, the repository, and its products, or Not in a product.
A member or an admin selects Record decision: Decision needed, Early warning sent, Notification sent, or Not reportable. The last two stop the clock. The audit log records each decision.

The portal shows the candidates. You decide if a finding is in a product that you sell and if you must report it.

Products #

A product is a named set of repositories that you place on the market. The CRA applies to a product. An admin selects New product, types the name, selects the repositories, and selects Save. A product does not change who can see a repository: departments do that. A delete keeps the repositories, and removes the product releases of the product.

Compliance report #

The compliance report is a document about one repository for an auditor. Open the repository, select a branch if you want, select Compliance report, then Print or save as PDF. Every role can open it. It has these sections:

Scope: the workspace, the repository, the branch, the scans, and the date of the data.
Known-exploited vulnerabilities: each one, with its sources and the CRA times.
Software bill of materials: the components by ecosystem, and the components that the portal could not evaluate.
Findings: each finding, with the severity, the exploited flag, the triage state, and the fix.
Suppressions: each acknowledged or ignored finding, with the person, the time, the expiry, and the reason, and the triage log.

A script gets the same data at GET /api/v1/repos/{id}/report, with ?ref= for a branch.

Export findings and dependencies #

Download the findings or the dependencies as CSV or JSON. For one repository, select More on its page. For all repositories that you can see, select Export on the Overview. Select Findings or Dependencies, then CSV or JSON, then Download.

The file has the rows of the tracked refs. The column release names the releases of the row. A scan that is not matched yet is not in the file.
The findings file has the columns exploited and exploited_sources, the severity, the triage state, and the fix.
In a CSV file, a cell that starts with =, +, -, or @ gets a single quote first, so a spreadsheet does not run it.
A script gets the files at GET /api/v1/repos/{id}/export/findings, /export/components, and GET /api/v1/export/findings. Add ?format=json for JSON. See The REST API.

Each scan also has a CycloneDX SBOM: see The Scans tab.

Alerts #

An admin sets up alerts on the Notifications page of the workspace menu. The portal sends an alert when a scan adds a vulnerable package, or when a new advisory affects a package that you already ship. Alerts cover the default branch and the supported releases. For a feature branch, use the pull request gate.

Minimum severity: Findings below this level send no alert. A known-exploited finding always sends one. An ignored finding never does.
Delivery: immediate, or a daily digest at 00:00 UTC. The Weekly digest is a 7-day summary, sent also when nothing changed.
Email to: At most 10 addresses, separated by commas. Empty means every active user. In a hosted workspace, each address must be an active user who signed in at least once with the TuxCare sign-in.
Slack incoming webhook: An https Slack webhook URL.

A new scan sends its alert at once. After a feed update, the portal waits until the rechecks end (at most about 30 minutes), then sends one message for each repository. Select Send test to check the setup: at most 5 tests an hour.

Outbound webhooks #

Add an https endpoint under Outbound webhooks. Copy the signing secret: the portal shows it one time. Each alert arrives as a JSON POST with id, kind, created_at, and payload, and two headers:

X-SecureChain-Timestamp: the time, in Unix seconds.
X-SecureChain-Signature: sha256= and the hex HMAC-SHA256 of timestamp + "." + body, with the secret as the key.

Compute the HMAC, compare it with the header, and refuse an old timestamp. The portal does not follow redirects. When the endpoint does not answer 2xx, the portal tries again after 1, 5, and 15 minutes. In a feed-update alert, each finding also has a refs list.

Email that does not arrive #

The portal stops email to an address at once after a hard bounce or a spam report, and after three failed deliveries in a row over at least three days. The other admins get an email. Email delivery lists each address and the reason, and the Users page marks the user Email stopped. Correct the address, then select Resume email. Resume an address that reported spam only when the person asks for the email.

Terms #

Severity: The highest CVSS score of the group of records that describe one vulnerability (a CVE and its aliases).
open: The advisory applies to the version that you ship, and the finding is not ignored.
new, reopened: new: the finding is on this branch for the first time. reopened: the previous scan did not have it, and this scan has it again.
fixed by TuxCare: You ship a TuxCare build (a version that ends in -tuxcare.N) that has the fix.
Known exploited: A named source, for example CISA KEV or ENISA EUVD, says that attackers use the vulnerability. It passes any alert severity filter, uses the critical fix deadline, and starts a CRA clock.
Not assessed: The portal could not check the package, for example because no advisory source covers its ecosystem. It is not clean.
Tracked refs: The default branch and the supported and deprecated releases of a repository. The workspace views count these only.
Slot: One project path and one set of ecosystems on a branch.

Next: Fix