We’ve updated our global, project, and release group Issues view to improve experience and functionality. This is the central inbox for all issues across all projects or all issues within a specific project.

From the main Issues tab, you can navigate to your Security Issues.

In this article, you learn about filtering and sorting options. As well as, bulk actions you can take to address the identified issues.

🚧
TIP
You can refer to Creating Tickets and Ignoring Issues for more information on completing bulk actions.

Regardless of the type of issue you are reviewing, all issues are automatically filtered into two tabs:

Active - All issues that require additional attention
Ignored - Issues that have been reviewed and ignored

Filtering Options

You now have the ability to use filters to refine your search.

Filter Groups

Depth

Filter Type	Description
Direct	Filter issues that are direct dependencies.
Transitive	Filter issues that are transitive dependencies.

Ticket

Filter Type	Description
Ticketed	Filter issues that already have a ticket associated.
Not Ticketed	Filter issues that have no associated tickets.
JIRA integrated	Filter issues that have a native JIRA integration
URL Linked	Filter issues that have a manual URL associated

Severity

Filter Type	Description
Critical	Filter Security issues that have CVSS score 9-10
High	Filter Security issues that have CVSS score 7-8.9
Medium	Filter Security issues that have CVSS score 4-6.9
Low	Filter Security issues that have CVSS score 0.1-3.9
Unknown	Filter Security issues that do not have a CVSS score

Fix Available

Filter Type	Description
None	Filter Security issues that do not currently have a known safe version
Patch	Filter Security issues that have a partial fix, that is a `Patch` increment as defined by semantic versioning
Minor	Filter Security issues that have a partial fix, that is a `Minor` increment as defined by semantic versioning
Major	Filter Security issues that have a partial fix, that is a `Major` increment as defined by semantic versioning
Unknown	Filter Security issues that have a partial fix, that is an `Unknown` increment because the package does not comply with semantic versioning

🚧
NOTE
Some definitions may be unexpected, but are aligned with semantic versioning rules. For example an increment from a prerelease version to a release version is considered a MAJOR increment

📘
NOTE
Partial Fix - Nearest update to fix the selected CVE. This fix may not resolve all vulnerabilities.
Complete Fix - Nearest update to fix all vulnerabilities found on this dependency

Exploit Maturity

Filter type	Description
Known exploit	Filter Security issues that have a known exploit as defined by CISA Known Exploit catalog
No known exploit	Filter Security issues that have a do not have a known exploit as defined by CISA Known Exploit catalog

First Found

Filter type	Description
Anytime	Filter Security issues that have been detected during any time frame.
Last 7 days	Filter Security issues that have been detected within the last 7 days
Last 14 days	Filter Security issues that that have been detected within the last 14 days
Last 30 Days	Filter Security issues that have been detected within the last 30 days

Package manager

The package manager filter enables a user to filter issues to only issues created by a particular ecosystem or package manager.

📘
NOTE
The package manager filter will only display options from available ecosystems in the given issue scope (Global, project, release group)

Project Label

Filter type	Description
Project Label	Filter to security issues detected in project(s) that use a FOSSA provided or user defined project label for additional business context. Multiple labels may be selected using `OR` based logic.

Team

The top-level team filters enables a user to filter to only issues detected by projects within the selected team(s). This filter displays issues for all teams by default

Filter type	Description
Team(s)	Filter to security issues detected in project(s) within a specific team. Multiple team(s) may be selected using `OR` based logic.

Sorting Options

Depending on the number of issues that are listed in your central inbox, it is helpful to sort issues based on specific criteria to support your remediation process. You can sort Issues based on:

When the Issue was found by FOSSA (newest to oldest or oldest to newest)
The package name (ascending or descending alphabetical order)
The severity of the listed issue (highest to lowest or lowest to highest)
Issue count per semantic version (Most issues or least issues)
EPSS score (Highest or Lowest)

📘
NOTE
The default sorting is set to Issue count when grouped by version and Severity (highest to lowest) when ungrouped.

📘
NOTE
EPSS sort is only available for ungrouped views

EPSS

Within both the issue inbox and issue drawer we have introduced EPSS as a new security input for prioritizing vulnerabilities. EPSS attempts to quantify the probability of a particular vulnerability (CVE) being exploited using various inputs such as code execution, CVE age, or known exploits. You can learn more about the EPSS model here

Issue Actions

You can initiate actions by selecting the checkbox next to any issue, giving you access to the action menu.

❗️
Important
Available actions will depend on product type (licensing, security, quality), issue status (active, ignored), issue scope (global, release group, project), and action type (individual, bulk). Please see the table below for a detailed breakdown.

Action	Description	Action type(s)	Product type(s)	Issue status	Issue scope(s)
Ignore (in current versions only)	Ignore the selected issue(s) for the current semantic version of the affected package. Doing so will ignore in only the selected, affected project(s). A new project revision containing any other semantic version of the package will generate a new active issue.	individual, bulk	licensing, security, quality	active	global, release group, project
Ignore (Auto-ignore in all versions)	only available for individual project issues Ignore the detected issue for all semantic versions of the affected package. Doing so will ignore in only the selected, affected project. Doing so will only apply to the selected issue type (Denied/Flagged license or a CVE) A new project revision containing any other semantic version of the package will be auto-ignored. Please see the auto-ignored section for full details.	individual	licensing, security	active	project
Create ticket	Create a ticket (JIRA) containing all selected issues. Please see Creating a Jira Ticket for full usage and configuration details. Doing so with a previously ticketed issue(s) selected will link to the new ticket only.	individual, bulk	licensing, security, quality	active, ignored	global, release group, project
Unlink ticket	Remove the association between the selected issue(s) and any linked tickets.	individual, bulk	licensing, security, quality	active, ignored	global, release group, project
Download CSV	Download a CSV containing all selected issues scoped by issue status(active or ignored)	individual, bulk	licensing, security, quality	active, ignored	global, release group, project
Unignore	Change selected issue(s) status from ignored to active. Note doing so will not end any existing auto-ignore rules. Please see the auto-ignore section for more details on stopping auto-ignore rules.	individual, bulk	licensing, security, quality	ignored	global, release group, project

