Red Hat Dependency Analytics (RHDA) plugin gives you awareness to security concerns within your software supply chain while you build your application.

Dependency Analytics supports multiple package managers:

• Maven (mvn)
• NPM (npm)
• PNPM (pnpm)
• Yarn Berry and Classic (yarn)
• Gradle Kotlin and Groovy (gradle)
• Golang (go mod)
• Python (pip) ecosystems, and base images in Dockerfile.

In future releases, Red Hat plans to support other package managers.

NOTE: The Red Hat Dependency Analytics plugin is an online service hosted and maintained by Red Hat. Dependency Analytics only accesses your manifest files to analyze your application dependencies before displaying the vulnerability report.

• Red Hat Dependency Analytics - Table of Contents
  • Quick start
  • Configuration
  • Features
  • Know more about the Red Hat Dependency Analytics platform
  • Data and telemetry
  • Support, feedback & questions
  • License

Prerequisites

• For Maven projects, analyzing a pom.xml file, you must have the mvn binary in your IDE's PATH environment.
• For Node projects, analyzing a package.json file, you must have one of the corresponding package manager npm, pnpm or yarn, node binaries in your IDE's PATH environment.
• For Golang projects, analyzing a go.mod file, you must have the go binary in your IDE's PATH environment.
• For Python projects, analyzing a requirements.txt file, you must have the python3 and pip3 binaries in your IDE's PATH environment.
• For Gradle projects, analyzing a build.gradle file or build.gradle.kts file, you must have the gradle binary in your system's PATH environment.
• For base images, analyzing a Dockerfile, you must have the syft and skopeo binaries in your IDE's PATH environment.

Procedure

1. Install IntelliJ IDEA on your workstation.
2. After the installation finishes, open the IntelliJ IDEA application.
3. From the menu, click Settings , and click Plugins.
4. Search the Marketplace for Red Hat Dependency Analytics.
5. Click the INSTALL button to install the plugin.
6. To start scanning your application for security vulnerabilities, and view the vulnerability report, you can do one of the following:
   • Open a manifest file, hover over a dependency marked by the inline Component Analysis, indicated by the wavy-red line under a dependency, and click Detailed Vulnerability Report.
   • Right click on a manifest file in the Project window, and click Dependency Analytics Report.

The Red Hat Dependency Analytics plugin has some configurable parameters that allows you to customize its behavior according to your preferences.

Procedure

1. Open the IntelliJ IDEA application.

2. From the menu, click Settings , and click Tools.

3. Click Red Hat Dependency Analytics.

   

Configurable parameters

• Maven :
  Set the full path of the Maven executable, which allows Exhort to locate and run the mvn command to resolve dependencies for Maven projects.
  Path of the JAVA_HOME directory is required by the mvn executable.
  If the paths are not provided, your IDE's PATH and JAVA_HONE environments will be used to locate the executables.

• Maven Wrappers :
  preferWrapper: Configure whether to use Maven wrapper. There are three options available:
  true: Always use the wrapper regardless of Build,Execution,Deployment › Build Tools > Maven: Maven home path setting
  false: Never use the wrapper regardless of Build,Execution,Deployment › Build Tools > Maven: Maven home path setting
  fallback: Use IntelliJ's Build,Execution,Deployment › Build Tools > Maven: Maven home path setting (default behavior)

• Node :
  Set the full path of the Node executable, which allows Exhort to locate and run one of the corresponding npm, pnpm or yarn command to resolve dependencies for Node projects.
  Path of the directory containing the node executable is required by one of the corresponding npm, pnpm or yarn executable.
  If the paths are not provided, your IDE's PATH environment will be used to locate the executables.

• Golang :
  Set the full path of the Go executable, which allows Exhort to locate and run the go command to resolve dependencies for Go projects.
  If the path is not provided, your IDE's PATH environment will be used to locate the executable.
  When option Strictly match package version is selected, the resolved dependency versions will be compared to the versions specified in the manifest file, and users will be alerted if any mismatch is detected.

• Python :
  Set the full paths of the Python and the package installer for Python executables, which allows Exhort to locate and run the pip3 commands to resolve dependencies for Python projects.
  Python 2 executables python and pip can be used instead, if the Use python 2.x option is selected.
  If the paths are not provided, your IDE's PATH environment will be used to locate the executables.
  When option Strictly match package version is selected, the resolved dependency versions will be compared to the versions specified in the manifest file, and users will be alerted if any mismatch is detected.
  Python virtual environment can be applied, when selecting the Use python virtual environment option.
  If selecting option Allow alternate package version while using virtual environment, the dependency versions specified in the manifest file will be ignored, and dependency versions will be resolved dynamically instead (this feature cannot be enabled when Strictly match package version is selected).

• Gradle :
  Set the full path of the Gradle executable, which allows Exhort to locate and run the gradle command to resolve dependencies for Gradle projects.
  By not setting a path to the gradle binary, IntelliJ IDEA uses its default path environment to locate the file.

