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.

Open your workspace #

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. After a sign-in at the workspace address, sc.tuxcare.cloud can ask Continue as your email address: select it to sign in to sc.tuxcare.cloud too, or select Not now to go on to the workspace. Select Continue as only if you started the sign-in yourself. A person who has not accepted the terms sees the terms page after the first sign-in. On this page, you accept the SecureChain Portal Terms of Use, the SecureChain Portal License Agreement, and the SecureChain Portal Data Processing Addendum for the organization of the workspace, and you acknowledge the SecureChain Portal Privacy Policy. Read them, select the box to accept them, and select Continue. If the workspace has no legal name, an admin also types it in Legal name of your organization. The portal asks one time for each workspace, and again only when TuxCare publishes new versions of the documents. 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, and each acceptance under Settings › Organization.

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.

A sign-in to a workspace lasts 14 days. If you do not use the workspace for 3 days, it asks you to sign in again. Select Sign out to end the session at once.

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.

Workspaces #

A workspace is one organization. Everybody in the workspace sees its repositories, except the repositories that a department hides from them. The button at the top right of the header names the workspace that you are in. It also shows your role. Open the button to see Workspace: and the name on the first line of the menu.

If you belong to more than one workspace, select Switch workspace in the menu and choose another one. Select Create workspace to start a new workspace for another organization. Check the name in the button before you triage a finding or make a token: the change applies to the workspace that the button names.

Roles #

Each user has one role for the whole workspace.

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:

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.

Filter by asset kind #

The Overview, Vulnerabilities, Packages, and Remediation pages have the buttons All, Repositories, Images, and Hosts. Select a button to show the findings and the packages of that kind of asset only. All shows every kind. The selected button has a check mark. The page address keeps the choice, and the links from the Overview to the other pages keep it too.

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 that are not evaluated: a release that is not evaluated, or an operating-system release with no advisory data.

• 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). The package with the worst severity comes first; inside one severity, 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, and a member can on Set up CI: the member's repository goes where the member's first scan would put it. Set up CI, beside it, mints the CI token of one repository and shows the job for your CI system, with buttons that copy them. An admin and a member see it.

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. When the newest scan is on another branch than the one the row counts, the cell names that branch and its time instead (feature-x · today 17:39); when the counted branch is stale, its amber chip and date show under that line. A run that repeats a scan of the same commit and the same dependencies moves the time of that scan; it does not add a scan.

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.

A repository with no complete, matched scan has no grade. A repository with a release whose match failed, or with an operating-system release that has no advisory data, never gets grade A: when no other rule of the table applies, it has no grade, and the page shows —. The rules use the fix deadlines of your workspace.

The page of a repository shows the same grade as the list. When you open a branch, a project of a branch, or an older scan, the grade reads the scan that the page shows, by the same rules. A scan that is clean but cannot prove it has no grade: its release has no advisory data, or a later scan of that project failed its match, and no later scan of it matched. The page names the cause under Not evaluated.

The Hosts page #

The Hosts page lists the machines scanned with tuxcare-radar3 (Getting started tells you how), one row each: the operating system and its release, the TuxCare support of the host (TuxCare ESU, TuxCare Essential Support, or TuxCare ELS; Read a host tells how the portal tells ESU from Essential Support) or, with none, how long the vendor's own security support runs, the kernel the host was running, the open vulnerabilities by severity, and the time of the last scan. The cards at the top count the hosts, those under TuxCare support, those past the end of their vendor's support, and the open and the known-exploited vulnerabilities across them. Search by host name, or filter by department. A host that the TuxCare Radar agent scans can send tags: each row shows them. To show only some hosts, select an operating system or a tag; with two or more tags, the page keeps the hosts that hold every tag. The page address keeps these filters. Select a host to open its page, which opens with the host's facts: the operating system, the tags, the support, the kernel, the address the scan came from, the agent or the CLI version, and the last scan. A host that the TuxCare Radar agent scans shows Agent: tuxcare-radar 1.2.3; a host last scanned with securechain-host, the earlier name of the agent, shows its version as the CLI version. It has the same tabs as a repository. On both lists, the Last scan date turns amber after 14 days without a scan and red after 30, with the age written beside it.