Bulk Actions

You can action more than one issue at a time across all affected projects by using the select all or checking the boxes of the applicable issues in the global issues view.

❗️
IMPORTANT
By selecting the bulk action checkbox, it automatically selects all the issues listed on the page. To select all the applicable issues, you must click the Select all link that displays in green.

Issue Grouping

By default FOSSA issues will be grouped by semantic version. A user may change to the ungrouped view by selecting Version in the issue inbox header and changing to Ungrouped

Issue Drawer

The FOSSA issue detail UI has been updated with an easy to use issue drawer to quickly review and triage issues. A user can open the issue drawer by selecting anywhere within the desired issue's row.

Issue Drawer Controls

At the top right corner of an issue drawer a user can Expand , Share , or Close the issue drawer.

Issue Drawer Control	Description
Expand	Opens a full screen view of the selected issues in a separate tab
Share	Allows a user to copy a link to the expanded view of the selected issue
Close	Closes the selected issue drawer

Issue Drawer Issue Sub Navigation

The issue sub nav for a security issue is composed of the following sections:

Section	Description
Remediation	Describes the current version of the package and the recommended upgrade to fix the CVE when applicable. Lastly, whether that fix is a `partial fix` (remediates the selected CVE only) or `complete fix` (remediates all known CVEs for that package)
Vulnerability Details	All available information for the vulnerability. This will include information such as the CVE, CWE, affected/patched version ranges, EPSS, and review status
Dependency	Relevant information regarding the package itself, such as name, version, depth, and package manager/ecosystem
Description	Description of the CVE from NVD
NVD base metrics	The metrics used by NIST to calculate a CVSS score for the CVE. For more information please see NIST's overview here
References	Any references to advisories, solutions, or tools from NVD

Issue Drawer Projects Sub Navigation

The project sub nav for a security issue contains the following metadata:

Metadata	Description
Project Name	Title of the project in FOSSA
Issue Status	Whether the issue is `active` or `ignored` in that project
View Path	The origin and dependency path to determine where the package was detected within the project

Comments

Time and user stamped comments to track issue triage conversations.

Auto-ignore Rules

In order to persist an ignore decision across all versions of a package or across all projects, you can create auto-ignore rules.

Given the potential for unintended acceptance of risk by ignoring in all versions, we highly recommend extreme diligence when applying these options.

Auto-ignore is scoped to the combination of:

Package(s)
Project(s)
CVE

Ignore Modal

Given a user has the necessary permissions, auto-ignore permissions, when a user ignores they will see options for Where should it be ignored? & Which versions?

Where should it be ignored

The following options provide the user an ability to persist ignore decisions beyond the scope of the selected project or global issue:

Project Scope	Description
In this project	Creates an auto-ignore rule scoped to only the selected project
Include release groups	Creates an auto-ignore rule scoped to the selected project & any release group containing the selected project. Including future release groups
In this release group	Creates an auto-ignore rule scope to only the selected release group (Release group issue inbox only)
Globally	Creates an auto-ignore rule scoped to all projects & release groups regardless of policy

🚧
CAUTION
By design, auto-ignore rules persist to their selected scope for current and future projects. Please see "Managing Auto-ignore rules" for details on terminating rules.

Which versions

The following options provide the user an ability to persist ignore decisions beyond the scope of the selected package version:

Package Scope	Description
Selected Version	Creates an auto-ignore rule scoped to the current package version only
All versions	Creates an auto-ignore rule scope to all versions of the package, current and future.

📘
NOTE
If a user selects scopes ofin this project and selected version, no auto-ignore rule is created. This issue will become active when a new package version is submitted or a new project is detected.

Managing Auto-ignore rules

Within any issue inbox (Global, Project, Release group) a user may select View Ignore Rules to navigate to all applicable rules.

📘
NOTE
The Global issue inbox will contain all auto-ignore rules across every scope (Global, Policy, Release group, Project)
The Project/Release group issue inbox will contain only applicable Project/Release group auto-ignore rules and all global auto-ignore rules

Ignore rules contain the following metadata:

Metadata	Description
Issue Ignored	CVE being ignored
Package	The name of the package
Version	Either a specific package version or `All`
Scope	`Global` `Policy` `Project` or `Project + Release Group`
By	User who created the auto-ignore rule
Note	Ignore reason and ignore note provided when creating the auto-ignore rule. Please note these will also appear on issue details when applicable

A user may use the action icon to the far right to remove any auto-ignore rule.

Auto-ignore Permissions

See the table below for a detailed breakdown of permission required to create auto-ignore rules:

Scope	Required permissions
Project	Requires `Resolve Security issues of projects` permissions for the selected project or for all projects.
Release group	Requires `Resolve Security issues of release group` permissions and access to the selected release group or all projects/release groups.
Project + release group	Requires `Resolve Security issues of project` and `Resolve Security issues of release group` permissions. Also requires access to the selected project and access to all release groups
Global	Requires `Resolve Security issues of project` and `Resolve Security issues of release group` permissions. Also requires access to all projects and release groups

Reviewing Security Issues

🚧
TIP

Filtering Options