Workflow Configuration Parameters in the Mend AI Native AppSec Platform

Overview

This article covers the Automation Workflow configuration options within the Application of the Mend Platform.

Getting it done

Workflows - General Details

The General Details section is where you name your workflow. This value is displayed in the Name column within the Automation page of the Mend Platform.

Tip: We recommend naming the workflow with a value that will help you and your team understand its usage.

Workflows - Triggering Event

The Triggering Event section is where you set the event(s) (WHEN) to trigger the workflow.

The triggering events are grouped into the following Triggering Event Types:

Security

Available for:

Code (SAST)
Containers
Dependencies (SCA)
AI (requires an AI Premium subscription)

Legal

Available for:

Containers
Dependencies (SCA)
AI (requires an AI Premium subscription)

Operational

Available triggering events include:

New Application Created
New Project Created
Scan Completed

Scan Completed

Note: “Scan Completed” is an engine-agnostic triggering event. Any completed scan which meets the criteria defined in the workflow will trigger it.

When Scan Completed is chosen as the operational triggering event, the Event Conditions interface will change and allow you to specify tags based on the following:

Key - e.g., branch, sourceUrl
Key:Value - e.g., sourceUrl:[Repo_URL] (up to ten entries are supported)
Regex - e.g., branch:release.*

The tags can then be used to trigger a label assignment action at the project or application level, to further filter and organize data across AppSec Platform views. This can be useful in a multitude of use-cases. See some examples below.

Note: Available actions include assigning preexisting labels. Use the Administration → Labels page to create the desired labels, then come back to the Workflows page to use them.

Example A:

Identify branches tagged as Release branches.

Using a **Key** Scan Tag to Assign Labels to Release Branches of the Application

Example B:

Assign ownership to different development teams based on the repository names (sourceUrl).

Using a **Key:Value** Scan Tag to Assign Labels to Development Teams Based on Repository URL

Note: If you have other workflows which rely on label matching as a scope condition, you can utilize the Scan Tag <> Label conversion depicted above to trigger those workflows.

In the example below, a workflow with a Security (Dependencies Analysis) triggering event will be triggered by the workflow demonstrated in example B above, in which we assigned a “Team A” label based on the repository URL:

Workflows - Scope Conditions

The Scope Conditions section is where you define the scope that the conditions/triggers will apply to, where you can select the option to Include/Exclude the defined settings:

Entire Organization
Application
Project
Labels

Workflows - Event Conditions

The Event Conditions section is where you set the condition(s) (IF) to trigger the workflow. You can set multiple conditions condition groups and define their logical expressions (OR, AND).

By Model Scan Complete - AI

Condition	Details
`Is Malicious Model`	The workflow action will be triggered if a malicious model is detected (or not). You can set the workflow trigger values to either `True` or `False`.
`Licenses`	The workflow action will be triggered if a specific License Name is found (or not). You can set the workflow trigger values to either `In`, `Is Empty`, `Match`, `Not In`, `No Match`, or `Regex` and select license name(s) from the dropdown list. Notes: Event conditions for licenses rely on exact string matches and do not support ranges. For example: If an event condition specifies “LGPL 1.0 or Later”, LGPL 1.0 will only be matched when the library license is listed as "LGPL 1.0 or Later" and not if the library license is listed as "LGPL 2.0". The number of selected licenses is limited to 50.
`Model Age`	Set the Model Age by those older than a certain number of days or months, defining a specific date range (`Between`), `Greater Than`, or `Less Than`.
`Model Name`	The workflow action will be triggered if a model name matching the defined criteria is detected.
`Vulnerability ID`	The workflow action will be triggered if a specific Vulnerability ID is found (or not). You can set the workflow trigger values to either `Equals` or `Not Equals`.
`Vulnerability Score`	Set the Vulnerability Score rating criteria that will trigger the workflow action. The supported syntax is a decimal number from 0 - 10. For example: `5.4`
`Vulnerability Severity`	The workflow action will be triggered if a Vulnerability Severity equals (or not). You can set the workflow trigger values to either `Unknown`,`Low`, `Medium`, `High`, or `Critical`.

SAST

