Tools / Synopsys Detect Interview questions

Synopsys Detect is a command-line scanning tool that finds open source components in your code, builds and containers, and sends them to a Black Duck server. There they are matched against known vulnerabilities, licenses and operational risk data.

It is a single Java (Spring Boot) application that bundles several scan methods behind one command: package manager detectors, the signature scanner, binary scan and Docker image inspection. You do not wire each of them up separately.

Detect is free to download and its source is public, but most of its value needs a Black Duck instance and license to receive the results. Since Synopsys' software integrity business became Black Duck Software in 2024, newer documentation may call it Black Duck Detect.

Detect is the client-side collector; Black Duck is the server-side analysis platform. Detect gathers evidence of what is inside your software, and Black Duck turns that evidence into a Bill of Materials with vulnerability, license and policy information.

This split is why Detect cannot tell you a library is vulnerable on its own. Even the policy check that fails a build is just Detect asking the server for the verdict.

Detect groups its capabilities into tools, which you control with detect.tools (include) and detect.tools.excluded (exclude).

By default the detector and signature scan tools run. The others need an explicit input, such as an image name or a binary path, or they are switched on with a property. Newer releases add further tools, so check --help for your version.

There are two common ways: run the bootstrap script (detect.sh on Linux/macOS, a PowerShell equivalent on Windows), which downloads the latest Detect JAR and runs it, or download the JAR yourself and call java -jar.

At minimum you pass the server URL and an API token. Everything else has a default.

java -jar detect-<version>.jar \
  --blackduck.url=https://blackduck.example.com \
  --blackduck.api.token=$BD_TOKEN \
  --detect.project.name=shop-api \
  --detect.project.version.name=1.4.0

Run it from the root of the project. By default Detect scans the current directory, which you can change with detect.source.path.

The requirements depend on what you scan, but a typical online run needs:

• A supported Java runtime (check the release notes, since the minimum version rises over time).
• Network access to the Black Duck URL, so Detect can authenticate, download the signature scanner and upload results.
• A valid API token for a user allowed to create or update projects.
• The relevant build tools on the PATH for detectors that need them, such as mvn, gradle or pip.
• Enough disk and memory. The signature scanner defaults to about 4 GB of heap.

Docker scanning additionally needs access to the image, either from a Docker daemon or as a tar file.

A detector is the part of Detect that understands one package manager or build system, such as Maven, npm or NuGet, and turns its files into a dependency graph.

Each detector works in two checks. It is applicable when it finds its trigger file, for example pom.xml or package.json. It is extractable when everything it needs to run is present, such as the mvn executable or a lock file.

When both are true, Detect extracts the graph and writes it as a BDIO file. Detectors are identified by a type name such as MAVEN, GRADLE or NPM, which you use in include and exclude properties.

A signature scan uses the Black Duck Signature Scanner to fingerprint the files and folders under your source path. The fingerprints, not your source code by default, are matched on the server against the Black Duck KnowledgeBase.

Its strength is finding open source that never appears in a manifest: a library copied into /vendor, a JAR checked into the repo, or code pasted from a public project. Package manager detectors cannot see these.

Detect downloads the scanner from the Black Duck server, runs it with its own bundled Java, and writes the scan output as JSON under the run directory before uploading it. Optional snippet matching goes further and looks for copied fragments inside files.

BDIO stands for Black Duck Input/Output. It is a JSON-LD file format that describes a project, its dependencies and the relationships between them, using external identifiers that Black Duck understands.

Detectors write one BDIO document per extracted project. An identifier looks like a package manager coordinate, for example the Maven group, artifact and version of a library, plus the ecosystem it belongs to. That is how the server knows which component and version you mean.

Detect uploads the BDIO to create a code location and populate the BOM. In offline mode the files are only written to disk, so you can upload them later. Newer releases use the BDIO 2 variant of the format.

Detect is a Spring Boot application, so a property can be supplied in several places. When the same property appears more than once, the higher-priority source wins.

Environment variable names use upper case with underscores in place of dots. Run --help to list properties, and add a search term to filter them, which is the fastest way to find the right name.

The API token is how Detect authenticates to Black Duck without a username and password. You generate it from your user profile in the Black Duck UI and pass it as blackduck.api.token.