A host is a repository of kind host underneath, so departments, tokens scoped to one asset, alerts and the export treat it as one. The Repositories page shows repositories and images only.

The TuxCare Radar agent also sends the machine ID of the host. The portal then keeps one host for each machine: a host that changes its name stays the same host and shows its new name. Two machines with the same name are two hosts, and the second shows its name with the first eight characters of its machine ID, for example web#fedcba98.

The agent sends every installed kernel, and the kernel that runs. The Vulnerabilities tab hides the findings of the kernels that do not run. To see them, select Show findings of kernels that are not running; the number in the label is the count of their vulnerabilities. Such a finding has the status kernel not running. It is not open, so it does not count in the grade, the totals, the trend, or the alerts. When the host boots one of those kernels, the next scan makes its findings open again. A host last scanned with securechain-host sent no running kernel, and the tab shows all its findings.

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.

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. When the CLI names a default branch that has no scan yet, the page says No scan of that branch yet and links to the branch with the newest scan.

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.
• The pages name a package by its full path: a Go module of major version 2 or more shows as github.com/corazawaf/coraza/v3@v3.0.0, not v3@v3.0.0, and an npm package of a scope as @babel/core. An operating-system package shows its name alone, for example openssl. The same name is in the fix plan, the page of the finding, the report, and the export.
• By package groups the findings under one header row for each package. A finding on a host or an image can list several packages of one source or one kernel build: it sits under its first package, and the page of the finding lists the others. The header row shows the open findings and the closed ones apart, and the upgrade, with closes all when the upgrade closes every open finding of the package. Else the row shows how many open findings the upgrade closes, for example closes 2 of 3: a finding with no known fix stays open. A package whose every finding the TuxCare build you ship already closes reads Closed by the TuxCare build you are on; it comes last and starts collapsed. Flat list shows one row for each finding.
• A package that only a development or test dependency reaches, as the SBOM of the scan says, has the mark dev. Its findings still count as open. Select Hide dev to leave them out of the list. The chip shows only when the scan has a dev 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. The packages with the worst severity come first: critical, high, medium, low, then no rating. Inside one severity, a package with a known-exploited finding comes first. A known-exploited medium never comes above a critical or a high. A finding that lists several packages counts for each of them. The version to move to is the one version that closes the most findings of the package. Each finding has its own fix, and the plan takes the highest of them. The plan names a TuxCare build only when that build closes every finding of the package. 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; scope unknown when the scan could not tell), its open findings, and its TuxCare status: TuxCare build, TuxCare build available, No TuxCare build, or Not assessed.

A package that your lockfile fetches from a git repository has no advisory source, so the portal does not evaluate it. When this workspace also scans that repository, the row says so: Scanned in this workspace: repository at commit: N open findings. Select the link to see the findings of that scan. When the workspace has no scan of that commit, the row names the newest scan of the repository and says another commit. When the repository has more than one project at that commit, the count covers each project and says how many: N open findings in 2 projects. These findings stay in the scan of that repository: they are not in the counts or the CI gate of the scan that lists the package. The component export has the same link in its workspace_scan_* columns, and the compliance report counts these packages.