Security (Code Analysis)

Condition	Details
`Finding Age`	Set the Finding Age by those older than a certain number of days or months, defining a specific date range (`Between`) or `Greater Than`.
`Finding CWE Type`	Set the specific CWE Type ID from the provided dropdown list that will trigger the workflow action. Note: Using the OWASP Top 10, SANS Top 25 or PCI DSS templates from the Template Gallery will autofill all the relevant CWE Type IDs.
`Finding Detection Date`	Flag findings according to an exact detection date or a defined period (before/after a certain date).
`Finding Has Endpoint Access`	Flag findings with a detected endpoint access (True/False).
`Finding Is Exploitable`	Flag findings with known, publicly available exploits to help prioritize remediation (True/False).
`Finding Probability`	Flag findings by their probability (Low/High).
`Finding Severity`	Set the Findings Severity and occurrences criteria that will trigger the workflow action. The supported syntax is a number greater than 0.
`Finding Violates Compliance Standard`	Flag vulnerabilities that violate one of these compliance standards (Equals/Not Equals): OWASP Top 10 2021 SANS/CWE Top 25 PCI DSS

SCA

Security (Dependencies Analysis)

Note: Automation workflows apply in every scan, regardless of whether the --update parameter is specified in the scan command or not.

Condition	Details
`Direct Dependency`	Determines whether the workflow action applies to libraries classified as direct or transitive dependencies. Values: True → Actions apply only to libraries that are direct dependencies of the project. False → Actions apply only to libraries that are transitive dependencies of the project.
`EPSS Score`	Set the EPSS Score rating criteria that will trigger the workflow action. The supported syntax is a decimal number from 0 - 1. For example: `0.4`.
`Exploit Available`	Flag vulnerabilities with known, publicly available exploits to help prioritize remediation.
`Is Malicious Package`	The workflow action will be triggered if a malicious package is detected (or not). You can set the workflow trigger values to either `True` or `False`.
`Library Age`	The workflow action will be triggered if a library age matching the defined criteria is detected.
`Library Name`	The workflow action will be triggered if a library name matching the defined criteria is detected.
`Vulnerability ID`	The workflow action will be triggered if a specific Vulnerability ID is found (or not). You can set the workflow trigger values to either `Equals` or `Not Equals`.
`Vulnerability Reachable`	The workflow action will be triggered if a Reachable Vulnerability is found (or not). You can set the workflow trigger values to either `True`, `False`, or `Unknown`.
`Vulnerability Score`	Set the Vulnerability Score rating criteria that will trigger the workflow action. The supported syntax is a decimal number from 0 - 10. For example: `5.4`
`Vulnerability Severity`	The workflow action will be triggered if a Vulnerability Severity equals (or not). You can set the workflow trigger values to either `Unknown`,`Low`, `Medium`, `High`, or `Critical`.

Legal (Dependencies Analysis)

Condition	Details
`Direct Dependency`	Determines whether the workflow action applies to libraries classified as direct or transitive dependencies. Values: True → Actions apply only to libraries that are direct dependencies of the project. False → Actions apply only to libraries that are transitive dependencies of the project.
`Library Age`	The workflow action will be triggered if a library age matching the defined criteria is detected.
`Library Name`	The workflow action will be triggered if a library name matching the defined criteria is detected.
`Licenses`	The workflow action will be triggered if a specific License Name is found (or not). You can set the workflow trigger values to either `In`, `Is Empty`, `Match`, `Not In`, `No Match`, or `Regex` and select license name(s) from the dropdown list. Note: Event conditions for licenses rely on exact string matches and do not support ranges. For example: If an event condition specifies “LGPL 1.0 or Later”, LGPL 1.0 will only be matched when the library license is listed as "LGPL 1.0 or Later" and not if the library license is listed as "LGPL 2.0". The number of selected licenses is limited to 50.
`Multiple Licenses`	The workflow action will be triggered when a library is associated with more than one license. Operator: Greater Than or Equal (≥) Default Value: 2 Input Type: Numeric (integer only) If the number of licenses associated with a library is greater than or equal to the configured number, the workflow action should trigger.

Containers

