Dependency Track

Dependency Track is an analysis platform that can be used to identify known vulnerabilities in the software supply chain.

More information

• Dependency Track website: https://dependencytrack.org/
• Dependency Track documentation: https://docs.dependencytrack.org/

Basic features

• Services load Software Bill of Materials (SBOM) information to the Dependency Track service, using CycloneDX format.
  • You can find tools to build SBOM from https://cyclonedx.org/tool-center/
• Dependency Track keeps track of the known component vulnerabilities using various data sources:
  • National Vulnerability Database (NVD)
  • GitHub Advisories
  • Open Source Vulnerabilities (OSV)
  • Sonatype OSS Index
• Dependency Track scans components periodically and marks known vulnerabilities.
  • Notification of the detected vulnerabilities can be sent to email/Teams/Slack/Jira...
• Tracks organization policy violations.
  • I.e. critical component vulnerability was left unaddressed for too long, for the service of this risk level.
• Allows managing vulnerabilities and policy violations.
  • You can analyze vulnerabilities and suppress false positives, not affected etc. with audit trail.
• Additionally, Dependency Track can also be used to license evaluation, detection of outdated components etc.

Use policy

Dependency Track is primarily intended for monitoring production services. All services and environments that handle personal data or other confidential information are considered production services.

By linking your service to Dependency Track, you commit to:

• keeping the service dependency information up-to-date (automation is recommended), and
• handling findings according to the guidelines below,
• removing the service data from Dependency Track at the end of the service lifecycle.

High and critical level vulnerabilities

It's strongly recommended to triage such findings immediately.

They must be addressed within seven (7) days by

• Updating the version OR
• Analyzing the component and defining the action in Dependency Track.

Medium and lower-level vulnerabilities

Handling of lower-level vulnerabilities is strongly recommended but not currently required by policy.

Suppressing vulnerabilities

Suppressing vulnerability hides it from the default view and statistics.

• False positives or Not Affected findings should be suppressed.
  • For Not Affected findings, the justification field must also be filled out.
• Other findings should not be suppressed.

Justifications for Use policy

In addition to monitoring individual services, Dependency Track is also used for overall situation monitoring by the university IT security team and partly to demonstrate compliance with data processing and security requirements.

The realization of these needs requires some common practices and rules for using the service.

How to use Dependency Track

Dependency Track UI: https://dtrack.it.helsinki.fi

Access rights

Access rights may be requested by the university employees, using self-service.

• All access rights to the service are granted based on IAM groups.
• All group members have identical rights.
• Users are identified via SSO at login.helsinki.fi.
  • If you are not a member of the IAM group that has been added to the service, login will fail.

IAM groups give you access to Team/Portfolio of specific projects (services).

Triage process

1. Open Dependency Track UI, open project from the Projects section and access the Audit Vulnerabilities tab.

2. Click arrow next to the component to show vulnerability details.
3. Assess whether the vulnerability impacts your service and choose the appropriate Analysis action.
   1. If the outcome is Not Affected, also select a Justification from the provided list (e.g. code not used, or protected by some other compoent).
   2. If the finding is determined to be a False Positive or Not Affected, hide finding by clicking Suppress selection.
4. Fill any other fields required by your service administration policies.
   1. You can leave comments and justification details. They are not required in the Dependency Track use policy but may be required by your team's policies.

Adding services

Adding new services and updating component information can be done via API.

API keys can be managed with self-service.

Examples of creating BOM and loading it to Dependency Track

Notifications

Notifications of the detected vulnerabilities can be requested with self-service.

Currently supported notification channels are Email, Jira, Slack and Teams.

Notification channel is set for the team (IAM-group), and notifications for a project are enabled by adding tag "grp-name" to the project. Add tag by opening a project view from the Projects section and selecting View Details below the project name.

Notifications are sent when new vulnerabilities or policy violations are detected, or BOM upload or analysis fails.