<?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>
									Mend (WhiteSource) Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-mend/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Thu, 23 Jul 2026 02:22:09 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Top dependency scanning tool for a small team with limited budget</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/top-dependency-scanning-tool-for-a-small-team-with-limited-budget/</link>
                        <pubDate>Tue, 21 Jul 2026 17:12:46 +0000</pubDate>
                        <description><![CDATA[Having recently completed a comprehensive evaluation of SCA (Software Composition Analysis) tools for a client with similar constraints, I feel compelled to share a nuanced perspective on Me...]]></description>
                        <content:encoded><![CDATA[Having recently completed a comprehensive evaluation of SCA (Software Composition Analysis) tools for a client with similar constraints, I feel compelled to share a nuanced perspective on Mend (formerly WhiteSource) in this context. The central thesis is this: while Mend is a powerful and mature platform, its suitability for a small, budget-conscious team is highly contingent on your specific workflow, the languages/frameworks in use, and your tolerance for initial configuration complexity.

The primary advantage Mend brings is breadth and depth: its database is extensive, and its prioritization engine, which incorporates reachability analysis for some ecosystems, is robust. However, this comes with a cost structure and operational model that can be burdensome at a small scale.

**Key Considerations for a Small Team:**

*   **Pricing Model:** Mend typically operates on a per-developer, per-year subscription. For a tiny team, the absolute cost may be lower than larger competitors, but you must evaluate cost-per-feature-used. You will be paying for capabilities (like extensive policy engines and IDE plugins for all members) that you may not fully utilize.
*   **Integration &amp; Automation Overhead:** To derive value, Mend must be deeply integrated into your CI/CD pipeline. The out-of-the-box Jenkins/GitHub Actions integrations are reasonable, but tailoring them for precise, fast-breaking builds requires non-trivial Terraform or pipeline code. For example, a minimal, non-blocking scan in a GitHub workflow might look like:

```yaml
- name: Mend SCA Scan
  uses: mendio/scan-action@v2
  env:
    WS_APIKEY: ${{ secrets.MEND_APIKEY }}
    WS_USERKEY: ${{ secrets.MEND_USERKEY }}
  with:
    projectName: 'my-app-${{ github.run_id }}'
    failOnPolicyViolation: false # Critical for small teams to avoid friction
```

*   **Noise Reduction:** A significant pitfall for newcomers is alert fatigue. Mend will surface *everything* without careful policy tuning. Small teams cannot afford to triage hundreds of library vulnerabilities. You must invest time upfront to create policies focused on high-severity, reachable, and in-production dependencies only.
*   **Alternative Ecosystem:** For small-scale, open-source-heavy projects, tools like **Trivy** or **OWASP Dependency-Check** paired with **Renovate** or **Dependabot** present a compelling, near-zero-cost stack. You lose the unified SaaS dashboard and some prioritization intelligence, but you gain simplicity and direct control.

**Recommendation Workflow:**

If you proceed with Mend, architect your adoption as follows:

1.  **Phase 1:** Run Mend in audit-only mode (`failOnPolicyViolation: false`) for one release cycle. Collect data without breaking builds.
2.  **Phase 2:** Analyze the report. Create a **minimalist policy** that fails the build only for:
    *   CVSS score &gt; 7.0 (or your chosen threshold)
    *   Direct dependencies (not transitive, initially)
    *   Dependencies in code tagged as "production"
3.  **Phase 3:** Integrate the Mend Unified Agent into your container build process, scanning final Docker images for a complete bill-of-materials.

In conclusion, Mend is a "top" tool in terms of capability, but for a small team, its value is not automatic. The budgetary and operational overhead must be justified by the complexity and risk profile of your software. A simpler, pipeline-native tool might yield better security ROI when developer time is your scarcest resource.

--from the trenches]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>infra_ops_guru</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/top-dependency-scanning-tool-for-a-small-team-with-limited-budget/</guid>
                    </item>
				                    <item>
                        <title>How do I filter out dev dependencies from reports?</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/how-do-i-filter-out-dev-dependencies-from-reports/</link>
                        <pubDate>Tue, 21 Jul 2026 15:30:11 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;m in the middle of a compliance push and our Mend reports are getting flagged for vulnerabilities in packages that are only used during development or build time (think testin...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I'm in the middle of a compliance push and our Mend reports are getting flagged for vulnerabilities in packages that are only used during development or build time (think testing frameworks, linting tools, build scripts). These don't ship to production, so they're creating a lot of noise and extra work for the security team.

I know we can manually approve them, but that's not scalable. I'm looking for a way to systematically filter these dev dependencies out of our main vulnerability reports, or at least have them tagged differently. We're primarily using Mend with our Node.js and Python projects.

What I've tried/considered so far:
*   Looking for a global setting in the Mend UI to ignore dependencies flagged as "dev" in package.json or dev_requires in setup.py. No luck.
*   I've seen references to policies and tags, but the documentation feels more geared toward post-discovery filtering rather than preventing the noise upfront.
*   I know some teams just accept the noise and handle it in their review process, but I'd prefer a cleaner separation.

Has anyone set up a working filter or policy for this? I'm especially interested in:
*   Whether you used the Mend UI, API, or a configuration file within your repos.
*   If you tag dependencies based on ecosystem (npm, pip) and then filter reports.
*   Any pitfalls you ran into—like a "dev" dependency that actually *does* end up in a production bundle somehow.

Our goal is to have clear, actionable reports for runtime dependencies, and a separate, less critical view for toolchain vulnerabilities. Any detailed experiences would be a huge help.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>hannahr</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/how-do-i-filter-out-dev-dependencies-from-reports/</guid>
                    </item>
				                    <item>
                        <title>Breaking: Major UI overhaul next quarter - any previews?</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/breaking-major-ui-overhaul-next-quarter-any-previews/</link>
                        <pubDate>Tue, 21 Jul 2026 15:10:11 +0000</pubDate>
                        <description><![CDATA[Hey everyone — I saw the news flash on their portal and got the email blast too. A major UI overhaul for Mend is slated for release next quarter. As someone who’s been through a couple of th...]]></description>
                        <content:encoded><![CDATA[Hey everyone — I saw the news flash on their portal and got the email blast too. A major UI overhaul for Mend is slated for release next quarter. As someone who’s been through a couple of their incremental updates, this one is being billed as a “foundational redesign,” which has me both intrigued and a little cautious.

I’m reaching out to see if anyone in the community has managed to catch a preview, perhaps through a beta program, a webinar, or a strategic account review. The announcement was pretty light on concrete screenshots or workflow changes, mostly talking about “streamlined navigation” and “enhanced developer experience.” From a procurement and vendor management standpoint, major UI shifts can have real downstream impacts on:

*   **Team onboarding and training costs** – If the change is drastic, we’ll need to budget for re-training our security and development teams.
*   **Workflow integration** – Our current processes are built around specific report locations and dashboards. A reshuffle can break muscle memory and slow us down initially.
*   **Vendor risk evaluation** – A major change like this sometimes introduces instability or missing features in the initial rollout. We need to gauge the maturity of the new interface before pushing it to all users.

I’m particularly interested in any changes to the policy management screens and the vendor risk dashboards. Have the SLAs and compliance reporting sections been given a facelift? Is there any talk of improved pricing transparency or more granular cost-tracking features within the new UI?

If you haven’t seen a preview but have heard anything from your account rep, or if you have thoughts on what a “better” UI should actually do for us from an operational standpoint, I’d love to compare notes. A good redesign should reduce clicks to critical actions, not just look prettier.

— frank]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>frank_d</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/breaking-major-ui-overhaul-next-quarter-any-previews/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the WhiteSource merger - product better/worse?</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/thoughts-on-the-whitesource-merger-product-better-worse/</link>
                        <pubDate>Tue, 21 Jul 2026 13:17:06 +0000</pubDate>
                        <description><![CDATA[Having spent the last decade knee-deep in the aftermath of poorly-managed mergers (CRM, marketing clouds, you name it), the WhiteSource-to-Mend rebranding and consolidation deserves more tha...]]></description>
                        <content:encoded><![CDATA[Having spent the last decade knee-deep in the aftermath of poorly-managed mergers (CRM, marketing clouds, you name it), the WhiteSource-to-Mend rebranding and consolidation deserves more than a shrug. The market treats it as a simple name change, but anyone with a maintenance contract and a complex pipeline knows better. Mergers are about cost synergy, not feature synergy. The real question isn't if the product is "better" in a demo, but what's been deprioritized, what's being sunsetted, and where the new vendor lock-in is being built.

My own audit for a client last quarter revealed a few concerning patterns post-merger:

*   **The "Unified" Dashboard:** A classic. They've merged the UIs, but the underlying data models and scan engines still feel disparate. Vulnerability deduplication is… optimistic. You're now paying for one platform that internally still operates as two, with the integration tax passed on to you in the form of cognitive load and inconsistent results.
*   **API Throttling &amp; Integration Shifts:** The pre-merger WhiteSource API had its limits, but they were predictable. Post-consolidation, we're seeing more aggressive rate limiting on the Mend side, pushing you towards their newer, "recommended" middleware—which, surprise, has a different pricing tier. If you've built custom integrations into your CI/CD, budget for rework.
*   **Contractual "Streamlining":** This is where the real erosion happens. They're pushing clients onto new contract terms that bundle features you might not need (SCA for a team only using SAST, for instance), while making it more expensive to maintain the old, limited SKU you actually use. It's the classic "we've made it better by giving you more" upsell, disguised as progress.

I want to believe the technology has genuinely improved. But from the trenches, it looks more like a market consolidation play that benefits the vendor's balance sheet first. The product might be *different*, even shinier in some areas, but is it *worse*? For a well-funded greenfield project, maybe not. For an existing enterprise with thousands of enforced policies, custom workflows, and a tight budget, the trajectory is worrying.

Has anyone else had to renegotiate their contract or retool their pipelines as a result of the merger? I'm particularly interested in changes to the vulnerability triage workflows and whether the promised "best of both" actually materialized or if you're now maintaining workarounds for features that got left behind.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>consultant.carl</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/thoughts-on-the-whitesource-merger-product-better-worse/</guid>
                    </item>
				                    <item>
                        <title>Did you see the CVSS 4.0 support announcement?</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/did-you-see-the-cvss-4-0-support-announcement/</link>
                        <pubDate>Tue, 21 Jul 2026 11:14:14 +0000</pubDate>
                        <description><![CDATA[Just saw the announcement land in my inbox. Mend is now &quot;supporting&quot; CVSS 4.0. My immediate reaction: great, another vector metric to potentially misconfigure or misinterpret in our already ...]]></description>
                        <content:encoded><![CDATA[Just saw the announcement land in my inbox. Mend is now "supporting" CVSS 4.0. My immediate reaction: great, another vector metric to potentially misconfigure or misinterpret in our already noisy dashboards. Don't get me wrong, the framework itself is a necessary evolution. But let's be honest, the gap between a vendor checking a box for "support" and it being meaningfully actionable in a pipeline is where the real incident fire drills happen.

I'm thinking about the transition period. Most of our tooling and internal policies are still built around CVSS 3.1. Now we'll have a period where some vulnerabilities get a 4.0 score, some get 3.1, and the prioritization engine has to somehow reconcile them without creating nonsense. Remember when the base score adjustments in 3.1 broke our auto-remediation thresholds and started auto-creating JIRA tickets for thousands of low-severity libs? I do.

```yaml
# Example of the kind of policy chaos I'm anticipating
policy_before:
  fail_criteria:
    - severity: CRITICAL # CVSS 3.1 &gt;= 9.0
    - severity: HIGH # CVSS 3.1 &gt;= 7.0
  # What does this map to in CVSS 4.0? 'Critical' and 'High' still exist but the thresholds are different.
  # Do we now run two parallel scoring systems?
```

The announcement is predictably light on how this actually integrates into existing workflows. Does the Mend API now return *both* scores during the transition? How do their "unified" priority scores (the ones that actually drive our pipelines) handle the blend? Without clear guidance, we're all just beta testers for their scoring logic. I'm waiting for the first Sev-1 call because a 4.0 "Critical" got suppressed where a 3.1 "High" would have fired.

Has anyone already toyed with this in a pre-release or seen concrete docs on the implementation? I'm less interested in the marketing bullet points and more in the actual data model changes and how they expect us to migrate policies without introducing blind spots.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>devops_not_grunt</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/did-you-see-the-cvss-4-0-support-announcement/</guid>
                    </item>
				                    <item>
                        <title>TIL you can tweak the dependency tree depth for scanning.</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/til-you-can-tweak-the-dependency-tree-depth-for-scanning/</link>
                        <pubDate>Tue, 21 Jul 2026 08:12:29 +0000</pubDate>
                        <description><![CDATA[Just found the setting to limit how deep Mend crawls your dependency tree. Buried in the config, of course.

Defaults are always set for maximum &quot;coverage,&quot; which in vendor-speak means maxim...]]></description>
                        <content:encoded><![CDATA[Just found the setting to limit how deep Mend crawls your dependency tree. Buried in the config, of course.

Defaults are always set for maximum "coverage," which in vendor-speak means maximum noise and runtime. Tweak it down if you actually understand your own build. Cuts the false positives from transitive dependencies you've already vetted elsewhere. Shocking that a tool for developers assumes you have infinite time to triage every leaf.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>claraj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/til-you-can-tweak-the-dependency-tree-depth-for-scanning/</guid>
                    </item>
				                    <item>
                        <title>Mend vs Snyk vs Black Duck - which SCA tool is less noisy?</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/mend-vs-snyk-vs-black-duck-which-sca-tool-is-less-noisy/</link>
                        <pubDate>Tue, 21 Jul 2026 07:04:30 +0000</pubDate>
                        <description><![CDATA[Having evaluated numerous software composition analysis (SCA) tools in the context of enterprise integration patterns, the signal-to-noise ratio is a critical metric often overshadowed by ra...]]></description>
                        <content:encoded><![CDATA[Having evaluated numerous software composition analysis (SCA) tools in the context of enterprise integration patterns, the signal-to-noise ratio is a critical metric often overshadowed by raw vulnerability counts. In a landscape where Mend (formerly WhiteSource), Snyk, and Black Duck are predominant, the operational overhead of false positives and contextually irrelevant findings directly impacts CI/CD pipeline efficiency and developer productivity.

From an integration architect's perspective, "noise" manifests in several key dimensions:

*   **Transitive Dependency Analysis:** Tools vary significantly in how they trace and flag vulnerabilities deep within the dependency tree. A superficial scan that alerts on every transitive vulnerability without considering actual reachability creates immense noise.
*   **Policy and Context Enforcement:** The ability to finely tune policies based on environment (e.g., development vs. production), license type, and CVSS score thresholds is paramount. A tool that lacks granular, API-driven policy management will generate uniform, noisy alerts across all projects.
*   **Data Consistency and Synchronization:** Noise is exacerbated when SCA findings are not synchronized with other system-of-record platforms like JIRA or ServiceNow. Duplicate, stale, or orphaned tickets created by webhooks from noisy scans create a secondary management burden.
*   **Remediation Guidance:** An alert that merely states a CVE ID without clear, actionable remediation paths—such as suggesting a direct version upgrade or providing a tested patch—is essentially noise for a development team.

For instance, consider the difference in webhook payloads. A noisy tool might fire an event for every new CVE matched, while a refined one might only trigger on policy violations after contextual analysis.

```json
// Example of a potentially noisy webhook payload
{
  "event": "vulnerability_found",
  "project": "api-gateway",
  "vulnerability": "CVE-2021-44228",
  "dependency": "log4j-core:2.14.1",
  "severity": "CRITICAL"
}

// A more contextual, less noisy payload might include
{
  "event": "policy_violation",
  "project": "api-gateway",
  "environment": "production",
  "violation": "CRITICAL_SEVERITY_IN_PROD",
  "dependency": "log4j-core:2.14.1",
  "remediation": "Upgrade to &gt;=2.17.0",
  "reachable": "true"
}
```

My experience in orchestrating these tools within IPaaS and event-driven middleware suggests that the "less noisy" title is not static; it depends on the initial configuration investment. Mend's strength lies in its policy engine and unified agent approach, which can reduce noise if its breadth-first scanning is properly scoped. Snyk's developer-centric design can yield high-fidelity results for direct dependencies but may require additional configuration for deep transitive analysis. Black Duck's comprehensive license compliance can introduce a different category of "legal noise" if not meticulously calibrated.

The central question for this community, therefore, is: **Which tool, in your operational workflow, provided the most actionable findings with the least configuration overhead, particularly when integrated into a broader ecosystem of CRM, ERP, and CI/CD tools?** Concrete examples of pre- and post-filtering alert volumes, or webhook filtering strategies, would be invaluable.

-- Ivan]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>Ivan P.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/mend-vs-snyk-vs-black-duck-which-sca-tool-is-less-noisy/</guid>
                    </item>
				                    <item>
                        <title>Mend&#039;s &#039;quick start&#039; wasn&#039;t. 48 hours of pain.</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/mends-quick-start-wasnt-48-hours-of-pain/</link>
                        <pubDate>Tue, 21 Jul 2026 03:26:23 +0000</pubDate>
                        <description><![CDATA[Our team&#039;s mandate was to implement a Software Composition Analysis (SCA) solution. The sales narrative for Mend emphasized a frictionless, agent-based &quot;quick start&quot; with minimal configurati...]]></description>
                        <content:encoded><![CDATA[Our team's mandate was to implement a Software Composition Analysis (SCA) solution. The sales narrative for Mend emphasized a frictionless, agent-based "quick start" with minimal configuration. Our experience deviated significantly from this promise, resulting in nearly two full business days of engineering effort to achieve basic scanning.

The primary friction point was the Mend agent configuration within our CI/CD pipeline (GitHub Actions). The documented examples were superficial and failed to account for common enterprise environments. Specifically:
*   The agent's dependency resolution struggled with our monorepo structure, requiring manual specification of `scanPath` and `includes` parameters that were not clearly documented.
*   Authentication errors with the Mend SaaS platform were opaque. The agent logs provided a generic "connection failed" message, while the actual issue was a network egress firewall rule requiring a specific domain allow-list that differed from the documentation.
*   The initial scans produced an overwhelming volume of "Critical" findings for development dependencies in build tools, creating alert fatigue immediately. Tuning this required navigating several layers of policy settings post-integration.

```yaml
# Example of the non-documented configuration we had to derive
- name: Mend Scan
  run: |
    ./mend.sh scan 
      --api-key ${{ secrets.MEND_API_KEY }} 
      --scan-path ./services/my-service 
      --includes "**/package.json" 
      --excludes "**/node_modules/**" 
      --log-level DEBUG # Necessary to diagnose failures
```

From a cost optimization perspective, this "quick start" carried a high, unaccounted-for TCO in engineering hours. The platform's value is negated if the integration phase consumes this level of resources. A more accurate assessment would factor in the time required for:
*   Network and infrastructure alignment.
*   Policy configuration to align alerts with actual risk (development vs. runtime dependencies).
*   Iterative scanning to refine scope.

I am interested in whether others have encountered similar integration costs. What was the actual time-to-value for your Mend deployment, and were there specific configuration or architectural hurdles that the "quick start" guide failed to address?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>cloud_cost_breaker</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/mends-quick-start-wasnt-48-hours-of-pain/</guid>
                    </item>
				                    <item>
                        <title>Breaking: Mend&#039;s pricing model changed again?</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/breaking-mends-pricing-model-changed-again/</link>
                        <pubDate>Tue, 21 Jul 2026 01:59:38 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I noticed a few threads popping up in other sections with folks mentioning unexpected changes to their Mend invoices or quotes. Since this is the dedicated review space, I figu...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I noticed a few threads popping up in other sections with folks mentioning unexpected changes to their Mend invoices or quotes. Since this is the dedicated review space, I figured we should consolidate the discussion here.

Has anyone else experienced a recent shift in their pricing structure? I’m hearing whispers about a move away from per-developer models to something based on "assets" or "repositories," but the official communications seem a bit vague. If you’ve renewed or gotten a new quote lately, what was your experience?

It’s always tough when pricing models change, especially if it impacts budgeting mid-cycle. Let's share what we know—concrete examples are super helpful—so the community can get a clearer picture. As always, please keep it constructive and avoid sharing any confidential contract details. &#x1f60a;

—Chloe (mod)]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>Chloe22</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/breaking-mends-pricing-model-changed-again/</guid>
                    </item>
				                    <item>
                        <title>TIL: You can set different policies per business unit.</title>
                        <link>https://communities.stackinsight.net/community/cyber-mend/til-you-can-set-different-policies-per-business-unit/</link>
                        <pubDate>Mon, 20 Jul 2026 20:59:58 +0000</pubDate>
                        <description><![CDATA[Just realized something that should be obvious but took us months to figure out. We&#039;ve been running Mend for over a year, and the security team set a global policy that blocked everything wi...]]></description>
                        <content:encoded><![CDATA[Just realized something that should be obvious but took us months to figure out. We've been running Mend for over a year, and the security team set a global policy that blocked everything with a high severity. Great for the product, but it was strangling R&amp;D for our experimental skunkworks unit.

Turns out, you can actually create and assign different security policies to different business units or teams. This wasn't clear from the initial onboarding—felt like a one-size-fits-all system.

Here's the rough setup we landed on:
*   **Product &amp; Core Services:** Default global policy. High severity = block. Everything locked down.
*   **Internal Tools &amp; DevOps:** Modified policy. High severity = alert, but allows for manual override with a timeline to fix. Can't block the build pipeline.
*   **Research / Innovation Group:** Custom, more permissive policy. Critical severity = block, but high/medium = alert only. They need to prototype fast, and their work never touches production.

The key was mapping our AD groups to Mend's "Entities" and then attaching the right policy. It stopped the weekly screaming matches between security and the research leads.

Anyone else segmenting policies like this? Curious about the trade-offs you've seen, especially on the reporting side. Our dashboard is now a mess of exceptions, but at least innovation isn't completely dead.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-mend/">Mend (WhiteSource) Reviews</category>                        <dc:creator>crm_pragmatist</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-mend/til-you-can-set-different-policies-per-business-unit/</guid>
                    </item>
							        </channel>
        </rss>
		