Migrating from Gen 1 to Gen 2 Detection Engines

Overview

Mend SAST uses two generations of detection engines. Gen 2 engines are the current generation and offer improved precision (fewer false positives), better performance, AI-based remediation suggestions, and support for scan profiles with toggleable low-probability findings. Gen 1 engines are the previous generation, built on a different architecture with depth-based performance configuration.

This article explains what changes when you move a project from a Gen 1 engine to the corresponding Gen 2 engine, how to plan and execute the migration, and how to document the transition for audit purposes.

This article applies to languages for which both a Gen 1 and a Gen 2 engine exist. Languages that have only a Gen 1 engine are unaffected. Languages introduced with a Gen 2 engine from the start involve no migration, because there is no previous result set to transition from. See Supported Languages and Frameworks for the current status of each language.

What changes when you move to Gen 2

A new, independent set of findings

A Gen 2 engine is not a tuned version of its Gen 1 predecessor. It uses a different architecture and a different data-flow model, and it produces an independent set of findings.

Expect the following when you first scan a project with a Gen 2 engine:

• A substantially lower total number of findings. The reduction consists mainly of findings that the Gen 1 engine reported speculatively and that are not actionable.

• New findings that the Gen 1 engine did not report.

• Little or no continuity at the level of individual finding identity, including for issues that both generations detect.

A lower finding count does not indicate reduced coverage. Coverage is defined by the CWEs and frameworks each engine supports, and is documented on the individual language pages.

Finding data is not carried over

Because the Gen 2 engine produces a completely new set of findings, findings detected by the Gen 1 engine cannot be re-identified in the Gen 2 result set. As a result, user-modified finding data is not migrated to the initial set of Gen 2 findings. This includes:

• Suppressions

• Reviewed states

• Comments

• Customized severities

Any modifications you make after the migration persist as usual across subsequent Gen 2 scans.

There is no supported mechanism for correlating or mapping individual findings between the two generations, and Mend does not recommend constructing one: matching on file, line or CWE produces both false matches and false gaps.

Configuration differences

Custom taint configuration is engine-specific and must be reviewed against the Gen 2 engine rather than assumed to apply unchanged. Gen 1 depth settings have no Gen 2 equivalent; use scan profiles instead.

Scan behavior

• The first scan after switching engine generation is a full scan. A baseline created with a different engine version is not reused for incremental scanning; a new baseline is created.

• Default per-file analysis timeouts differ: 60 seconds for Gen 1 languages and 600 seconds for Gen 2 languages. See Configure the Mend CLI for SAST for the MEND_SAST_TIMEOUT_FILE and MEND_SAST_CONFIG_MAX_TYPE_ANALYSIS_STEPS parameters.

Gen 1 deprecation

Gen 1 engines are actively maintained until their deprecation date, which is one year after the general availability of the corresponding Gen 2 engine.

After the deprecation date, the Gen 1 engine can still be used to preserve consistency, but bugs will no longer be fixed, and no new CWEs, frameworks or platform capabilities will be added to it. Deprecation does not disable the engine or cause scans to fail.

For the authoritative and current list, see Supported Languages and Frameworks.

Selecting an engine generation

When Mend introduces a new detection engine generation, the previous generation remains the default for existing organizations so that results stay consistent. New organizations default to Gen 2.

Per scan, via the Mend CLI

Engine generation parameters support a gradual rollout, letting you validate Gen 2 on selected projects before enabling it as the default across your organization:

mend code --<language>-engine-generation 1|2

For example:

mend code --java-engine-generation 2

mend code --python-engine-generation 2

mend code --go-engine-generation 2

Equivalent environment variables (MEND_SAST_<LANGUAGE>_ENGINE_GENERATION) are available for pipeline configuration, and engines can alternatively be selected by ID using the -e, --engines parameter. For the full list of parameters, short notations and engine IDs, see Configure the Mend CLI for SAST.

For your organization

To make a new engine generation the default for an organization — which also determines the engine used by repository integrations and the language configurations shown in the code scan configuration — contact Mend Support or your Customer Success Manager.

Reverting

Because the generation is a parameter, a project can be pointed back at the Gen 1 engine until that engine's deprecation date. Findings and triage data of each generation remain separate.

Recommended migration path