A GitHub Action of your workflows (uses: owner/repo@ref) is a package of the scan too. Its row says Pinned to a commit when the ref is a full commit hash of 40 characters, else Not pinned: a tag, a branch, or a short hash can move to other code between the check and the run. A warning above the table counts the actions that are not pinned, and each such row gives the advice: pin the action to a full commit hash and keep the tag in a comment (uses: owner/repo@<sha> # v4.2.2), and turn on the GitHub policy that requires SHA pinning for the organization or the repository. This is a warning, not a vulnerability: it does not change the counts or the grade. The portal checks each action against the GitHub Actions advisories: the ref goes to the commit that it named when the portal received the scan, the commit to its release version, and the version through the ranges of the advisories. A commit that an advisory names as malicious is vulnerable whatever its version. A checked action says Checked at version 4.2.2, and a vulnerable one has its finding in the Findings tab, with the upstream fix. An action that the portal cannot check says Not checked with the reason: the tag data has not reached the workspace yet, the ref is a branch, the ref is not a known tag or commit, the commit has no version tag, or the scan is older than the tag history. An action that is not checked is never counted as clean. An action of a repository that no advisory names has nothing to check. The component export has the same state in its action_* columns.

A tag of an action can point at a malicious commit for a short time and then move back, as the tags of tj-actions/changed-files did on 14 and 15 March 2025. A check after that time reads clean, but a build in that time ran the bad code. When the advisories name such a commit, the Overview and the page of each repository that used the action show the card GitHub Actions: past exposure. A branch of a repository is Possibly exposed when the scan in force at a time in the window (the newest scan at or before that time) holds the action at a tag that pointed at the bad commit, or pins the bad commit. When the branch has no scan before the window and its first scan holds the tag, the card says so. When your jobs run the gate step of the CLI, the card also lists each run in the window: Exposed when the runner downloaded the bad commit and the job went on, Blocked by the gate when the gate stopped it, and Not exposed when the run got another commit. The card gives the days to review (UTC), and the advice: review the runs of the workflow in those days, and rotate the repository and organization secrets that the jobs with the action can read, and the tokens that those jobs wrote. The export GitHub Actions: past exposure holds the same list.

The link shows only a repository that you, or the token, can read. A CI token of one repository reads that repository only, so it gets no link to the scan of another repository. The CLI then says that the scan exists in this workspace, but the token cannot read it. A department token whose department holds both repositories, or a personal login that can read both, shows the link.

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 7 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.

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

1. 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.
2. 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.

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:

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 header shows the advisory that matched the version of the package, 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. Some advisories name each other, so the portal keeps them as one finding. When a related advisory names your package but does not affect your version, the card Advisories of this finding lists it under Related ids that do not affect this version, with its own CVE and its fix for the package. For example, node-forge 1.4.0 shows CVE-2026-85393, and the card lists GHSA-ppp5-5v6c-4jwp (CVE-2026-33894), fixed in 1.4.0.
• 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. For a transitive package, the card names the direct packages of your project that pull it in, and the way to pin or move it in your ecosystem. Where one line or one command fits your tool, the card shows it to copy: for example a constraints line for pip, a dependencyManagement section for Maven, a constraints block for Gradle, or go get, cargo update, composer update, or bundle update. A package name or a version with characters that are not safe in a command gets no line: the name comes from the scan, and you run the line. 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. Choose why, and 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. For Ignored, answer Why?, type the Reason, and select the time under Ignore for. Select Save.

Why do you ignore it? #

Each ignore has a reason category. The category does not change what the portal counts: every category removes the finding from the totals, the grades, the alerts, and the fix deadlines. It changes the VEX file and the labels that other people read.

The advisory data is wrong

The advisory is wrong for this package or these versions, and the same is true for everyone. Select What is wrong?: the bug is in another package, the version range is too wide, the vulnerable code is not in the package, the CVE is disputed or rejected, or another problem. The VEX file says false positive. See Report wrong advisory data.

We are not affected

The advisory is right, but your project does not run the vulnerable code. Select a Justification (see below). The VEX file says not affected.

We accept the risk

Your project is affected, and your team accepts the risk for now. The VEX file says exploitable and will not fix.

Other reason

Another reason. Write it in the reason field. The VEX file says not affected, with no justification.

Under Where?, This finding sets the decision on this finding only. The other choices make a rule that also covers later scans and new versions. See Suppress a vulnerability with a rule.

• 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 #

1. Open the Findings tab of a repository, and filter it.
2. Select the check box of each finding. The box of a package header row selects all findings of the package. A finding with several packages is one finding: one selection triages it for all its packages. The box in the table header selects every finding that the filters show.
3. In the bar above the table, select Acknowledge, Ignore…, or Mark new.
4. For Ignore…, choose Why?, 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 of the category We are not affected 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.

Suppress a vulnerability with a rule #

A rule ignores one vulnerability for more than one finding. It also applies to the scans, the versions, and the repositories that come later. A rule has a scope:

This repository

Every finding of the advisory in the repository. A member of the repository can make this rule.

A department

Every finding of the advisory in the repositories of the department.

The workspace

Every finding of the advisory on every asset of the workspace.

A narrower rule wins over a wider rule. A decision of a person on one finding wins over every rule.

1. Open the page of a finding or of the vulnerability. On the page of the vulnerability, select Suppress this advisory. A member selects Ask to suppress this advisory.
2. Answer Why? (see Why do you ignore it?). For wrong data, select What is wrong?.
3. Under Where?, select the scope. The form selects the narrowest scope that fits.
4. Optional: change the Package. It shows the package of the finding. A rule with a package does not cover the other packages of the same advisory. Clear it to cover every package.
5. Optional: select Versions. Type the versions with commas between them. With Every version, the rule also covers new versions.
6. Type the Reason. It is necessary.
7. Optional: select 30 days, 90 days, or Until a date. The rule ends at the end of that day (UTC). Or select Until a fix is available: the rule ends when the advisory has an upstream fix version for the package. A TuxCare build does not end it.
8. Optional: select the asset kinds: Repositories, Images, or Hosts. With no kind selected, the rule applies to every kind. TuxCare Radar applies the rule to hosts only.
9. Select Add the rule. If the scope needs an approval, the button is Ask an admin.

Ask an admin #

A member can make a rule for one repository. A rule for a department or for the workspace needs an admin. A member who selects one of these scopes sends a request. For a department, the member needs a seat in that department.

• The admins get an email for each new request. Until an admin approves it, the request has no effect and the findings count.
• An admin opens Settings › Requests, and selects Approve or Reject. Before the approval, the admin can make the rule narrower: the scope, the package, the versions, and the end date. A rejection needs a note.
• An admin cannot decide a request that the same admin made. Another admin decides it. An admin who needs a wide rule makes the rule directly.
• The person who asked gets an email with the decision and the note.
• A viewer cannot make rules or requests.

The list of rules #

• Settings › Suppressed vulnerabilities lists the rules, with the scope, the package, the versions, the reason, the end date, the person who approved the rule, and the state. Every role can read the list.
• A finding of a rule shows ignored by rule and the reason. It does not count in the totals, the grades, the trend, the alerts, or the fix deadlines.
• A rule has one of three states: Active, Needs review, or Ended.
• End, not delete. Select End to stop a rule. The findings count again, and the rule stays in the list as history. An admin ends any rule. The author of a repository rule ends that rule.
• The audit log records each rule, request, decision, and end.

When the advisory changes #

When the affected packages or versions of the advisory change, the rule goes to Needs review. The rule stays in force while it waits. A change of the score or of the text does not move a rule.

• The admins get one email each day that lists the rules to review. For a repository rule, the author also reads the list in Settings.
• An admin selects Confirm to keep the rule, or End to stop it.
• A rule of wrong data that you sent to TuxCare shows Waiting for TuxCare. TuxCare checks the new advisory. If the data is still wrong, the rule goes back to Active. If the data is now right, the rule ends and the admins get an email with the note of TuxCare.

Report wrong advisory data #

Advisory data from outside sources has errors. If the data is wrong for everyone, tell TuxCare. TuxCare checks the advisory. If the data is wrong, TuxCare corrects it for every workspace and tells the source of the advisory.

Report wrong data #

There are two ways. Both send the same report.

• With a rule. Make a rule (see Suppress a vulnerability with a rule), choose The advisory data is wrong, and keep Send to TuxCare checked. The report goes when the rule becomes active. For a request, it goes when an admin approves the request. A rejected request sends nothing.
• Without a rule. On the finding page, open Report wrong data to TuxCare, fill in the form, and select Send to TuxCare. This suppresses nothing: the finding still counts. Use it when you want TuxCare to know now. Every role can send a report, also a viewer.

A workspace sends 50 reports in a day (UTC) at most. After that, a report without a rule is refused until the next day. A rule still saves and works, but it sends no report: the rule list shows Not sent to TuxCare: daily limit.

What goes to TuxCare #

The form shows the exact text before you send it. A report holds:

• the reference of your workspace, for the staff link and the deletion rule;
• the advisory id, the package (with no version), and the versions;
• the problem that you selected;
• the reason that you typed.

A report holds no name, no email address, no repository name, and no commit. TuxCare does not tell other workspaces that you reported the advisory, and does not show them your text.

What happens next #

The rule list and the finding show the state of the report:

Sent to TuxCare

TuxCare has the report. Nobody has looked at it yet.

TuxCare is checking

Staff check the advisory data.

TuxCare reported it upstream

TuxCare sent a correction to the source of the advisory. The note has a link.

TuxCare corrected the data

The advisory data is right now, in every workspace. The false findings close at the next match, and the page of the advisory says TuxCare corrected this advisory, with the reason. Your rule then has no finding to cover. You can end it.

TuxCare: the data is right

TuxCare checked the data and did not change it. The note says why. The rule stays in force until you end it.

The note of TuxCare shows next to the state.

Turn the reports off #

An admin can turn the reports off in Settings › Reports to TuxCare. The switch is on at first. When it is off, a rule of wrong data sends nothing, and the report form does not show. The rule still works. Without a report, TuxCare cannot check the advisory for you. When the advisory changes, an admin confirms or ends the rule.

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, Needs a reboot (a reboot would close at least one of its findings on a server without KernelCare: the newest installed kernel fixes it), 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).
• The Affects column counts two things: the repositories, images, and hosts with an open finding of the advisory, and the open findings. One repository can hold more than one finding of an advisory, one for each affected package. For example, 1 repository, 2 findings is one repository with brotli and brotlicffi. When each repository holds one finding, the column gives the repositories only (3 repositories). The count follows the filters of the page, the department too.
• Select the count to see each finding. The list shows each repository one time, as a heading, with its findings under it: the package and its version, the fix of that package, and a link to the finding. The packages of one advisory can have different fixes. When they do, the Fix column gives the fix of the worst finding and says so, and the list gives the fix of each package. The findings that are ignored or that a TuxCare build fixed are not in the count: the list shows them below the open findings, under Not in the count.
• After the advisory id, matched by names the advisories that affect your packages, and the line below gives the title of one of them when its title is not the text of the CVE. The text of a CVE can name another product. For example, the text of CVE-2023-4863 names Google Chrome, and the row shows matched by GHSA-j7hp-h8jx-5ppr with the title libwebp: OOB write in BuildHuffmanTable: Pillow before 10.0.1 includes its own copy of libwebp. Each finding in the list of repositories also names the advisories that matched it.

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

