Skip to main content

Roll out Veracode GitHub Workflow App

After planning a deployment, ensure your environment meets the prerequisites, and you have the required permissions for configuring the required GitHub repositories.

The deployment involves installing and configuring the GitHub Workflow App in an organization and importing the configuration from the centralized repo to other repos.

Prerequisites​

  • Licensing

    You must be licensed for the Veracode scan types you plan to run. No additional Veracode license is required to use the GitHub Workflow Integration.

  • GitHub requirements

    • Enable GitHub Actions on the centralized repository and on each target repository.
    • Ensure the required GitHub Actions are allowed at the organization level.
    • Generate Veracode HMAC API credentials and store the credentials securely in GitHub.
    • Import or replicate the centralized Veracode integration repository in each GitHub organization.

  • Installation scope

    Install the Workflow App per GitHub organization. In GitHub, ensure that the user installing the app has permission to install third-party apps for the organization.

  • Central repository

    After initial configuration, each GitHub organization contains a centralized veracode repository that stores scan configuration. Before installation, confirm that the organization does not already have a repository with that name.

  • Network access

    Allow outbound HTTPS (TCP 443) to Veracode and GitHub endpoints. If your organization enforces IP allowlisting, include:

    • 52.1.86.151
    • 54.156.131.97
    • 34.237.58.115

    You must also allow outbound HTTPS connections to the Veracode URLs required for the scan types you use, such as Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Infrastructure as Code (IaC). For more information, see Allow Veracode domains and IP addresses.

  • Secrets and credentials

    • Define ownership and rotation for Veracode API credentials.
    • Store secrets in GitHub Secrets or an approved secret store.
    • Follow least‑privilege principles.

  • Build toolchains

    Ensure that the required build tools, SDKs, and package managers are available for your application so that packaging and scans can run successfully.

Packaging requirements​

The GitHub Workflow App uses source-based scanning where available. When source-based scanning is not available or not suitable for a repository, the Workflow App relies on packaging and build output.

The GitHub Workflow Integration uses Veracode packaging to identify what needs to be scanned. For Linux environments, packaging is typically performed using the veracode/scm-packaging image. For Windows environments, packaging uses windows-latest.

You can override the default packager image by using the veracode_static_scan:build:packager_image parameter at the global or repository level. If you override the packager image, ensure that the custom image includes all required dependencies for your application. For more information, see About autopackaging.

Some repositories might require:

  • Manual packaging steps.
  • Custom build workflows.
  • Validation of build output before scans succeed consistently.

During rollout, you might encounter repositories that:

  • Are empty.
  • Don't contain scannable code.
  • Require access to internally hosted libraries.
  • Fail to build.
  • Don't produce the expected packaging output.

Address these issues before proceeding with broader rollout to ensure consistent scan results across repositories.

Rate limits​

  • Pipeline scan rate limit: up to 6 scans can start per 60 seconds per API key. The workflow retries automatically on HTTP 429 responses.

  • Pipeline artifact size limits can apply. Confirm current limits before large-scale rollout.

  • API rate limits per IP address:

    • .do endpoints (XML reporting): 80/min.
    • XML APIs: 250/min.
    • REST APIs: 500/min.

Install the GitHub Workflow App​

Before you begin, ensure you have reviewed the prerequisites.

  1. Install the Veracode Workflow App in each GitHub organization. For more information, see the installation instructions.
  2. Import or replicate the Veracode GitHub Actions integration repository in each GitHub organization. Keep the centralized repository private.
  3. (Optional) Maintain one overarching centralized repository to push configuration changes to organization‑level repositories.

Validate the installation​

  1. Open the Actions tab on the centralized repository.
  2. Confirm workflows complete successfully (green checks).
  3. Resolve any failures (red checks) before onboarding additional repositories.

Scale the rollout​

  • Start with a limited pilot by configuring repo_list.yml to include selected repositories.
  • Roll out incrementally, such as by language, framework, or team.
  • To save results to the Veracode Platform, ensure analysis_on_platform is enabled.
  • Monitor GitHub Actions queue times and workflow statuses.
  • Switch to manual artifact builds or custom workflows when auto‑packaging fails.
  • Work with Veracode support or consulting resources for repositories that require packaging or build assistance.
  • To run baseline scans across enabled repositories, enable issue triggers for the relevant scan types and use GitHub APIs or GitHub CLI to create scan-triggering issues in each repository. For more information, see Trigger on-demand scanning with GitHub issues.

Review scan coverage​

After each rollout increment, compare what you expect to see from repositories with what appears in GitHub and on the Veracode Platform.

Review for:

  • Enabled repositories that don't generate expected scan data.
  • Repositories with no scannable code.
  • Empty or inactive repositories.
  • Applications with unscanned modules in Veracode.

This validation is an important part of ongoing operation in large environments.

Troubleshoot and roll back​

  • For failed checks, review the GitHub Actions logs to identify the cause.
  • For packaging issues, use Veracode consultation or support resources to identify the best fix.
  • For veracode.yml changes, prioritize global configuration when possible.
  • Depending on your veracode.yml settings, failing checks can indicate either a scan-start failure or flaws that violate policy. Review the build logs to identify the root cause.

Common errors​

Use the following guidance to identify common deployment issues during rollout and ongoing operation. To troubleshoot with more detailed logs, set the debug parameter to true in veracode.yml. Disable debug logging after the issue is resolved to reduce GitHub log size.

  • HTTP 429 responses
    HTTP 429 responses indicate rate limiting. The workflow includes retry logic, so these responses might not always cause scan failure.

  • Packaging or build failures
    Packaging or build failures can indicate:

    • Unsupported build workflows.
    • Missing tooling.
    • Lack of access to private library repositories.

  • Expected scans do not appear on the Veracode Platform
    Missing scan results can indicate:

    • Empty repositories.
    • analysis_on_platform is not enabled.
    • The policy or sandbox scan trigger has not run.
    • API credentials do not have permission to create the application profile.
    • Required team assignment is missing.
    • The repository contains non-scannable code.
    • Packaging issues occurred.

  • Unexpected policy status
    Unexpected policy status can indicate:

    • The repository is mapped to the wrong application profile.
    • API credentials do not have permission to download scan results.
Last updated on