Find all the support you need on your Veracode journey.

A fresh batch of platform updates just landed across the Veracode portfolio. Here's what's shipped since August 5th — from smarter scan notifications to sharper DAST targeting and a more capable packaging runner for GitHub and GitLab integrations.

EASM: Real-Time Scan Event Notifications

Released August 5, 2026

External Attack Surface Management (EASM) now sends real-time, in-app notifications the moment a scan completes, fails, or gets cancelled. No more manually refreshing scan status — security teams get an immediate signal, keeping threat surface monitoring responsive and shrinking the gap between detection and action.

Notifications show up directly in the EASM interface, so teams can track scan outcomes without ever leaving the workflow.

• Learn more: EASM documentation
• Release notes: EASM release notes

DAST: Business Unit Targeting and Scan Engine Enhancements

Released August 6, 2026

Dynamic Analysis (DAST) now lets teams assign a business unit when creating a web application or API specification target — or straight from the DAST configuration page. That makes it simple to organize and filter scan targets by business unit, a real win for organizations that need to align application security reporting with internal team and ownership structures.

The DAST scan engine also got sharper, with improved detection for CAA record checks on SSL certificates for CWE-862 — applied across both Dynamic Analysis and DAST. Better detection means more accurate identification of certificate-related misconfigurations, so teams can close gaps before they're exploited.

• Documentation: Scan web applications (DAST) | Scan APIs
• Release notes: Web Application Scanning release notes

GitHub Workflow Integration: Check Runs Bug Fix (v2.1.2)

Released August 6, 2026

A minor release of the GitHub Workflow Integration (v2.1.2) fixes a bug where GitHub APIs weren't updating and reflecting the correct check runs status. With the fix in place, check run results now display accurately in GitHub — so developers and security teams can trust the status shown right in pull requests and commit views.

Runner Image scm-packaging-5.0.0: Expanded Packaging for GitHub and GitLab

A new default runner image — scm-packaging-5.0.0 — is now available for GitHub and GitLab repository integrations, replacing scm-packaging-3.0.0

. The updated image brings a broad refresh of underlying components, expanding support for a wider range of project types and increasing overall project coverage across repo workflows.

Updated components include:

• Alpine v3.24.0
• Ubuntu v26.04
• .NET v10
• PipEnv v2026.6.2
• libicu v78
• Node.js v22.22.1
• Python v3.14.4

GitHub Workflow Integration (v2.1.1) also introduces a new uninstallation workflow. Administrators can now uninstall the Veracode app from GitHub organizations directly through the Veracode Platform — streamlining lifecycle management without toggling settings in GitHub itself.

GitLab gets the same scm-packaging-5.0.0 support, enhancing packaging capabilities in repo workflows and broadening the range of project types covered.

• Packaging details: GitHub Workflow packaging requirements

That's the full set of updates since August 5th. For a complete history of platform changes, visit the Veracode release notes.

Hi Veracode Community Experts,

I have a question regarding External Control of File Name or Path (CWE-73) findings reported by Veracode Static Analysis.

To mitigate path traversal, I added the following validation method:

public static boolean isWithinBaseDir(File file, String baseDir) {

  try {

    String canonicalFile = file.getCanonicalPath();

    String canonicalBase = new File(baseDir).getCanonicalPath();

    // Ensure trailing separator so "/allowed" doesn't match "/allowedExtra/file"

    if (!canonicalBase.endsWith(File.separator)) {

      canonicalBase += File.separator;

    }

    return canonicalFile.startsWith(canonicalBase);

  } catch (IOException e) {

    _log.error("IOException during canonical path check: " + e.getMessage());

    return false;

  }

}

This method resolves both the target file path and the allowed base directory to their canonical paths and verifies that the target file is located within the allowed directory.

However, after implementing this validation, Veracode Static Analysis still reports the same CWE-73 finding.

My understanding is that isWithinBaseDir() is a runtime validation. It prevents path traversal during application execution, whereas Veracode Static Analysis does not execute the application. Instead, it performs static data-flow analysis by tracing user-controlled input from the source to the sink.

Because of this, I suspect Veracode may not recognize this runtime validation as sufficient mitigation.

Could you please confirm whether my understanding is correct? Is this the reason the finding is still being reported?

If so, what is the recommended way to fix CWE-73 so that Veracode recognizes the mitigation? Are there any Veracode-recommended coding patterns, APIs, or validation techniques that the static analyzer can recognize for this category of findings?

Any guidance or best practices would be greatly appreciated.

Thank you!

Can not fix "CWE-73: External Control of File Name or Path" vulnerability in the following Python code:

```

import os

def load_json_data(json_file_path: str) -> dict:

  if not json_file_path.endswith('.json'):

    raise ValueError('The file should be in json format')

  # Ensure the file is in the project directory to prevent external file path traversal.

  abs_path = os.path.abspath(os.path.join(PROJECT_ROOT, json_file_path))

  if not abs_path.startswith(PROJECT_ROOT):

    raise ValueError(f'The file path is outside the project directory: {json_file_path}')

  with open(abs_path, 'r') as f:

    json_data = json.load(f)

  return json_data

```

Can please anyone take a look and tell how to fix it?