To save the list, select XLSX or CSV next to Export, or PDF for a page to print or save as PDF. The file has every advisory that the filters keep, not only the page, with the hosts and the other assets that have each one, the counts of open, triaged, and late findings, the fix, and the other names of the advisory. An XLSX file has a filter on each column, and a second sheet, About, with the filters and the time of the export.

Packages #

The Packages page lists every package of the tracked refs. A finding that lists several packages counts on each of them. 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, image, and host that uses it, with the version, the branch, and the dependency kind. A host has no branch and no dependency kind: its row says installed on the host.

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, the worst severity first. Inside one severity, a known-exploited finding comes first. Fix these first.

Top fixes across hosts

Shown when the page shows hosts only: with the asset-kind filter on Hosts, and in a TuxCare Radar workspace. Each row is one package update on the hosts: the package, the version to update to, the advisories and the open findings that the update closes (a finding that lists several packages counts on each package), and the hosts that it touches. The rows that close the most advisories come first, then those on the most critical hosts, then those on the most hosts. On each host, the update goes to the highest fix version of the open findings of the package. A finding that KernelCare or LibCare live-patches, a finding of a kernel that the host does not run, an ignored finding, and a finding with no fix do not count.

Time to remediate and SLA #

The section Time to remediate and SLA at the end of the Remediation page is the remediation report for managers and auditors. It uses the department and the asset-kind filter of the page. Report period selects the last 30, 90, 180, or 365 days. Until you change it, it follows the period of the page.