Detect uses it to obtain a bearer token for its REST calls: creating the project and version, uploading BDIO and scan files, polling for results and running the policy check.

The token carries the permissions of the user who created it. If scans fail with authorization errors, check that user's roles for the project before suspecting Detect. For pipelines, a dedicated service account with only the roles it needs is a cleaner choice than a personal token.

Use detect.project.name and detect.project.version.name.

--detect.project.name="Shop API"
--detect.project.version.name=2.1.0

If you leave them out, Detect tries to infer them. A detector may supply a name and version from the build file, for example from Maven coordinates. Otherwise the project name falls back to the source folder name and the version to a timestamp.

That fallback is a trap in CI: a timestamp version creates a new project version on every build. Set both explicitly using something stable such as the release number or branch name.

A code location is the unit under which Black Duck stores one scan's results and maps them to a project version. Every BDIO upload and every signature scan creates one, identified by a name.

The name matters. Re-running a scan with the same code location name replaces the earlier results, which keeps the BOM current. A different name creates a new code location, and the old one stays mapped, so removed components can linger in the BOM.

Detect builds the name from the project, version, scan type and path. You can add detect.project.codelocation.prefix or .suffix to keep names unique across similar repos, and override it with detect.code.location.name.

The BOM is the list of open source components found in a project version, built from every code location mapped to it.

For each component it shows the version, the license, known vulnerabilities (from NVD and Black Duck Security Advisories), operational risk such as project activity, and the match type: direct dependency, transitive dependency, file match or snippet match.

Policies are evaluated against the BOM, so the policy status of a project version comes from here. Teams can also adjust it by ignoring a false match or manually adding a component, and export it as a notices file or a risk report.

Each Detect execution creates a run directory where it keeps its working files. By default this lives under ~/blackduck, in a runs folder with one sub-folder per execution.

Inside you will find the generated BDIO files, the signature scanner output and logs. Downloaded tools such as the scanner and inspectors are kept in a separate tools location, so they are reused between runs.

The base location is set with detect.output.path. By default Detect cleans up the run directory when it finishes, controlled by detect.cleanup. Set it to false, or use diagnostic mode, when you need to inspect the files after a failure.

A binary scan uploads a compiled artifact, such as a JAR, firmware image or installer, to Black Duck Binary Analysis, which identifies open source components inside it without needing source or manifests.

You enable it by pointing at the file with detect.binary.scan.file.path, or at several files with detect.binary.scan.file.name.patterns.

--detect.binary.scan.file.path=build/libs/shop-api.jar

It suits third-party deliverables and legacy builds where the source is unavailable. It normally requires a separate Binary Analysis entitlement on the server, so a scan can fail even when everything else works.

Give Detect the image by name or as a tar file.

--detect.docker.image=myorg/shop-api:1.4.0
# or, without pulling from a daemon
--detect.docker.tar=/tmp/shop-api.tar

Detect then runs the Docker Inspector, which reads the OS package database inside the image to list Linux packages, and also signature-scans the image's file system to catch application libraries and copied code.

The results land in Black Duck as a project version. If you do not pass a project name and version, they are typically derived from the image repository and tag. Remember that scanning a base image reports its vulnerabilities too, so decide whether you want those in the same BOM as your app.

Detect returns an exit code that CI systems use to pass or fail the step. The commonly seen ones are:

More codes exist for newer features, so check the documentation for your Detect version. Code 3 is the one teams usually want, since it is the intended way to break a build.

Detect covers most mainstream ecosystems through its detectors. The list grows with each release, but it includes:

• JVM: Maven, Gradle, Ivy, sbt
• JavaScript: npm, Yarn, pnpm
• Python: pip, Pipenv, Poetry, Conda
• .NET: NuGet (solutions, projects and package config files)
• Go, Rust, PHP: Go modules, Cargo, Composer
• Ruby, Swift, Mobile: Bundler/RubyGems, Swift Package Manager, CocoaPods
• Others: Conan, Dart/Pub, Hex, Clojure/Leiningen, Bitbake, CPAN and more

Treat this as a snapshot and confirm against the documentation for your version before promising coverage to a team.