1. Select pilot projects. Choose two or three: at least one large or business-critical project, and one representative of your mainstream technology stack.

2. Export the current state. Generate reports for the pilot projects before switching, including resolved (historical) findings for the relevant time frame. Reports are available from the Platform UI and the API in CSV, XML and JSON, and from the CLI additionally in HTML, PDF and SARIF. Reports reflect customized severities and suppression state. Retain these exports as the record of the Gen 1 result set.

3. Run both generations in parallel. Scan the pilot projects with both generations for a representative period — two weeks is usually sufficient — so that teams compare results over a normal scan cadence rather than from a single snapshot.

4. Review the delta. Concentrate on two groups: high and critical Gen 1 findings that are no longer reported, and Gen 2 findings that are new. If your security team assesses a no-longer-reported finding as a true positive, open a support case (see below).

5. Establish the Gen 2 baseline and re-apply triage. Export the first Gen 2 result set and treat it as the new baseline. Where you previously suppressed findings individually, consider whether scan profiles, low-probability toggles or custom sanitizer configuration address the same cases centrally.

6. Roll out and complete the switch. Extend the migration application by application, then reach out to Mend Support or Customer Success to set Gen 2 as the organization default and stop scanning with Gen 1.

Downstream systems

If findings are forwarded to external systems such as Jira or a GRC tool, items created from Gen 1 findings are not automatically updated or closed by the migration. Decide before switching whether those items are closed with a documented reason or reconciled manually, and coordinate with the owner of the downstream system.

Documenting the migration for audit purposes

If your SDLC requires an auditable lifecycle for every security finding, treat the migration as a single, dated change of detection method, documented at the level of the result set rather than the individual finding:

1. Freeze and export the Gen 1 state per project on a known date, including resolved (historical) findings. This is the closing record for the Gen 1 result set.

2. Record the change event in your SDLC documentation: the date, the scope (projects and languages affected), the reason (vendor detection engine generation change), and a reference to this article and to the deprecation policy in Supported Languages and Frameworks.

3. Establish the first Gen 2 scan as the new baseline, with its own dated export.

4. Disposition the difference as a set, on the basis that the detection method changed and the previous result set is not reproducible under the new engine. Retaining both exports evidences that no finding was removed silently.

5. Handle exceptions individually. For any Gen 1 finding your security team assesses as a true positive, open a support case. Mend's response provides per-finding documentation for that exception.

Frequently asked audit questions

• Q: Were the Gen 1 findings that are no longer reported determined to be false positives?

  • A: They are not individually adjudicated, and Mend does not issue a per-finding verdict. The reduction in finding volume is a result of the higher precision of the Gen 2 engine. Findings that your security team assesses as genuine should be raised through a support case.

• Q: Did Mend change the detection criteria or the interpretation of the relevant weakness?

  • A: The detection method changes with the engine generation. Ongoing rule, CWE and framework changes are documented in the Mend SAST Release Notes. Mend does not provide a mapping from an individual Gen 1 finding to a specific Gen 2 rule change.

• Q: Did an applicable CWE, NIST or other external criterion change?

  • A: Changes in external standards are not the cause of differences between the generations. CWE coverage additions and adjustments over time are recorded in the release notes.

• Q: Is the same underlying issue reported by Gen 2 under a different finding ID?

  • A: In some cases, the same weakness in the same code is reported by the Gen 2 engine with a different identifier and a different data flow. In other cases, the Gen 1 finding does not correspond to a reachable issue and is correctly not reported. There is no supported way to determine this programmatically; correlate at project and CWE level for reporting, and use support cases for individual findings.

Reporting a finding you believe was lost

If a finding reported by a Gen 1 engine is no longer reported by the Gen 2 engine and your security team assesses it as a true positive, open a case with Mend Support including:

• The language and both engine generations used, with the scan IDs or project and scan names.

• The Gen 1 finding details: CWE, file, line, data flow and severity.

• The relevant code or a minimal reproducer, if it can be shared.

• The reasoning behind the true-positive assessment, such as a reachable input or a missing sanitizer.

Mend investigates reported cases individually.

Related articles

• Supported Languages and Frameworks

• Configure the Mend CLI for SAST

• Customize your Code Scan Configuration

• Risk Factors in Mend SAST

• Mend SAST Release Notes