Mean time to remediate by month

One row for each calendar month (UTC) of the period, and a last row for the whole period. The first and the last month are cut to the period: the row shows the days, for example 4–31 Aug 2026. For each severity, the table shows the mean and the median number of days from the first sighting to the close, and the number of findings that closed. A finding counts in the month in which it closed. — means that no finding of that severity closed. The column No rating shows only when a finding with no rating closed.

Fixed in time against the deadline sets

One row for each deadline set, with the deadline of each severity. Fixed in time is the share of the findings that closed in the period on or before their deadline, with the counts (for example 92% (23 of 25)). Open past the deadline counts the findings that are open now and older than their deadline. Out of scope counts the findings that the set leaves out. The portal computes every deadline and count.

To save a table, select Download MTTR (CSV) or Download SLA (CSV). The files have the filters of the page. The MTTR file has a row for each month, asset kind (hosts, repositories, images, and all), and severity. The SLA file has a row for each deadline set and severity, and a total row for each set. To make a PDF, select Print or save as PDF: a page opens with the workspace, the period, the filters, the date, and the two tables. Select Print or save as PDF on that page, then Save as PDF as the printer.

Fix deadlines #

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

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.

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.

• 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. A release of a container image belongs to its image digest: the same name on another build of the image is refused in the same way, also when the build has the same packages.
• 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.

