Deployment strategies and planning

Before rolling out Veracode GitHub Workflow App, decide on a deployment strategy and review the planning considerations in this section.

Choose a deployment strategy

Choose a deployment strategy based on whether you are onboarding new or existing repositories.

Greenfield deployment

• Pilot with non‑critical repositories.
• Validate packaging, workflows, and results.
• Start with non‑blocking gates; enable blocking after stabilization.
• Provide developer training on how to review findings and remediation guidance.

We recommend starting with one test repository and using the settings in veracode.yml to ensure applications are fully scanned before onboarding other applications.

Brownfield deployment

• Prioritize repositories not yet onboarded to Veracode.
• Application profile names default to <GITHUB-ORGANIZATION>/<REPOSITORY>. If a different name is required, add a veracode.yml file to the default branch of the repository and set the veracode_static_scan:profile parameter.
• Ensure developers have access to Veracode, are assigned the required role, and have the appropriate team access.
• Communicate policy requirements, gating timelines, and mitigation workflows.

Manage multiple GitHub organizations

Use this approach when managing multiple GitHub organizations:

• Start with a pilot organization and a subset of repositories.
• Configure base triggers and scan settings in the pilot organization.
• Validate the setup before rolling out to additional organizations.
• Install the Workflow App in each GitHub organization.
• Ensure each organization contains a centralized Veracode repository.
• Use one additional overarching centralized repository as the source of truth.
• Make all configuration changes in the overarching repository.
• Lock other centralized repositories to prevent local edits.
• When a pull request merges to the default branch of the overarching repository, push configuration changes to each organization‑level centralized repository.

Overarching configuration and rollout

The overarching repository acts as the source of truth for shared workflow configuration. Customers can review and merge changes in one place before distributing them to the centralized Veracode repository in each GitHub organization.

This model can help customers manage configuration rollout across multiple GitHub organizations by reviewing changes before distribution.

In large environments, customers might use automation to assist with setup or ongoing onboarding across organizations. These approaches might require elevated GitHub permissions, such as organization-owner access.

Map existing application profiles

Map repositories to existing profiles when you need to preserve policy history, ownership, mitigation history, or reporting structures.

If repositories are not mapped to existing application profiles, the Workflow App can create new application profiles using the default naming convention. This can result in duplicate application representations, which can affect reporting and analytics.

One way to reduce per-repository configuration is to rename existing application profiles to match the default GitHub naming convention. This can reduce the need to maintain individual veracode.yml files, but it can also affect reports that rely on application names.

If renaming profiles is not appropriate, add a veracode.yml file to each repository that must map to an existing application profile:

veracode_static_scan:
  profile: PLATFORM-PROFILE-NAME

User and team access

GitHub repository access doesn't automatically grant access in the Veracode Platform. Administrators must assign Veracode roles and team membership explicitly.

Confirm which users need access to scan results, mitigation workflows, consultation scheduling, and policy management. When possible, use SAML with just-in-time provisioning and IdP-initiated SAML to help ensure new users are created and assigned the correct teams and roles.

For more information about common Veracode roles, see Common roles for user accounts.

For larger deployments, consider using SAML with just-in-time provisioning to manage users centrally. Depending on your identity-provider configuration, team and role assignment information can be included in the SAML assertion to simplify onboarding and access management.

These decisions are especially important when mapping existing profiles or managing SCA workspace access.

SCA workspace usage

By default, SCA scans use a single workspace, which can create visibility and access-control challenges at scale.

When multiple teams require separate access to results, review SCA workspace behavior during deployment planning and validate whether the current workspace model meets your access-control requirements.

Security and governance

Use the following guidelines to secure credentials and enforce governance controls.

• Apply least‑privilege access for GitHub and Veracode credentials.
• Encrypt secrets and rotate them regularly.
• Document policies, waivers, approvals, and audit requirements, including pull‑request gating thresholds.

Production risk reporting

Confirm which branch or event represents production-relevant risk, which policy scan is used for reporting, and whether additional metadata is required.

If you already use Veracode reporting or analytics, validate how repository-based policy scans affect your reporting model.

For scenarios where multiple repositories form one application, such as microservices, you can use Veracode Collections to group application profiles for aggregate reporting.

You can also use custom fields to add metadata to application profiles and improve custom reporting in Veracode Analytics.

Using self‑hosted runners

Self-hosted runners are recommended for environments that require custom tooling, internal network access, or access to private dependencies. See GitHub runner requirements.

• Ensure runners have required tooling and outbound HTTPS access.
• Use runs_on: self-hosted in veracode.yml when applicable.