These two properties record how the software is used, and Black Duck policies can key off them.

--detect.project.version.phase=RELEASED
--detect.project.version.distribution=EXTERNAL

Distribution matters mostly for licenses. A copyleft license may be fine for INTERNAL use but a violation for EXTERNAL distribution, so setting this correctly changes the policy outcome. You can also set detect.project.tier to rank project priority.

In practice, set the phase from the pipeline stage, for example DEVELOPMENT on feature branches and RELEASED for tagged builds. Policies that only apply to released software will then ignore early branches, which keeps day-to-day noise down. If the values are not set, Black Duck uses its own defaults, so policies written around them may behave differently than you expect.

Detect walks the source directory, and for each folder it checks every detector for applicability (is the trigger file there?) and then extractability (can it actually run?).

flowchart TD
A["Visit folder"] --> B{Trigger file found?}
B -- No --> G["Go to next folder"]
B -- Yes --> C{Allowed by include/exclude?}
C -- No --> G
C -- Yes --> D{Tools and files present?}
D -- No --> E["Report not extractable"]
D -- Yes --> F["Extract dependency graph"]
F --> G

Several detectors can apply to one folder, for example Gradle and a lock file. Detect has built-in precedence rules, so a more reliable detector usually wins and lower ones are skipped for that folder. How deep the walk goes is set by detect.detector.search.depth, and what is allowed is shaped by the include and exclude type properties.

detect.detector.search.depth sets how many folder levels below the source path Detect inspects for detector trigger files. The default is 0, which means only the source folder itself.

That surprises people with a monorepo: a package.json three folders down is simply never looked at. Raise the depth to include it.

Deeper searches find more projects but also pick up test fixtures and samples, so pair a higher depth with exclusions.

There are separate switches for tools, detector types and folders.

# skip whole tools
--detect.tools.excluded=SIGNATURE_SCAN

# skip specific package managers
--detect.excluded.detector.types=NPM,PIP

# or allow only some
--detect.included.detector.types=MAVEN

# skip folders during detector search
--detect.detector.search.exclusion.paths=samples,test-fixtures

Use included when you want a strict allow-list, and excluded to remove a few noisy ones. Do not set both for the same run, as the combination is confusing to debug. For the signature scanner, folder exclusion has its own properties, covered separately.

A common real-world case is a repo with a Node-based docs site next to a Java service. Excluding NPM keeps the docs site out of the product BOM, while the Maven detector still runs normally. After changing exclusions, check the detector summary at the end of the run to confirm the right ones show as skipped rather than failed.

Set detect.policy.check.fail.on.severities to the policy severities that should fail the run.

--detect.policy.check.fail.on.severities=BLOCKER,CRITICAL

Valid values are BLOCKER, CRITICAL, MAJOR, MINOR, TRIVIAL, UNSPECIFIED, plus ALL and NONE. After uploading, Detect waits for the server to finish evaluating, asks for the policy status, and if a violated policy has one of the chosen severities it exits with code 3.

The policies themselves, and their severities, are defined in Black Duck, not in Detect. If a pipeline never fails, check that policies are assigned to the project and that the severity you listed actually matches one of them.

Start with BLOCKER,CRITICAL on a new rollout and tighten later, otherwise an existing backlog of findings can stop every team on day one. Note that failing the build only reflects the state of the BOM at scan time; a vulnerability published tomorrow will not fail yesterday's build.

The scan mode, set with detect.blackduck.scan.mode, decides whether results are stored in Black Duck.

Rapid and Stateless trade depth for speed. You do not get a persistent BOM or the usual project history, so they complement intelligent scans rather than replace them. Which tools each non-persistent mode supports has widened between versions, so confirm against your Detect release.

They look for open source in completely different ways, which is why Detect runs both by default.

A project that only declares dependencies is well covered by detectors. A project that pastes code or checks in JARs needs the signature scan. Use both, and exclude dependency folders from the signature scan so you do not count the same library twice.

Normal signature matching asks whether a whole file or folder matches a known open source file. Snippet matching asks a harder question: does a fragment inside your file match open source code?

The scanner breaks files into pieces, hashes them, and the server compares those hashes against a snippet index. That is how pasted or lightly edited code can be caught even though the file as a whole is unique.