• Image :
  Set the full path of the Syft executable, which allows Exhort to locate and run the syft command to generate Software Bill of Materials for the base images.
  Optionally, set the full path of the Docker or Podman executable. Syft will attempt to find the images in the Docker or Podman daemon with the executable. Otherwise, Syft will try direct remote registry access.
  Set the full path of the Skopeo executable, which allows Exhort to locate and run the skopeo command to determine the image digests.
  If the paths are not provided, your IDE's PATH environment will be used to locate the executables.
  If a Syft configuration file is used and not at the default paths, set the full path to the configuration file in configuration.
  If an authentication file is applied for skopeo inspect, set the full path to the file in configuration.
  If platform is not specified in the Dockerfile for multi-platform images the default platform is used, as set in the configuration. Otherwise, set the full path of the Docker or Podman executable, then Exhort will use the executable to find the image platform based on the operating system and architecture of the container runtime.

• Inline Vulnerability Severity Alerts :
  You can set the vulnerability severity alert level to Error or Warning for inline notifications of detected vulnerabilities.

• Proxy Configuration :
  From IntelliJ IDEA Appearance & Behavior > System Settings > HTTP Proxy, you can configure a static proxy for all HTTP requests made by the plugin. This is useful when your environment requires going through a proxy to access external services. For example:http://proxy.example.com:8080

• Manifest Exclusion Patterns :
  You can exclude manifest files from component analysis using glob patterns. This is useful for excluding third-party dependencies, test files, or other manifests that should not be analyzed.
  Enter one pattern per line. Examples: **/node_modules/**/package.json to exclude all package.json files in node_modules directories, or test/**/pom.xml to exclude all Maven files in test directories.

• Component analysis
  Upon opening a manifest file, such as a pom.xml, package.json, go.mod or requirements.txt file, a scan starts the analysis process. The scan provides immediate inline feedback on detected security vulnerabilities for your application's dependencies. Such dependencies are appropriately underlined in red, and hovering over it gives you a short summary of the security concern. The summary has the full package name, version number, the amount of known security vulnerabilities, and the highest severity status of said vulnerabilities.

  

• Dockerfile scanning
  Upon opening a Dockerfile, a vulnerability scan starts analyzing the images within the Dockerfile. After the analysis finishes, you can view any recommendations and remediation by clicking the More actions... menu from the highlighted image name. Any recommendations for an alternative image does not replace the current image. By clicking Switch to..., you go to Red Hat's Ecosystem Catalog for the recommended image.

  
  You must have the syft and skopeo binaries installed on your workstation to use the Dockerfile scanning feature. You can specify a specific path to these binaries, and others by settings the following parameters as environment variables or system properties:

  • TRUSTIFY_DA_SYFT_PATH : Specify the absolute path of syft executable.
  • TRUSTIFY_DA_SYFT_CONFIG_PATH : Specify the absolute path to the Syft configuration file.
  • TRUSTIFY_DA_SKOPEO_PATH : Specify the absolute path of skopeo executable.
  • TRUSTIFY_DA_SKOPEO_CONFIG_PATH : Specify the absolute path to the authentication file used by the skopeo inspect command.
  • TRUSTIFY_DA_DOCKER_PATH : Specify the absolute path of docker executable.
  • TRUSTIFY_DA_PODMAN_PATH : Specify the absolute path of podman executable.
  • TRUSTIFY_DA_IMAGE_PLATFORM : Specify the platform used for multi-arch images.
  • TRUSTIFY_DA_MVN_USER_SETTINGS : Specify the absolute path to the Maven user settings file.
  • TRUSTIFY_DA_MVN_LOCAL_REPO : Specify the absolute path to the Maven local repository.

  

This plugin implements a custom Dockerfile parser to provide syntax highlighting and analysis without requiring the Docker plugin dependency. The parser is built using JFlex lexer and Grammar-Kit parser generators.

• Grammar Definition: src/main/java/org/jboss/tools/intellij/image/build/dockerfile.bnf - Defines Dockerfile syntax rules using Grammar-Kit BNF format
• Lexer Specification: src/main/java/org/jboss/tools/intellij/image/build/dockerfile.flex - Defines token patterns using JFlex format
• Generated Classes: PSI (Program Structure Interface) classes are generated in src/main/java/org/jboss/tools/intellij/image/build/psi/

When modifying the grammar or lexer files, you need to regenerate the parser classes:

1. Install JFlex (if not already installed):

   # Download JFlex 1.9.2 or later
   wget https://github.com/jflex-de/jflex/releases/download/v1.9.2/jflex-1.9.2.jar

2. Generate Lexer:

   java -jar jflex-1.9.2.jar src/main/java/org/jboss/tools/intellij/image/build/dockerfile.flex

3. Generate Parser (using Grammar-Kit plugin in IntelliJ):

   • Open the .bnf file in IntelliJ IDEA
   • Right-click and select "Generate Parser Code" from context menu
   • Or use Tools → Grammar Kit → Generate Parser Code

4. Important Notes:

   • Always use IMAGE_NAME_TOKEN (not IMAGE_NAME) in both grammar and lexer to avoid naming conflicts
   • The ANY_CHAR token serves as a catch-all for any non-whitespace characters in Dockerfile instructions
   • Generated PSI classes should be committed to git to ensure reproducible builds