Security (Containers Analysis)

Condition	Details
`EPSS Score`	Set the EPSS Score rating criteria that will trigger the workflow action. The supported syntax is a decimal number from 0 - 1. For example: `0.4`.
`Layer Group`	Available values: Base Layers Application Layers The workflow action will be triggered if a specific layer type is found (or not). You can set the workflow trigger values to either `Equals` or `Not Equals`.
`Library Name`	The workflow action will be triggered if a library name matching the defined criteria is detected.
`Library Type`	The programming language or package manager of the detected library (e.g., Debian, Go, Maven, etc.)
`Vulnerability ID`	The workflow action will be triggered if a specific Vulnerability ID is found (or not). You can set the workflow trigger values to either `Equals` or `Not Equals`.
`Vulnerability Reachable`	The workflow action will be triggered if a Reachable Vulnerability is found (or not). You can set the workflow trigger values to either `True` or `False`.
`Vulnerability Score`	Set the Vulnerability Score rating criteria that will trigger the workflow action. The supported syntax is a decimal number from 0 - 10. For example: `5.4`
`Vulnerability Severity`	The workflow action will be triggered if a Vulnerability Severity equals (or not) . You can set the workflow trigger values to either `Unknown`,`Low`, `Medium`, `High`, or `Critical`.

Legal (Containers Analysis)

Condition	Details
`Library Name`	The workflow action will be triggered if a library name matching the defined criteria is detected.
`Library Type`	The programming language or package manager of the detected library (e.g., Debian, Go, Maven, etc.)
`Licenses`	The workflow action will be triggered if a specific License Name is found (or not). You can set the workflow trigger values to either `In`, `Is Empty`, `Match`, `Not In` or `No Match` and select license name(s) from the dropdown list. Note: Event conditions for licenses rely on exact string matches and do not support ranges. For example: If an event condition specifies “LGPL 1.0 or Later”, LGPL 1.0 will only be matched when the library license is listed as "LGPL 1.0 or Later" and not if the library license is listed as "LGPL 2.0".

Workflows - Action options

The Actions section is where you set the response (THEN) to the condition(s) being met for the workflow.

Value	Details
`Assign Label`	Set the Labels from the provided dropdown list that will be assigned for the Application/Project. Note: The number of selected labels is limited to 50.
`Create Jira Issue`	Create a Jira Issue. Note: Creating Jira Issues from within the Mend AppSec Platform requires a Jira Integration installed and configured. The Create Jira Issue action is not supported for the “Licenses” event condition.
`Create Policy Violation`	Create a Policy Violation for a triggered completed scan. You have to configure the Violation Priority, Violation SLA, and if to fail the pipeline when a violation is detected. To learn more about configuring policy violation settings, please refer to our Configure Policy Violations with Automation Workflows documentation.
`Email Scan Details`	When triggered, findings from this workflow are added to the scan summary email sent to the Organization and Application Admins. Notification preferences can be managed from the Profile settings ().

Email Notifications

Note: By default, users will receive scan summary emails only for applications they are authorized to access, based on their assigned permissions.
Email notifications are turned on by default for admin users only. They will need to be enabled for non-admins.

Navigate to My Profile → Email Notifications to enable/disable Scan Summary Email notifications for your user.

Email notifications can be enabled/disabled per organization or as a bulk operation for all the organizations your user is a member of, using the Enable for All Organizations toggle.

Click “Yes, Enable” when prompted, to confirm.

Support for Non-Users and Distribution Lists

A new user type, Notification User, can be used to configure email and workflow notifications to be sent to email distribution lists and non-platform users (notification-only users).

Notification Users do not have a username or password and cannot log into the platform. They should only be used for notifications for distribution lists and non-platform users.
Notification Users must have a role assigned (e.g., Member) via group membership. They can be added to existing groups or to newly created groups. via the Administration → Groups page.

Note:

Using the same email address for two different user types (e.g., a regular platform user and a notification user) is not supported.
While the role assignment for a Notification User is a technical requirement for receiving email and workflow notifications, it has no impact outside of that, as these users have no access to the Mend AppSec Platform and do not inherit any permissions associated with roles.