You control it with detect.blackduck.signature.scanner.snippet.matching. Its values include SNIPPET_MATCHING and FULL_SNIPPET_MATCHING, with _ONLY variants that skip regular file matching. The fuller modes are slower and noisier.

Snippet hits are probabilistic. Each one should be reviewed in Black Duck and confirmed or ignored, not accepted blindly.

The signature scanner has its own exclusion properties, separate from detector exclusions.

# exclude by path pattern (folder names wrapped in slashes)
--detect.blackduck.signature.scanner.exclusion.patterns=/test/,/docs/

# exclude by directory name
--detect.blackduck.signature.scanner.exclusion.name.patterns=node_modules,vendor-sample

# scan only chosen sub-folders
--detect.blackduck.signature.scanner.paths=src,lib

Typical reasons to exclude: folders where a package manager already reports the dependencies (so they are not counted twice), test fixtures that contain deliberately old libraries, and large generated output that only slows the scan down.

Check the scan log afterwards to confirm the exclusions were applied as you intended.

If an exclusion seems to have no effect, the usual causes are a pattern missing its enclosing slashes, a typo in the folder name, or the path being matched relative to a different root than you assumed. Run a dry run with detect.blackduck.signature.scanner.dry.run=true to see what would be scanned without uploading anything.

For Maven or Gradle builds with several modules, the detector walks the module tree and records each module as a subproject of the root in the dependency graph.

By default each detector's output becomes its own code location, so a repo with Maven and npm parts produces separate ones. To see everything as a single combined BOM, set an aggregate name:

--detect.bom.aggregate.name=shop-platform

This merges the detector results into one aggregated BDIO instead of several. You can also trim the tree with properties such as detect.maven.excluded.modules or detect.gradle.excluded.projects, for example to leave out sample or test modules that should not count towards the product's BOM.

Offline mode lets Detect do its collection work without contacting Black Duck.

--blackduck.offline.mode=true

Detect still runs detectors and produces BDIO files, and the signature scanner can run in a dry-run style that writes its output locally. Nothing is uploaded, so you collect the files from the run directory and import them into Black Duck later through the UI or API.

Features that need the server are unavailable: the policy check, waiting for results, and report generation. Also note the signature scanner normally comes from the server, so offline runs need it supplied locally with detect.blackduck.signature.scanner.offline.local.path.

A practical pattern is to run offline on build agents that have no route to Black Duck, archive the run output as a build artifact, and have a connected job upload it. This keeps scanning decoupled from network rules, at the price of losing immediate policy feedback on the build itself.

Air-gapped here means no internet access, usually with an internal Black Duck server still reachable. That is different from fully offline mode.

Normally Detect downloads helper tools at run time: inspectors for Gradle and NuGet, the Docker Inspector, and the signature scanner. In an air gap those downloads fail, so you supply them ahead of time:

1. Download the Detect JAR and the air gap package from Black Duck on a connected machine.
2. Copy them to the isolated network and unpack the inspectors.
3. Point Detect at them with the relevant path properties, such as the signature scanner host URL or local path.
4. Run Detect with --blackduck.url pointing at the internal server.

If even the internal server is unreachable, switch to offline mode and upload results later.

You can use the Jenkins plugin for Detect, or simply call the bootstrap script from a shell step. The script route is portable and easy to read.

stage('Open Source Scan') {
  steps {
    withCredentials([string(credentialsId: 'bd-token', variable: 'BD_TOKEN')]) {
      sh '''#!/bin/bash
        bash <(curl -s -L $DETECT_SCRIPT_URL) \
          --blackduck.url=https://blackduck.example.com \
          --blackduck.api.token=$BD_TOKEN \
          --detect.project.name=${JOB_NAME} \
          --detect.project.version.name=${BRANCH_NAME} \
          --detect.policy.check.fail.on.severities=BLOCKER,CRITICAL
      '''
    }
  }
}

Store the token as a Jenkins credential so it is masked in logs. Because the step returns Detect's exit code, a policy violation fails the stage automatically. Add a pinned Detect version so builds are repeatable.

Use the branch name as the version for multibranch pipelines, so each branch gets its own BOM. Consider running the stage only on pull requests and the main branch, since scanning every commit on every branch can overload the server and slow feedback.

