update docs to describe correlated server property#1722
update docs to describe correlated server property#1722
Conversation
| } | ||
| ```` | ||
|
|
||
| ## Black Duck Server Properties |
There was a problem hiding this comment.
I would suggest we insert "SCA" here and in line 128 for clarity.
| * Support for pnpm now extends to 10.32.1. | ||
| * npm detectors now allow for aliases to be used when specifying dependencies in the package.json file. | ||
| * Ivy CLI Detector, leveraging the `ivy:dependencytree` Ant task to extract direct and transitive dependencies for Ant + Ivy projects. For further information, see [Ivy (Ant) support](packagemgrs/ivy.md). | ||
| * If enabled, [detect_product_short] will now pull certain configured properties from [bd_product_long]. In [bd_product_long] version 2026.4 this will start with the `detect.blackduck.correlated.scanning.enabled` property. |
There was a problem hiding this comment.
What do we mean by enabled?
As of BDSCA 2026.4 do we mean that if we set detect.blackduck.correlated.scanning.enabled=true that other properties configured in BDSCA will be pulled in for use by Detect?
There was a problem hiding this comment.
enabled just means that correlated scanning will be used. This server property mimics the existing local one Detect has had for awhile.
The background here is that BDSCA has a new endpoint that Detect can check to see if there are any server level properties that an admin has set. Users can override these locally using existing Detect properties. The only server level property as of 2026.4 will be the detect.blackduck.correlated.scanning.enabled one but others might be added in the future.
There was a problem hiding this comment.
Thank you.
In that case, a tweak suggestion. (Which itself may require a tweak or two)
- As of [bd_product_long] version 2026.4, setting the [detect_product_short]
detect.blackduck.correlated.scanning.enabledproperty to "True" will cause [detect_product_short] to retrieve relevant server properties from [bd_product_long].
There was a problem hiding this comment.
Ah, getting closer I think. What will happen is this:
- If a user has specified the property, we will simply use it (true or false). It's an override/the most powerful option.
- Detect 11.5 and later will reach out to Black Duck if the server is level 2026.4 to determine if an admin has turned on correlation. If it is true then Detect will turn on correlation.
- If no one mentions anything about correlation then the default of false will take over.
Note that we'll likely use this mechanism in the future to pull any BD specified properties but right now when that middle bullet takes place, the only possible thing Detect can learn about is this detect.blackduck.correlated.scanning.enabled property. The property isn't special in anyway besides being the first property that has been implemented for this new exchange.
There was a problem hiding this comment.
Oddly difficult to succinctly release note. : )
Is it that I am missing a new property that "enables" the overall functionality or is it that if a property supports the functionality and is set to true/enabled, the feature is considered enabled?
Also wondering; if the middle bullet takes effect as of Detect 11.5, what would get pulled from BD SCA as of 11.4?
Thank you.
There was a problem hiding this comment.
In 11.4 and later Detect will always call this endpoint for BDs 2026.4 or later, in online mode at least, to see if BD has any properties Detect should consider. So the general check for properties is always enabled if you have the versions I mentioned or later.
Now talking about what Detect might learn about, as of the writing of this comment there is only one property that BD has, which is the correlated one we have been talking about. So Detect will get that single property and check if it is enabled. If it is then it will see what scans correlated is enabled for (which is package manager and/or signature scans).
And ugh, sorry to add to the confusion with my incorrect mention of 11.5. I meant to say 11.4, everything in this conversation is relevant for 11.4.
There was a problem hiding this comment.
Ah ok, how about this revised suggestion?
- When [detect_product_short] is integrated with [bd_product_long] version 2026.4 or later, relevant [bd_product_short] server configuration details will be retrieved for use by [detect_product_short]. With this release of [detect_product_short], if the
detect.blackduck.correlated.scanning.enabledproperty is set to "True", relevant server properties will be retrieved.- In future releases the retrieval of additional [bd_product_short] server properties will be supported.
There was a problem hiding this comment.
I think we are good with the starter statement of: "When [detect_product_short] is integrated with [bd_product_long] version 2026.4 or later, relevant [bd_product_short] server configuration details will be retrieved for use by [detect_product_short]." and the ending statement of: "In future releases the retrieval of additional [bd_product_short] server properties will be supported."
The middle statement I think is a bit confusing. The user does not need to set any Detect property for this to all happen. They can, and if they do we will use that before the server version.
What if we say something like: "With this release of [detect_product_short], the [bd_product_short] server administrator can choose to set the detect.blackduck.correlated.scanning.enabled property, which will be retrieved and used if the user has not specified this property locally."
Adds descriptions of the new server configuration properties to the release notes and to the status.json