An operating-system release with no advisory data shows the same mark: Not evaluated: centos-8 (no advisory data). The portal has no advisory of TuxCare or of the vendor for that release, so it cannot check the operating-system packages of the scan. The repository or host cannot get grade A, and the Overview counts it as not evaluated. See The Hosts page.

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.

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

• 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. On a release or a product release, select a format after VEX: CycloneDX (CycloneDX 1.6), OpenVEX (OpenVEX 0.2.0), or CSAF (a CSAF 2.0 VEX document). The three files state the same thing. Give the reader the format that it asks for: many buyers and the guidance of the EU Cyber Resilience Act read CSAF, and the Sigstore tools read OpenVEX. Every role can export the file. The state of each advisory comes from the triage:

OpenVEX and CSAF have fewer justifications than CycloneDX. It needs a configuration, a dependency, or an environment becomes the vulnerable code cannot be controlled by an adversary, and the four protected values become inline mitigations already exist. The OpenVEX author and the CSAF publisher is your workspace. An OpenVEX or CSAF file needs at least one advisory: for a release with no advisory, only the CycloneDX file is available.

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, with ?format=openvex or ?format=csaf for the other formats.

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 reports #

A compliance report is a document about one repository for an auditor, made when you open it. Open the repository and select Compliance reports: the page lists what a report can be about. One row for each scanned branch or tag (by project, when the repository holds several), with the date of its last scan, the commit, and the counts of its open and known-exploited findings; the branch the repository page counts is marked tracked and comes first. The counts of a row are the counts of the report it opens. A repository with many branches shows the rows in pages: choose the rows per page, then Previous and Next. Below it, one row for each release. Select Open report on the row you want, then Print or save as PDF. Every role can open it. A report 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.