Detect needs the proxy for both Black Duck calls and tool downloads, and it uses the blackduck.proxy.* properties.

--blackduck.proxy.host=proxy.corp.example.com
--blackduck.proxy.port=3128
--blackduck.proxy.username=svc-detect
--blackduck.proxy.password=$PROXY_PASS
--blackduck.proxy.ignored.hosts=blackduck.internal.example.com

For NTLM proxies add blackduck.proxy.ntlm.domain. Use the ignored-hosts property for an internal Black Duck server that should be reached directly.

Keep the password out of the command line where possible. Use the environment variable BLACKDUCK_PROXY_PASSWORD instead. A wrong proxy setting usually ends in a proxy connectivity failure, exit code 4.

To verify the settings, run a short scan with only the detector tool and read the connection lines at the top of the log. If the proxy needs a custom certificate for HTTPS inspection, that certificate must also be trusted by Java, otherwise you will see certificate errors that look like a connection problem rather than a proxy problem.

Detect can ask Black Duck to build reports once the scan has been processed.

# PDF risk report
--detect.risk.report.pdf=true
--detect.risk.report.pdf.path=./reports

# open source notices file
--detect.notices.report=true
--detect.notices.report.path=./reports

The risk report summarizes vulnerabilities, license and operational risk. The notices report lists components and license text, which is what legal teams usually need for attribution.

Both depend on the server finishing its analysis, so Detect waits for results first. That makes the run longer, and these properties cannot work in offline mode.

Archive the generated files as build artifacts so each release has its own attribution file and risk summary. Keep the output path outside the scanned source folder, otherwise the next signature scan may pick up the report files themselves.

Buildless mode tells detectors to read project files directly instead of running the build tool.

--detect.detector.buildless=true

A normal Maven scan runs Maven so it can resolve exact versions. In buildless mode Detect parses files such as pom.xml itself, so you do not need the toolchain, the repositories or even a working build.

The cost is accuracy. Declared versions may be property placeholders, imported BOMs may not be expanded, and transitive dependencies may be incomplete. Use buildless for quick scans, environments without the toolchain, or when the build is broken. For release gating, prefer full detectors.

A useful middle path is to run buildless on every pull request for speed, then run the full detector on the release branch, where accuracy matters. Compare the two BOMs once to learn how much your own projects differ between the modes.

The detector is applicable, because it found pom.xml, but not extractable, because there is no Maven to run. Detect logs that fact in its detector summary and moves on without producing a BOM for that module.

That can look like a successful run with missing results, so make it fail loudly if the Maven scan matters:

--detect.required.detector.types=MAVEN

If a required detector does not run, Detect ends with a detector-required failure code instead of quietly succeeding.

To fix the cause, install Maven, add a mvnw wrapper to the repo, or point to it with detect.maven.path. If you cannot run Maven at all, switch to buildless mode.

Both detectors ask the build tool itself, so they see the same dependency versions the build resolves, including transitive ones.

Because the real tool runs, it needs network access to your artifact repositories, valid credentials in settings.xml or Gradle properties, and a project that builds. That is what makes the results accurate, and also why these detectors fail on broken builds.

Test and development libraries are not shipped, so counting them inflates vulnerabilities. Each ecosystem has its own filter:

# Maven: drop scopes
--detect.maven.excluded.scopes=test,provided

# Gradle: keep only runtime configurations
--detect.gradle.included.configurations=runtimeClasspath

# npm: skip devDependencies
--detect.npm.include.dev.dependencies=false

Pick one approach per ecosystem rather than mixing include and exclude. Be careful with provided scope in Maven: the app server supplies those libraries at runtime, so excluding them may hide real risk in the deployed system.

Rescan and compare the BOM afterwards to confirm that only non-shipped components disappeared.

Remember that dev tools can still end up in what you ship, for example a bundler plugin that injects code into a front-end build. If the output contains anything from a dev dependency, include that tool deliberately rather than relying on the blanket exclusion.

The npm detectors prefer lock files, because they record the exact resolved version of every direct and transitive package. In order of reliability they use package-lock.json, npm-shrinkwrap.json, and as a last resort package.json.

