SCA – Upcoming Change in CAST Highlight CLI: Dependency Detection Defaults

As of version 5.10.8 of CAST Highlight’s CLI and version 1.2.18 of the Code Reader, we are introducing an important change in how Open Source Software (OSS) components are detected. This update is designed to improve scan performance and align detection results more closely with what is explicitly declared in your applications. See details in this article.

What’s Changing?

  • Today (current behavior): The CLI detects OSS components both by analyzing package manager files (e.g., pom.xml, package-lock.json, yarn.lock, etc.) and by fingerprinting individual files using their SHA256 signature.
  • With the new version (default behavior): Code Reader and CLI will only retain dependencies declared in package manager files. This means detection will primarily reflect the components your applications explicitly reference.

What If You Still Want File Fingerprinting?

If you prefer to continue detecting OSS components via file signature analysis (SHA256 fingerprinting), you can easily do so by running scans with the new option:

java -jar HighlightAutomation.jar --sourceDir C:\source --workingDir C:\temp --serverUrl https://... --companyId *** --applicationId *** --tokenAuth *** --fingerprint

This ensures that your scans include both:

  • Dependencies declared in package manager files, and
  • Components identified through file fingerprinting.

Balancing Accuracy and Coverage

By defaulting to package manager–based detection, your scan results will typically include fewer false positives, since only explicitly declared dependencies are retained. The trade-off is that some OSS usage may go unnoticed — for example, when developers directly copy/paste third-party source files or manually add external libraries without updating package manager files. Ultimately, it’s up to you to configure your scans based on your organization’s goals: prioritize clarity and accuracy by sticking with the default, or maximize coverage by enabling fingerprinting with --fingerprint.

Why This Change?

  • Clarity: Package manager–based detection aligns results with the dependencies that your teams explicitly declare and manage.
  • Performance: Scans run faster and generate leaner results without unnecessary noise.
  • Flexibility: You remain in control — file fingerprinting remains available via the --fingerprint flag.

How to Prepare

  • Review your current usage of the Code Reader and CLI.
  • If your workflows depend on file fingerprinting, update your scripts or pipelines to include the --fingerprint option.
  • If you rely primarily on package manager detection, no action is needed.

👉 This change will be available in the as of version 5.10.8 of the CLI, version 1.2.18 of the Code Reader, so we recommend updating your scanning processes in advance to avoid surprises.