The section Known-exploited vulnerabilities links to the single reporting platform of the Cyber Resilience Act, where a manufacturer files the early warning with its CSIRT and ENISA.

A script gets the list at GET /api/v1/repos/{id}/reports, one page of the branch and tag rows at a time (?limit= and ?offset=; next_offset is absent on the last page), and a report 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, when a new advisory affects a package that you already ship, when a host stops sending scans, and when an open finding comes near its fix deadline. Alerts cover the default branch and the supported releases. A person can also watch every branch of a repository (see Choose the alerts that you get). For a feature branch, use the pull request gate. A source repository alerts on its default branch: the default branch that you set, else main, else master. A repository with none of these has no alert branch. Its branch scans then send no alert, except to a person with an All branches watch. Its supported releases still send alerts. The Watchers section shows No alert branch. Set the default branch on the repository page to fix it. An upgrade or a new build of a package that leaves an advisory open sends no alert, and neither does a fix that waits for a restart: the package had the finding before. The first scan of a repository, branch, or project path sends no alert. The exception is a person with an All branches watch: the first scan of a feature branch alerts that person. The subject of each alert names the workspace after the product, for example SecureChain [acme]: 3 new finding(s) across 1 repo(s).

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: all alerts of the day in one message, 30 minutes before the daily time of the workspace. This is the choice of the workspace. Each person also has a choice of their own.

Digest

off, weekly (a summary of the last 7 days), or daily (a summary of the last 24 hours), at the daily time of the workspace. The portal sends the digest also when nothing changed. The digest starts with the new findings that a source lists as exploited in the wild. Then it shows the counts, the project to start with, the projects with the most severe new findings, and the new advisories, most severe first. It also counts a finding that a new advisory opened on an older scan.

Host not seen (days, 0 = off)

A host that sends no scan for more than this many days sends one alert. The subject names the host and the days. When the host sends a scan again, the alert starts again. The default is 3 days.

Fix deadline warning (days, 0 = off)

An open finding sends one alert when its fix deadline is at most this many days away. A change of the fix deadlines gives a new deadline, and a new alert. The portal checks the deadlines once a day. One message lists the findings of the check, with the asset and the due date. The minimum severity applies; a known-exploited finding always alerts. The default is 0: the alert is off until an admin sets the days. TuxCare Radar used 30 days.

CIS drift

A host sends one alert when a CIS rule that passed in its previous OpenSCAP run fails in the new run. One message lists the rules of the run, each with why it matters and how to fix it, and links to the CIS page of the host. The alert compares only runs with the same content, level, and scanner version: the first run of a host, the first run after a new content, level, or scanner version, and a rule that was manual before send no alert. The minimum severity does not apply. The default is on.

Email to

At most 10 addresses, separated by commas. These addresses get every alert of the default branch and the supported releases, as the Slack channel does. They do not replace the people who watch a repository: those people get their email also when this field is set. An address that is also a watcher gets one email. Empty means no extra address. 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.

The Notifications page and My alerts show the daily time of the workspace, in UTC and in your time zone. The portal picks a fixed time for each workspace, so the workspaces do not all send at one time.

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. The test email goes to Email to, to the people who watch a repository, and to you. When nobody watches a repository and Email to is empty, it goes to every admin.

Choose the alerts that you get #

A person gets alert email only for the repositories that they watch. Each person sets this for themselves. A viewer can do it too.

• Turn on Watch on a repository page. Choose Default branch and releases or All branches.
• On the My alerts page, watch a department (every repository of it, also one that is added later) or all repositories.
• The person who adds a repository watches it with no action. This is the person who owns the token of the first scan, or who registers the repository in the portal.
• To stop a watch of one repository that a department or all-repositories watch covers, turn off Watch on that repository. The other repositories stay watched.

A watch never shows a repository that the seats of your department hide. The email of a person lists the watched repositories only.