A package.json alone only gives version ranges such as ^4.17.0, so the result is less exact. Yarn projects use yarn.lock and pnpm projects use pnpm-lock.yaml.

No npm install is needed to parse a lock file, and node_modules is skipped by default in both detector search and signature scan. Commit your lock file, since without it your BOM will not match what you actually deploy.

Which detector runs depends on the files present.

For the pip detector, activate the project's virtual environment and run pip install -r requirements.txt first. The detector inspects what is installed, so an empty environment gives an empty BOM.

--detect.pip.requirements.path=requirements.txt
--detect.pip.project.name=shop-worker

If both python and python3 exist, make sure Detect uses the one matching your project.

In CI, create the virtual environment and install dependencies as a step before Detect, and reuse that same environment for the scan. For projects with a lock file, the Pipenv or Poetry detectors are generally preferable because they do not depend on the machine's installed state.

A run follows the same stages whatever the project.

flowchart TD
A["Load properties and validate"] --> B["Connect to Black Duck"]
B --> C["Create or find project and version"]
C --> D["Run tools: detectors, signature scan, binary, docker"]
D --> E["Write BDIO and scan files"]
E --> F["Upload to Black Duck"]
F --> G["Wait for server processing"]
G --> H["Policy check and reports"]
H --> I["Set exit code and clean up"]

1. Configuration: properties from arguments, environment and files are merged and validated. A bad value ends here with the configuration failure code.
2. Connection: Detect authenticates and downloads the signature scanner if needed.
3. Tools run: each selected tool produces output files in the run directory.
4. Upload and wait: the files are sent, and Detect waits when a policy check or report needs results.
5. Finish: it prints a status summary, cleans up, and exits with the code that reflects the outcome.

The summary shows each detector's status, which makes it the first place to look when something is missing.

Detect hands image scanning to the Docker Inspector, a helper it downloads on demand.

sequenceDiagram
participant D as Detect
participant I as Docker Inspector
participant B as Black Duck
D->>I: Image name or tar
I->>I: Save image, extract layers
I->>I: Read OS release and package database
I->>D: BDIO for OS packages + squashed image
D->>B: Upload BDIO and signature scan
B-->>D: Project version BOM

The inspector obtains the image (from a daemon, a registry or your detect.docker.tar), unpacks the layers and identifies the Linux distribution from files such as /etc/os-release. It then reads the package database (dpkg, rpm or apk) to list installed OS packages.

Because OS packages do not cover application libraries, Detect also signature-scans the image's merged file system. The two sets of evidence combine in one project version. It is why an image BOM can include both distro packages and your own JARs.

Work from the simplest evidence outward.

1. Read the status summary at the end of the console output. It lists each detector's result and the overall exit code.
2. Raise log detail with --logging.level.detect=DEBUG (or TRACE) and rerun.
3. Keep the files by setting --detect.cleanup=false, then inspect the BDIO and scan output in the run directory.
4. Use diagnostic mode with --detect.diagnostic=true, which zips the run directory, logs and configuration into one archive for Black Duck support. detect.diagnostic.extended gathers more.
5. Isolate the failing tool using detect.tools, so you only rerun the part that broke.

Check the diagnostic zip for secrets before sharing it. Detect masks sensitive property values in its own output, but your build files may still contain private repository details.

Exit code 1 means Detect could not reach or authenticate to the server. Narrow the cause down in this order:

Always run the test from the same machine that fails. Connectivity from your laptop proves nothing about a locked-down CI agent. Avoid leaving trust.cert on in production, since it skips validation.

A code location is keyed by its name, so anything that changes the name creates a new one while the old one stays mapped to the project version. Components you removed then keep appearing in the BOM.

Common triggers:

• Using a changing project version name, such as a timestamp or build number, in the code location name.
• Scanning from a different folder or agent path, which changes the generated name.
• Renaming a repository or branch without updating the Detect properties.

To fix it, use stable names with detect.project.codelocation.prefix or .suffix, or fix the name directly with detect.code.location.name. Setting detect.project.codelocation.unmap=true unmaps older code locations from the version during a scan, and unwanted ones can be deleted in the UI.

Most of the time goes to the signature scan, build-tool resolution and waiting on the server, so focus on those.

