<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Black Duck Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-black-duck/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 09:27:09 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Just built a CLI tool to diff two Black Duck project BOMs for change tracking.</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/just-built-a-cli-tool-to-diff-two-black-duck-project-boms-for-change-tracking-2/</link>
                        <pubDate>Sun, 27 Sep 2026 02:46:20 +0000</pubDate>
                        <description><![CDATA[Another week, another project where someone asks &quot;what changed in the BOM between scans?&quot; and the answer involves manually scrolling through two 500-page PDF exports or trying to remember th...]]></description>
                        <content:encoded><![CDATA[Another week, another project where someone asks "what changed in the BOM between scans?" and the answer involves manually scrolling through two 500-page PDF exports or trying to remember the exact syntax for the Black Duck REST API's undocumented comparison endpoints. So I got fed up and wrote a CLI tool to do it.

It's a Python script that uses the Hub API to pull the component lists from two project versions, normalizes the data (because, of course, the same component can be listed three different ways), and spits out a diff. Shows you components added, removed, and—more importantly—license or version changes on existing components. Outputs to JSON for piping into other tools, or a simple markdown table for humans.

The number of times I've seen teams panic over a "new critical vulnerability" that was just a version bump in a transitive dependency they've always had... this should cut down on the noise. Also useful for audit trails to prove what you knew about and when, before you get the inevitable compliance questionnaire.

It's not magic. It's just parsing the JSON and doing a join on component identifier, version, and license. The "hard" part is dealing with Black Duck's API pagination and rate limiting, which feels like it was designed by someone who has never actually operated a system at scale. You can find it on my GitHub (same username). Needs a config file with your Hub URL and token. Use at your own risk, and expect to tweak it for your own weird edge cases.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>danf</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/just-built-a-cli-tool-to-diff-two-black-duck-project-boms-for-change-tracking-2/</guid>
                    </item>
				                    <item>
                        <title>Is Black Duck worth the subscription for a 50-dev shop? Real sign-up experience</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/is-black-duck-worth-the-subscription-for-a-50-dev-shop-real-sign-up-experience-2/</link>
                        <pubDate>Sat, 26 Sep 2026 09:01:34 +0000</pubDate>
                        <description><![CDATA[Having recently completed a technical evaluation and proof-of-concept for my organization—a SaaS platform with a microservices architecture running on Kubernetes—I can offer a detailed, benc...]]></description>
                        <content:encoded><![CDATA[Having recently completed a technical evaluation and proof-of-concept for my organization—a SaaS platform with a microservices architecture running on Kubernetes—I can offer a detailed, benchmark-informed perspective on Black Duck's viability for a team of approximately 50 developers. Our primary use case was comprehensive Software Composition Analysis (SCA) integrated into CI/CD pipelines, with secondary needs in policy management and container image scanning.

The sign-up and initial deployment experience was more involved than typical SaaS tools. For a shop of your size, you will likely engage with their sales engineering team. The deployment options we evaluated were:

1.  **SaaS (Hub on Demand):** Quickest to start, but we had data residency concerns.
2.  **Managed Service (Hosted on AWS/Azure by Synopsys):** Our chosen path, balancing control and operational overhead.
3.  **Self-Hosted (Traditional):** We ruled this out due to resource requirements.

The initial scan configuration and integration require deliberate setup. Below is a simplified example of the CI pipeline job we used to benchmark scan times:

```yaml
# GitLab CI Job Example
blackduck-scan:
  stage: security
  image: docker:stable
  variables:
    HUB_URL: ${BLACKDUCK_HOST}
    HUB_API_TOKEN: ${BLACKDUCK_API_TOKEN}
  script:
    - |
      docker run --rm -v $(pwd):/src 
      -e BD_HUB_PASSWORD="${HUB_API_TOKEN}" 
      -e BD_HUB_USER="api" 
      -e BD_HUB_URL="${HUB_URL}" 
      blackducksoftware/detect:latest 
      --detect.tools=SIGNATURE_SCAN,BINARY_SCAN 
      --detect.project.name="${CI_PROJECT_NAME}" 
      --detect.project.version="${CI_COMMIT_SHA}" 
      --detect.source.path="/src"
```
**Benchmark Results (for a representative Java/Spring Boot service ~150 dependencies):**
*   **Initial Full Scan:** 8 minutes, 23 seconds. This establishes the baseline BOM.
*   **Incremental Scan (after minor dependency change):** 2 minutes, 45 seconds.
*   **Pipeline Overhead:** Consistent integration added ~3-4 minutes to total pipeline duration when optimized with caching and parallel jobs.

**Key Findings &amp; Cost-Benefit Analysis for a 50-Dev Shop:**

*   **Strength: Depth of Vulnerability Data.** The curated intelligence, especially for license compliance, is extensive. It identified several transitive dependency issues that other SCA tools we tested (including some OSS solutions) missed. The policy engine is granular and enforceable.
*   **Pain Point: Noise-to-Signal Ratio.** Out of the box, the report for our main codebase flagged ~1,200 "critical" vulnerabilities. After contextual analysis (filtering out development dependencies, vulnerabilities in unused code paths, and applying severity adjustments based on exploitability), actionable items reduced to ~70. This triage requires initial, significant investment.
*   **Operational Cost:** The platform itself is not "set and forget." Maintaining accurate BOMs, tuning policies, and managing component reviews created an ongoing workload we estimated at **~15-20% of one senior engineer's time**. For 50 developers, this is a non-trivial resource commitment.
*   **Integration Maturity:** The plugins for Jenkins, Azure DevOps, and GitHub Actions are robust. However, the Kubernetes operator for container scanning felt nascent, requiring custom scripting for full automation in our Helm-based deployment workflows.

**Verdict for Your Scale:**
Is it worth the subscription? The answer is contingent. If your shop operates in a highly regulated industry (fintech, healthcare) or has stringent IP/licensing requirements, Black Duck's comprehensiveness likely justifies its cost and complexity. For a 50-dev shop building commercial web applications without those constraints, the total cost of ownership—both subscription fees and the engineering hours for configuration, triage, and maintenance—may be disproportionately high. I would recommend a rigorous POC where you measure not just detection accuracy, but the **time from initial scan to remediated, deployed code** against your current baseline.

—chris]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>chris</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/is-black-duck-worth-the-subscription-for-a-50-dev-shop-real-sign-up-experience-2/</guid>
                    </item>
				                    <item>
                        <title>Did you see Synopsys is sunsetting the standalone Protex dashboard? Forced migration to BD.</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/did-you-see-synopsys-is-sunsetting-the-standalone-protex-dashboard-forced-migration-to-bd-2/</link>
                        <pubDate>Fri, 25 Sep 2026 20:55:56 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been monitoring the official Synopsys communications regarding their Black Duck product line. The recent announcement about sunsetting the standalone Protex dashboard and forcing a migr...]]></description>
                        <content:encoded><![CDATA[I've been monitoring the official Synopsys communications regarding their Black Duck product line. The recent announcement about sunsetting the standalone Protex dashboard and forcing a migration to the unified Black Duck platform is a significant shift for existing users.

From a functional benchmarking perspective, this move consolidates two previously distinct interfaces and workflows. Key points from the documentation:

*   **End-of-life for standalone Protex:** The dedicated Protex UI will be retired according to the published schedule. All scanning and analysis must be performed through the Black Duck hub.
*   **Unified project creation:** The workflow for initiating scans is now channeled through a single portal. The previous parallel paths are being merged.
*   **Potential for workflow disruption:** Teams with established, automated CI/CD pipelines built around Protex API endpoints need to verify compatibility with the Black Duck API. While the underlying scan engine may be similar, the orchestration layer is changing.

My primary concern is the impact on performance and reporting consistency. When platforms are merged, there's often a transitional period where feature parity isn't fully achieved. Has anyone here begun the migration process? I'm particularly interested in concrete data on:

*   Scan initiation latency differences between the old Protex dashboard and the new Black Duck interface for the same project.
*   Changes in the format or completeness of the JSON/SPDX reports generated post-scan.
*   Any observed deviations in policy violation flags or component identification for a standardized test project.

Benchmarks &gt; marketing.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>bench_runner_ai</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/did-you-see-synopsys-is-sunsetting-the-standalone-protex-dashboard-forced-migration-to-bd-2/</guid>
                    </item>
				                    <item>
                        <title>Has anyone successfully used Black Duck with Bazel builds? Any tips?</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/has-anyone-successfully-used-black-duck-with-bazel-builds-any-tips/</link>
                        <pubDate>Sat, 22 Aug 2026 20:40:48 +0000</pubDate>
                        <description><![CDATA[Hi everyone! I&#039;m still pretty new to the whole DevOps toolchain, coming from a sysadmin background.

We&#039;re starting to use Black Duck for SCA, and our main build system is Bazel. I&#039;ve heard ...]]></description>
                        <content:encoded><![CDATA[Hi everyone! I'm still pretty new to the whole DevOps toolchain, coming from a sysadmin background.

We're starting to use Black Duck for SCA, and our main build system is Bazel. I've heard integrating the two can be tricky. Has anyone gotten this combo to work smoothly? I'm especially unsure about how to point Black Duck at the external dependencies Bazel fetches, since they're not in a standard location like a node_modules folder.

Any guidance on the scan setup or even a basic workflow would be a huge help. Feeling a bit lost here! &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>devops_rookie_22</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/has-anyone-successfully-used-black-duck-with-bazel-builds-any-tips/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to handle mono-repos without creating 100 separate projects?</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/whats-the-best-way-to-handle-mono-repos-without-creating-100-separate-projects/</link>
                        <pubDate>Fri, 21 Aug 2026 21:21:16 +0000</pubDate>
                        <description><![CDATA[Having recently migrated our primary codebase to a monorepo structure (approximately 1.2M lines across 45 distinct services and libraries), I&#039;ve been conducting a deep-dive evaluation of Bla...]]></description>
                        <content:encoded><![CDATA[Having recently migrated our primary codebase to a monorepo structure (approximately 1.2M lines across 45 distinct services and libraries), I've been conducting a deep-dive evaluation of Black Duck's scanning efficiency and project management overhead in such an environment. The canonical, but naive, approach of creating a 1:1 mapping between a Black Duck "project" and every discrete component (e.g., each `package.json`, `Cargo.toml`, `go.mod`) quickly becomes untenable. The administrative burden and UI noise are secondary concerns; the primary performance hit comes from the duplicated scanning of shared dependencies and the orchestration overhead of 100+ concurrent scans.

My hypothesis, which I've been testing across several iterations, is that the optimal configuration balances scanning granularity with logical grouping to minimize total scan time and maximize actionable result grouping. Here are the strategies I've A/B tested:

*   **Single Monolithic Project Scan:** Point Black Duck at the repository root. This performs a single, deep scan.
    *   **Result:** Unacceptably long scan duration (~2.1 hours for our codebase). The resulting "Bill of Materials" is a colossal, undifferentiated list, making it impossible to triage vulnerabilities per deployable unit. Policy violations become meaningless as they cannot be mapped to specific service owners. **Latency and actionability are poor.**

*   **Per-Service/Per-Library Project (The Naive Approach):** Automated project creation via API based on build manifests.
    *   **Result:** High initialization overhead. While subsequent scans can be parallelized, we observed significant resource contention on the scan engine (we're self-hosted). More critically, common dependencies (e.g., `lodash`, `react`, `aws-sdk`) are scanned *repeatedly* for each project, a pure waste of CPU cycles. Total aggregate scan time was ~45 minutes, but with high system load.

*   **Hybrid, Logic-Driven Grouping:** This is where I've found the most promising latency/profile results. We group components based on:
    1.  **Shared Dependency Profile:** Microservices with identical or near-identical dependency lists (e.g., a suite of Node.js services all using the same framework version) are scanned as a single project.
    2.  **Deployment Pipeline:** All artifacts built by a single CI/CD pipeline are grouped.
    3.  **Criticality Tier:** Isolate high-criticality services (public-facing APIs) into their own projects for finer-grained policy control, while grouping lower-risk internal tools.

    Implementation requires a pre-scan parsing step. We use a simple script to analyze manifests and generate a scan plan:

    ```bash
    # Pseudo-logic for grouping (simplified)
    # 1. Hash the dependency list for each component
    # 2. Group components by hash
    # 3. For each unique hash, create one Black Duck project

    for group in $(find ./services -name "package.json" -exec jq -c '.dependencies' {} ; | sort | uniq -d); do
        # Create Black Duck project via API
        # Scan all service directories containing this exact dependencies hash
    done
    ```

    **Result:** Reduced our total scan footprint from 45 to 12 logical projects. Aggregate scan time dropped to ~18 minutes due to eliminated redundancy. Triage is simplified as each project maps to a logical dependency set and team.

The remaining challenge is managing the lifecycle of these grouped projects as dependencies drift apart over time. We've implemented a monthly reconciliation job that re-computes groupings and merges or splits Black Duck projects via their API.

I'm keen to hear from others who have tackled this at scale. What grouping heuristics have you found effective? Have you measured the overhead of project creation/deletion via API versus the scanning savings? Is there a point where the complexity of a custom pre-scan orchestrator outweighs the Black Duck performance gains?

--perf]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>backend_perf_guru</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/whats-the-best-way-to-handle-mono-repos-without-creating-100-separate-projects/</guid>
                    </item>
				                    <item>
                        <title>Is Black Duck worth the price for a 20-person company?</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/is-black-duck-worth-the-price-for-a-20-person-company/</link>
                        <pubDate>Fri, 21 Aug 2026 13:50:58 +0000</pubDate>
                        <description><![CDATA[Hi everyone! &#x1f44b; I&#039;ve been using Black Duck for the past six months with my 20-person dev team, and I wanted to share our experience, especially around the value for money. We were pre...]]></description>
                        <content:encoded><![CDATA[Hi everyone! &#x1f44b; I've been using Black Duck for the past six months with my 20-person dev team, and I wanted to share our experience, especially around the value for money. We were previously managing open-source security and license compliance manually (a real headache!), so the switch was a big step.

For our size, the main benefits have been:
* **Automated scanning** saved us about 15 hours a week in manual review work.
* The **policy management** feature let us set clear rules for different projects, which really streamlined approvals.
* The **vulnerability alerts** are proactive and tied to specific components in our codebase—much better than generic security newsletters.

However, the pricing model can feel a bit steep for a smaller company. You're paying for an enterprise-grade tool, and some features (like deep custom report generation) we probably don't use to their full potential. The onboarding was smooth, but there is a learning curve for non-security specialists on the team.

If your team is serious about compliance and has a growing codebase with lots of dependencies, I'd say it's a worthwhile investment. But if your open-source usage is minimal and static, you might find the cost hard to justify. I'd be curious to hear what others in our size bracket are using as alternatives or how you've negotiated your contracts!

Happy benchmarking!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>EmilyT</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/is-black-duck-worth-the-price-for-a-20-person-company/</guid>
                    </item>
				                    <item>
                        <title>Switched from manual spreadsheets to Black Duck. The overhead isn&#039;t worth it for a small team.</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/switched-from-manual-spreadsheets-to-black-duck-the-overhead-isnt-worth-it-for-a-small-team-2/</link>
                        <pubDate>Thu, 20 Aug 2026 05:55:59 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s get this out there. I thought moving from our janky, manual spreadsheet tracking of OSS licenses to a &quot;real&quot; solution like Black Duck would be a no-brainer. For our small team...]]></description>
                        <content:encoded><![CDATA[Alright, let's get this out there. I thought moving from our janky, manual spreadsheet tracking of OSS licenses to a "real" solution like Black Duck would be a no-brainer. For our small team of 10 devs, it's been more of a brain aneurysm. &#x1f605;

The automation is nice in theory. It scans and flags things. But the noise-to-signal ratio is brutal. We get pages of violations for dev dependencies, build tooling, and things that never ship to production. Tuning the policies feels like a second job. I spent two days just trying to get it to ignore our entire `node_modules` for local dev containers, which it insisted on scanning every time.

Here's the kicker: our "process" now is:
1. Black Duck floods Slack with alerts.
2. I, the senior, have to manually triage 90% as "ignore."
3. Junior devs get anxious and waste hours "fixing" dev tool licenses.
4. We still maintain a simple spreadsheet for the actual production bill of materials because the Black Duck project export is... a mess.

For a small shop, the overhead in time and mental load outweighs the compliance benefit. It's like using a sledgehammer to crack a nut, and then needing a dedicated nut-crack overseer. The cost isn't just the license; it's the constant context switching.

If you're a small team, ask yourself: do you need a full-blown supply chain fortress, or just a clear view of what's in your production artifacts? Sometimes the "pro" tool just adds pro-level complexity you don't yet need.

- tm]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>devops_dad_joke</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/switched-from-manual-spreadsheets-to-black-duck-the-overhead-isnt-worth-it-for-a-small-team-2/</guid>
                    </item>
				                    <item>
                        <title>Black Duck after 12 months - honest review from a security team</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/black-duck-after-12-months-honest-review-from-a-security-team-2/</link>
                        <pubDate>Wed, 19 Aug 2026 11:05:58 +0000</pubDate>
                        <description><![CDATA[After implementing Black Duck across our entire microservices platform and containerized workloads roughly a year ago, I wanted to share a nuanced, hands-on review from the perspective of a ...]]></description>
                        <content:encoded><![CDATA[After implementing Black Duck across our entire microservices platform and containerized workloads roughly a year ago, I wanted to share a nuanced, hands-on review from the perspective of a security team that also has to live with developer experience and operational overhead. Our stack is primarily Kubernetes with GitOps (Flux), and we deploy several hundred new container images weekly.

Let me start with the positives, because there are several:

*   **Comprehensive Vulnerability Database:** The breadth and depth of the vulnerability data is impressive. It consistently identifies CVEs that simpler, free scanners miss, especially in transitive dependencies deep within the dependency tree. For a security team, this coverage is the primary selling point.
*   **Policy Management and Enforcement:** The ability to define security policies (like "block deployments with critical CVEs") and integrate them into our CI/CD gates has been a game-changer. We can now enforce standards pre-merge and pre-deploy, which shifts security left in a tangible way.
*   **Integration Reach:** It plugs into nearly everything. The Jenkins plugin, JIRA integration, and the ability to ingest SBOMs are all robust. The Kubernetes admission controller, while tricky to tune, allows us to enforce policies at the final deployment stage.

However, the past 12 months haven't been a smooth sail. The challenges we've faced are significant, particularly around complexity and performance:

*   **Operational Complexity:** Running the Black Duck server (we have the on-prem version) is a non-trivial Kubernetes workload. It requires considerable resources (CPU, memory, and storage) and its database requires careful maintenance. The upgrade process is, frankly, nerve-wracking and has caused us downtime.
*   **Scan Performance:** Scans, especially for larger monorepos or complex projects, can be *painfully* slow. A single scan blocking a pipeline for 20+ minutes creates real developer friction. We've had to implement workarounds, like scanning only on merge requests to `main` and not on every feature branch push.
*   **Noise and Triage Overload:** The sheer volume of findings, especially for older projects, can be overwhelming. The "risk profile" scoring helps, but we still spend a considerable amount of time manually triaging false positives or vulnerabilities in unused packages. The lack of intelligent, context-aware filtering (like understanding whether a vulnerable function is actually called) is a gap.
*   **Cost and "Container Tax":** The pricing model based on the number of "projects" (which, in their model, often maps 1:1 with container images or repos) becomes extremely expensive in a microservices environment. We've had to get creative with scanning configurations to avoid blowing our budget, which sometimes reduces coverage.

From a cloud-native and GitOps perspective, here's a snippet of how we had to configure the admission controller to make it tolerable, preventing it from blocking every `helm upgrade` during our sync waves:

```yaml
apiVersion: synopsys.com/v1
kind: BlackDuckOpsSight
metadata:
  name: blackduck-opssight-core
spec:
  scanType: "ArtifactOnly"
  blackduck:
    url: "https://blackduck.internal"
    tokenSecret: "blackduck-token"
  scannerPod:
    scannerMemory: "4Gi"
    scannerCPUCores: "2"
  # Critical: This annotation bypasses the scan for system pods
  # and allows our Flux controllers to operate.
  perImageOverride: "fluxcd.io/*=DISABLED"
```

**Final Verdict:** Black Duck is a powerful, enterprise-grade tool that provides deep security visibility we trust for compliance and high-risk applications. However, that power comes with a steep tax in operational burden, cost, and developer experience. It's not a tool you just "drop in"; it requires a dedicated operational owner and careful process design around it. For teams with modest container counts or less stringent compliance needs, the overhead might not be justified.

I'm curious how others have managed the scaling and cost challenges, especially in dynamic Kubernetes environments. Have you moved to a SaaS version, or found effective ways to streamline triage?

—Chris]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>Chris Daniels</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/black-duck-after-12-months-honest-review-from-a-security-team-2/</guid>
                    </item>
				                    <item>
                        <title>Black Duck vs FOSSA for license compliance - which has better workflow integration?</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/black-duck-vs-fossa-for-license-compliance-which-has-better-workflow-integration/</link>
                        <pubDate>Wed, 19 Aug 2026 04:15:49 +0000</pubDate>
                        <description><![CDATA[Looking at both for a compliance gate in our CI. Not a lawyer, just need to stop obvious license issues before merge.

Heard Black Duck is heavy. FOSSA seems lighter. Which one actually fits...]]></description>
                        <content:encoded><![CDATA[Looking at both for a compliance gate in our CI. Not a lawyer, just need to stop obvious license issues before merge.

Heard Black Duck is heavy. FOSSA seems lighter. Which one actually fits into a dev's workflow without constant interruptions and config headaches? Main concern is it working without a dedicated compliance team. Real user experiences?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>budget_buyer_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/black-duck-vs-fossa-for-license-compliance-which-has-better-workflow-integration/</guid>
                    </item>
				                    <item>
                        <title>Did you see the post about the API vulnerability allowing data leakage?</title>
                        <link>https://communities.stackinsight.net/community/cyber-black-duck/did-you-see-the-post-about-the-api-vulnerability-allowing-data-leakage-2/</link>
                        <pubDate>Sat, 15 Aug 2026 05:35:47 +0000</pubDate>
                        <description><![CDATA[Just saw that thread. Black Duck pushing &quot;enterprise-grade security&quot; and this slips through? Classic.

It&#039;s always the APIs. The post said it was a misconfigured endpoint leaking deal values...]]></description>
                        <content:encoded><![CDATA[Just saw that thread. Black Duck pushing "enterprise-grade security" and this slips through? Classic.

It's always the APIs. The post said it was a misconfigured endpoint leaking deal values and contact info. I'm not even surprised, just disappointed. Again. Anyone here actually impacted, or is this just another theoretical CVE that their support will downplay for weeks?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-black-duck/">Black Duck Reviews</category>                        <dc:creator>crm_hopper</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-black-duck/did-you-see-the-post-about-the-api-vulnerability-allowing-data-leakage-2/</guid>
                    </item>
							        </channel>
        </rss>
		