You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Black Duck-shaped export matches the transformed reports, and analyse writes it
export-blackduck is gone; analyse does its job
depinder export-blackduck is removed. depinder analyse <folders...> now sorts every file it finds by content: a CycloneDX SBOM whose metadata.tools credits Trivy, one that credits Syft, or native input. File names and folder names decide nothing: a *.cdx.json is read by name, and any other *.json whose first bytes declare "bomFormat": "CycloneDX" is read too. An SBOM from any other tool, or a *.cdx.json that is not CycloneDX, is named in a warning and skipped.
The results folder gains one subfolder per source found: trivy/ and syft/ each hold exactly what export-blackduck wrote for that input alone (the sbom-* CSV triples, sbom-scan-provenance.json, security.csv and the seven other Black Duck-shaped files); depinder/ holds the native plugins' <plugin>-*.csv triples, empties included. A subfolder appears only when its source had input. Native runs no longer write security.csv: that file describes SBOMs.
--project-name and --target moved to analyse. The default project name is the SBOMs' shared repository name, else the input folder's name. The repository name comes from the SBOM's metadata.component.name, which both tools fill with the scanned directory's name, and falls back to the file name; the projects in sbom-<eco>-libs.csv are named the same way.
The same repository twice from one producer is analysed twice and warned about. Trivy and Syft SBOMs of the same repository in one folder are fine: they go to different subfolders.
sbom-scan-provenance.json now records, per SBOM, which tool wrote it and at which version, and lists only the SBOMs of its subfolder.
One invocation opens the registry cache once and runs the scanner preflight once, however many sources it finds.
The Black Duck-shaped files match the transform
The SBOM export now writes _dependencies.csv, _dependencies_sources.csv and _upgrade_guidance.csv with the exact header line and cell conventions transformBlackDuckReports produces, and adds _vulnerability_details.csv (the transform's 23-column view of security.csv). A downstream reader processes a depinder folder and a transformed Black Duck folder the same way.
Headers and cell rules moved to one shared module, src/blackduck/columns.ts, imported by both commands.
Cell conventions in the shareable files: Match type is Direct / Transitive / Direct,Transitive; a zero per-severity count is blank while Total (every finding, the same count as libs.csv and the upgrade guidance) and Critical and High stay numeric; dates are \tYYYY-MM-DD; Version id is empty; VerifiedPathMethod is not-checked; files end with a newline.
1Component name and ProjectPathExists are gone; Version id and VerifiedPathMethod are in.
Newer Versions (semver) left the Black Duck-shaped files for the new depinder-only _component_versions.csv.
addCategoriesToBlackDuckReports joins on Component Version Origin Id when every Version id is empty and reads the repository from ProjectPath when no VerifiedPath was verified, so it works on an analyse SBOM subfolder.