A watch of All branches also sends the alerts of a feature branch and of a deprecated or archived release. These alerts list only the findings that the default branch does not hold. A finding that is open on the default branch sends one alert, from the default branch.

When nobody watches a repository, its alerts go to the admins. The email says Nobody watches this repository. The Notifications page lists the repositories that nobody gets alerts for.

Immediate email or daily summary #

On My alerts, each person chooses how the email arrives.

Automatic

The default. Immediate email while you watch 3 repositories or fewer. A daily summary when you watch more. A watch of all repositories counts as more than 3.

Immediate

One email for each alert.

Daily summary

One email a day, at the daily time of the workspace. It holds new findings, silent hosts, and fix deadlines only. On a day of the workspace digest, the same email also holds the digest: one email, not two. It lists the alerts that the portal delivered since the last summary, at most 7 days. It shows at most 50 findings for each repository and 200 in total, then and N more. An address that is also in Email to gets no summary: that address gets every alert at once.

Off

No alert email. You still count as a watcher of the repository.

A known-exploited finding sends its email at once, for every choice except Off. The one exception is a workspace whose delivery is daily digest: there the portal holds every alert, also a known-exploited one, until 30 minutes before the daily time of the workspace.

In a hosted workspace, the portal sends alert email only to a person who signed in at least one time with the TuxCare sign-in. Until then, your watches stay as you set them, and My alerts says that you get no alert email.

Act on a finding from the email #

Each finding in an alert email has links that act on it. Each new advisory of a digest has one link.

Ignore

Ignores the finding on its branch, with the reason category other.

Accept risk

Ignores the finding with the reason category risk accepted.

Not affected

Ignores the finding with the reason category not affected. A VEX export then says not_affected.

Suppress in this repository

Makes a suppression rule of the advisory for the repository. It needs the member role on the repository.

Suppress in the workspace

The link of an advisory in the digest. An admin makes a rule of the workspace. A member asks an admin for it.

A link opens a page of the portal that shows the finding or the advisory and what the action does. Nothing changes until you select Confirm. Sign in first if the portal asks you to. The action has the same rules as in the portal: a triage needs the member role on the repository, and a rule needs a reason. The audit log names you.

• A link works once. When a colleague used it already, the page says who and when.
• A link works for 7 days. After that, open the finding in the portal.
• A link works only in the workspace that sent the email.
• A very large email, for example a daily summary with many findings, shows the links for its first findings only, so that mail programs show the whole email. Act on the others in the portal.
• A merged alert of an advisory update names several branches. Its finding has the suppress link only: a triage is a decision for one branch.

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. Select Test in the row of an endpoint to send it a signed test event: at most 5 tests an hour for the workspace. The portal does not follow redirects. When the endpoint does not answer 2xx, the portal tries again after 1, 5, and 15 minutes. When no channel of the workspace got the alert, it then tries once an hour for about a day. Then it stops, and the audit log names the alerts that did not go out. Each finding has a stable_key. In a feed-update alert, each finding has a refs list and no stable_key.

Answer each POST quickly: one try gives an endpoint one minute for all of its alerts. After a failed delivery, or when the minute ends, the endpoint gets no more alerts until the next try. When the deliveries to an endpoint fail again and again for a day or more, the portal turns the endpoint off and writes the reason to the audit log. Correct the endpoint, then turn it on again.

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). The advisory of an operating-system vendor can rate the vulnerability higher than the score. That rating applies to the packages of the operating system only: a language package (npm, PyPI, Go, and the other ecosystems) takes the band of the CVSS score, and its finding page shows severity from the CVSS score.

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. A finding that is not open keeps the mark on its row, muted and with the reason, for example closed by the TuxCare build you are on or, on a host, live-patched by KernelCare: the claim is about the vulnerability, and the finding is not open work, so the Exploited filter and the counts leave it out. An ignored finding is not open either: its mark is muted with ignored, and they leave it out in every triage view, also in all. The exploitation block of the finding page is muted the same way and says why.

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