• All standard Dockerfile instructions (FROM, RUN, COPY, ADD, etc.)

• Multi-stage builds with AS aliases

• Platform specifications (--platform flag)

• Variable substitution (${VAR} and $VAR)

• Comments and complex shell commands

• Comprehensive syntax error handling

• Excluding dependencies with trustify-da-ignore
  You can exclude a package from analysis by marking the package for exclusion. If you want to ignore vulnerabilities for a dependency in a pom.xml file, you must add trustify-da-ignore as a comment against the dependency, group id, artifact id, or version scopes of that particular dependency in the manifest file. For example:

  <dependency> <!--trustify-da-ignore-->
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
  </dependency>

  If you want to ignore vulnerabilities for a dependency in a package.json file, you must add trustify-da-ignore as a attribute-value pair. For example:

  {
      "name": "sample",
      "version": "1.0.0",
      "description": "",
      "main": "index.js",
      "keywords": [],
      "author": "",
      "license": "ISC",
      "dependencies": {
          "dotenv": "^8.2.0",
          "express": "^4.17.1",
          "jsonwebtoken": "^8.5.1",
          "mongoose": "^5.9.18"
      },
      "trustify-da-ignore": [
          "jsonwebtoken"
      ]
  }

  If you want to ignore vulnerabilities for a dependency in a go.mod file, you must add trustify-da-ignore as a comment against the dependency in the manifest file. For example:

  require (
      golang.org/x/sys v1.6.7 // trustify-da-ignore
  )
  

  If you want to ignore vulnerabilities for a dependency in a requirements.txt file, you must add trustify-da-ignore as a comment against the dependency in the manifest file. For example:

  requests==2.28.1 # trustify-da-ignore
  

  If you want to ignore vulnerabilities for a dependency in a build.gradle file, you must add trustify-da-ignore as a comment against the dependency in the manifest file. For example:

  implementation "log4j:log4j:1.2.17" // trustify-da-ignore
  implementation group: 'log4j', name: 'log4j', version: '1.2.17' // trustify-da-ignore
  

• Excluding developmental or test dependencies
  Red Hat Dependency Analytics does not analyze dependencies marked as dev or test, these dependencies are ignored. For example, setting test in the scope tag within a pom.xml file:

  <dependency>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
      <scope>test</scope>
  </dependency>

  For example, setting devDependencies attributte in the package.json file:

  {
      "name": "sample",
      "version": "1.0.0",
      "description": "",
      "main": "index.js",
      "keywords": [],
      "author": "",
      "license": "ISC",
      "dependencies": {
          "dotenv": "^8.2.0",
          "express": "^4.17.1",
          "jsonwebtoken": "^8.5.1",
          "mongoose": "^5.9.18"
      },
      "devDependencies": {
          "axios": "^0.19.0"
      }
  }

  For example, setting exclude attribute in the go.mod file:

  exclude golang.org/x/sys v1.6.7
  
  exclude (
      golang.org/x/sys v1.6.7
  )
  

  You can create an alternative file to requirements.txt, for example, a requirements-dev.txt or a requirements-test.txt file where you can add the development or test dependencies there.

• Excluding manifest files with patterns
  You can exclude specific manifest files from component analysis using configurable glob patterns. This feature allows you to avoid analyzing third-party dependencies, test files, or other manifests that are not relevant to your security analysis.
  Patterns are configured in the plugin settings under Tools > Red Hat Dependency Analytics > Manifest Exclusion Patterns.
  Examples of exclusion patterns:

  • **/node_modules/**/package.json - Excludes all package.json files in node_modules directories
  • test/**/pom.xml - Excludes all Maven pom.xml files in test directories
  • vendor/**/*.go.mod - Excludes all go.mod files in vendor directories
  • **/build.gradle - Excludes all Gradle build files
    Right-click on any manifest file and select Exclude from Component Analysis to quickly add an exclusion pattern for that specific file.

• Red Hat Dependency Analytics report
  The Red Hat Dependency Analytics report is a temporary HTML file that exist if the Red Hat Dependency Analytics Report tab remains open. Closing the tab removes the temporary HTML file.

The goal of this project is to significantly enhance a developer's experience by providing helpful vulnerability insights for their applications.

• GitHub Organization

The Red Hat Dependency Analytics plugin for IntellJ IDEA collects anonymous usage data and sends it to Red Hat servers to help improve our products and services. Read our privacy statement to learn more. This plugin respects the settings of the Telemetry by Red Hat plugin, which you can learn more about here.

The Red Hat Dependency Analytics plugin for IntelliJ IDEA in current version, supports the following IntelliJ IDEA versions:

• 2022.1
• 2022.2
• 2022.3
• 2023.1
• 2023.2
• 2023.3

There are two ways you can contact us:

• You can reach out to us at rhda-support@redhat.com with any questions, feedback, and general support.
• You can also file a GitHub Issue.

EPL 2.0, See LICENSE for more information.