Mend Platform Rollout Overview
Overview
This documentation series will help you with rolling out Mend, providing guidance to get you scanning your first few repositories quickly.
There are three main decisions to make regarding a Mend Rollout: Scan Strategy, Access Control and Results Consumption. Each decision will work together to help you make choices for the others. This document will provide a high level overview of each decision and their various pros/cons to help make informed decisions around your Mend Rollout.
Scan Strategy
Scan Strategy is the first and most important decision. Your scan strategy will dictate the Organization Structure which in turn decides Access Control, Developer Results Consumption, & how Renovate is deployed.
There are two options for scan strategy when implementing Mend:
Repository integration
Pipeline
These methods are not mutually exclusive. It is possible to run both pipeline and repository in parallel but when starting out with Mend it is important to focus on one method to get a handle on your organization structure, Renovate and Results consumption.
IDE is not listed as a scan strategy as this is not a scalable or enforceable scan method. Mend has no way to monitor IDE usage by developers, the results are not uploaded to the Mend UI, and each developer will need to obtain the own user key for the IDE install.
If you wish for Developers to be able to scan locally alongside either Pipeline or Repo integration to get results in front of developers faster, we recommend Integrating the Mend CLI into your IDE.
Repository
The repo integration supports the “Shift Left” approach by scanning earlier in the development process. It provides the full Mend experience to developers inside their own work environment. With the repository integration, a developer should never need to go the Mend UI to consume security results. All Renovate Enterprise features are included such as Smart Merge Control making it easier for developers to maintain their dependency health.
If your Source Control Management system is not mentioned below or your code base does not use a supported package manager, you must use the pipeline integration.
Mend supports the following repository integrations:
Cloud Repository integrations
Github.com
Azure DevOps*
The Azure Devops repository integration is currently being overhauled slated for Q4 of 2024. It is recommended to start with a pipeline strategy until this new integration is released.
Bitbucket Cloud
Self-Hosted integrations
Github Enterprise/EMU
Gitlab Server
Bitbucket Data Center
This documentation series covers the Cloud Repository integration set up.
Setting up a self-hosted integration is not simple. It requires infrastructure to deploy and careful planning is required to scale correctly.
For Self-Hosted integrations, speak with your Customer Success Manager who will assign a Mend Onboarding Engineer to guide you through the process.
If you want to get started scanning right away and you need a self-hosted integration, it is recommended you start with pipeline scanning.
Pros | Cons |
|---|---|
Scalable Mass Rollout | Need to configure access to private registries |
No User Management Required | Lack of configurations for breaking apart Mono repositories into separate modules |
Renovate EE Features | Additional setup required for container scanning (pipeline/registry) |
Differential scan results | SAST is not available for Bitbucket Server, GitLab or Azure DevOps |
Scan results where developers live | Static application/project structure |
Known Repository Integration Gaps
The following features are currently missing from the repository integration and require the addition of pipeline scanning to be utilized.
Only one branch can be configured for repository issue tracking and publishing SAST scan results to the Mend UI.
Image scanning
SAST scanning is unavailable for GitLab Enterprise, Bitbucket DataCenter and AzureDevops
Pipeline
Pipeline refers to any type of scanning using the Mend CLI or the Mend Unified Agent directly. These scanners are typically built into your CI/CD process to automatically scan your applications as they are being built for delivery to Dev/QA/production.
The pipeline integration is ideal when flexibility is required. It allows full control over how results are reported to the Mend UI, which is especially useful for generating and reporting SBOMs. However, setting up a pipeline integration can be more complex, especially without centralized pipeline templates, and it may be more challenging for developers to access results. They may need to export reports via API or visit the Mend UI to view fix suggestions. Automatic dependency updates can be configured to replicate the functionality of repository integration by using the community version of Renovate
Pros | Cons |
|---|---|
Customizable application/project structure | Harder for developers to consume results with the need to either export reports via API or go to the Mend UI to see fix suggestions |
Can run customized scripts post scan | Need to configure open-source renovate separately |
Pre-existing build environment (in theory) | Difficult to scale (rollout & maintain) without centralized pipeline templates |
More flexible | Requires insertion into build (not a build adjacent) |
Access Control and Organization Structure
While Access Control can be a complex topic, this documentation series will focus on two different options to keep it simple:
AppSec Admin access only
Developer access
Which one you use depends on the scan strategy you have implemented and the goals of your AppSec program.
Some questions to consider:
Who should be maintaining results within the Mend UI?
Suppressing false positives, creating tickets, generating reports or updating/modifying library licenses and copyrights.
Resolving vulnerabilities should not be consider since that can only be performed by a developer applying the appropriate upgrades
How do I want my developer to be consuming Mend Results?
Should developers be allowed to see results for projects they do not own?
It is possible to set up access control so developers will only see the projects they own. However, this requires a heavy amount of group management which can slow down the roll out of Mend.
Organization structure will depend on what scan strategy you decide will be covered in more detail in the individual integration guides.
Mend does support SSO integration via SAML but this should not have a huge bearing on the Access Control decision.
Admin only UI access
Pros | Cons |
|---|---|
Simple setup | Developers cannot generate reports without service userKey and API access |
No group management | |
No Mend UI training required for developers |
|
Developer UI access
Pros | Cons |
|---|---|
Developers have full access to reports and UI | UI training required for developers |
Cumbersome setup & maintenance via scripting |
Results Consumption
Results consumption is an important decision to drive value out of Mend. Not reviewing the results of a scan is effectively the same as not scanning the application at all. It is important to provide results to different stake holders in a way that makes the most sense for them to consume. It is possible to implement multiple methods of Results Consumption. The best strategy to consume results is the one your stakeholders want to use most. The only metric for a successful consumption strategy is whether or not scan results are being utilized in some fashion or another.
Stakeholders to take into consideration:
Executives
Management
Security Team
Developers
Mend UI
The Mend UI is typically used by the Security Team to review findings from scans. However, this can also be used to generate reports for Executives. Additionally, developers can be given access to view findings where needed in instances where other methods such as Jira or SCM Issue Trackers with Repo Integrations do not work for your organization.
Pros | Cons |
|---|---|
Source of Truth for all Mend Results | Need to set up access control |
Can suppress findings or alerts and modify license/copyright information | Information is not focused to a specific group without setting up labels |
Jira through Mend Jira Integration
The Mend Jira Integration creates Jira tickets with information about findings posted in the Mend UI. This is most useful when a company’s primary form of productivity tracking is through Jira tickets, or if an organization has multiple different SCM systems that all connect to Jira in the SDLC.
Pros | Cons |
|---|---|
Can set conditions for creating tickets automatically though Workflow engine | 30 minute - 1 hour sync time |
Can manually create Jira tickets through Mend UI | One way sync - Closed Jira tickets do not suppress the vulnerability within Mend and Vice/versa |
Ticket status tracking within the Mend UI | Requires specific Mend Fields and Issue types set up by the integration |
Issues are only created a scan is completed | |
Issues cannot be created in multiple Jira Boards |
Custom Scripts using Mend API
Creating custom scripts is most often beneficial when the Repository Integrations cannot be used, but scan results still are still desired after a scan in a pipeline. Typically these reports can be generated/formatted during the pipeline and then published as an artifact to the pipeline alongside any scan logs.
Pros | Cons |
|---|---|
Can be automated and built into tooling | Needs to be developed and maintained |
Complete customization over output | |
Can provide results without requiring access to UI via a service user |
Repository Integration Only
Source Control Management System issue tracker
Examples of a “Source Control Management System issue tracker” includes features of SCM systems such as GitHub Issues, Bitbucket issues, etc. This method is typically the recommended way for most development teams as it does not require logging into any other systems, or any extra setup past installing the integration, and provides the quickest way to get results from a scan.
Pros | Cons |
|---|---|
Built into the SCM | Not all teams have issues enabled |
Maintained by the integration - If a vulnerability is fixed or suppressed, the issue will be closed | Manually closed issues are considered “Ignored” by the integration |
Thresholds can be configured per team or globally across all teams | Little to no customization options |
Commit/Pull Request Status Checks
If Issue Trackers for Repository Integrations are not usable, another option is to use Commit/Pull Request Status Checks which provide a report of the findings that resulted from the scan associated with that commit. This is used by development teams to get a report of the dependencies that have vulnerabilities, and which version that library needs to be updated to, to remediate the vulnerabilities.
Pros | Cons |
|---|---|
Provides immediate feedback to developers | Requires setting status check as required to block merging |
Differential results |
Next Steps
Having trouble deciding what you should do? A good place to start is the cloud repo integration. If that is not possible, start with the pipeline, give developers access to the UI, and as many forms of results consumption as possible. These can always be tweaked later when you have a better understanding of Mend and how you want to run your AppSec Program.
Once you have decided on your Scan Strategy, Access Control, and have a general idea for Results Consumption. Proceed to the rollout guides for each scan strategy to get started rolling out Mend to your organization.
Pipeline Rollout
Cloud Repository Rollout