• Trim the signature scan: exclude dependency, test and generated folders, or limit it to specific paths.
• Run only the tools you need: --detect.tools=DETECTOR is much faster for a quick check.
• Avoid re-downloading: reuse the tools folder between runs, or set a local scanner with detect.blackduck.signature.scanner.local.path.
• Use buildless mode where exact transitive accuracy is not needed.
• Use Rapid or Stateless scans for pull requests so you skip the full BOM processing.
• Do not wait unnecessarily: keep detect.wait.for.results off unless you need the policy result.
• Tune parallelism and memory: the scanner exposes parallel processor and memory properties.

Measure before and after on your own repo, as the biggest win depends on whether the tree is mostly vendored files or mostly declared dependencies.

Vulnerability impact analysis checks whether your Java code actually calls the vulnerable part of a library, not just whether the library is present. It helps you separate reachable vulnerabilities from theoretical ones.

When enabled with detect.impact.analysis.enabled=true, Detect builds a call graph from your compiled classes and uploads it. Black Duck compares it with the vulnerable methods named in its Security Advisories and marks each matching vulnerability as reachable or not.

Some points to remember:

• It supports Java projects only.
• It needs compiled classes, so run it after the build, not before.
• It depends on advisory data and a suitable license on the server.

Treat "not reachable" as a way to prioritize fixes, not as permission to ignore a vulnerability forever, since code paths change.

The bootstrap script downloads the latest Detect release by default. A new release can change defaults, deprecate or rename properties, or raise the minimum Java version, so a pipeline that worked yesterday can fail today without any change on your side.

Pin the version with an environment variable the script reads:

export DETECT_LATEST_RELEASE_VERSION=<version>

Pinning gives you repeatable results, which matters when a BOM or policy outcome has to be explained later. It also lets you cache the JAR in a download folder instead of fetching it on every run.

Upgrade deliberately: read the release notes, try the new version on one pipeline first, and compare the results before rolling it out. Also confirm the version is compatible with your Black Duck server release.

Treat the token like a password and keep it out of source control and logs.

1. Store it in the CI system's secret store: Jenkins credentials, GitHub Actions secrets, or Azure DevOps variable groups.
2. Pass it through the environment variable BLACKDUCK_API_TOKEN rather than as a command-line argument, since arguments can show up in process lists and shell traces.
3. Create a dedicated service account with only the roles scanning needs, instead of using a personal token.
4. Rotate it on a schedule and revoke it when a pipeline is retired.

export BLACKDUCK_API_TOKEN="$BD_TOKEN_FROM_SECRET_STORE"
./detect.sh --blackduck.url=https://blackduck.example.com

Detect masks sensitive values in its configuration output, but build scripts that echo variables can still leak them. Avoid set -x around that step.

Snippet matches are probabilistic, so some noise is expected. Reduce it in layers.

1. Scan less noise: exclude test fixtures, generated code and third-party folders that detectors already cover.
2. Pick a lighter matching mode: the broader modes of detect.blackduck.signature.scanner.snippet.matching find more but also raise false hits.
3. Review in Black Duck: open the Source tab, compare the matched file with the open source original, and either confirm the match or ignore it.
4. Record the decision: ignored matches stay ignored on later scans of the same project version, so the review effort is not repeated.
5. Check the license and component: a match to a tiny, generic function is often not meaningful, while a match to a large block usually is.

Keep a short team rule for what counts as a confirmed match, so reviews stay consistent between people.

Use Rapid scan when you want quick feedback on a pull request and do not need a stored BOM. It returns policy violations for the dependencies found, and nothing is kept as a project version.

--detect.blackduck.scan.mode=RAPID
--detect.blackduck.rapid.compare.mode=BOM_COMPARE
--detect.policy.check.fail.on.severities=BLOCKER,CRITICAL

The compare mode decides what is reported. ALL lists every violation found, while BOM_COMPARE reports only violations that are new relative to the existing project BOM, which stops developers being blamed for old issues.

Pair it with Intelligent scans on main or release branches, so the persistent BOM, history and reports stay up to date. If a PR check must also include signature or container results, look at Stateless mode, and confirm what your Detect version supports.