MClarkson676368 (Community Member) asked a question.

Using Veracode Auto-Packager and Pipeline Scan in GitLab CI/CD

We integrate Veracode into our GitLab CI/CD pipelines using:

 

  • Auto-Packager
  • Pipeline Scan (pipeline-scan.jar)
  • Policy & Sandbox scans
  • Agent-SCA

 

Challenge: Multiple Artifacts from Auto-Packager

When using auto-packager, it sometimes creates more than one package artifact. This causes issues for the downstream pipeline scan, as:

 

  • You can’t point the scan at the entire auto-packager output directory.
  • You can’t specify multiple files on the pipeline scan command line.

 

Our Approach

We iterate through the contents of the auto-packager output directory and invoke a separate pipeline scan for each artifact. So far, so good.

 

Integrating with GitLab Security Dashboard

To import results into the GitLab security dashboard, we use the --gl_vulnerability_generation flag. However:

 

  • The GitLab vulnerability report filename is hardcoded in pipeline-scan.jar.
  • There’s no command-line option to override it.

 

Solution: After each pipeline scan, we move and rename the GitLab vulnerability report to avoid overwriting. Simple enough.

 

Next Hurdle: GitLab Accepts Only One SAST Report per Job

GitLab only ingests one SAST report per job, so we needed a way to merge individual reports into a single file.

 

After some head-scratching and getting familiar with jq, I succeeded! So I thought I'd share the jq recipe for anyone in the same situation.

 

Have you solved this differently? Or faced other challenges using Veracode within GitLab? I’d love to hear your approach.

 

jq recipe to merge SAST reports:

- |

# Put merged file under gl-sast/

export SAST_REPORT_DIR="gl-sast"

# export SAST_MERGED_FILE="${SAST_REPORT_DIR}/gl-sast-report.json"

export SAST_MERGED_FILE="gl-sast-report.json"

 

 

echo "SAST_REPORT_DIR=${SAST_REPORT_DIR}"

echo "SAST_MERGED_FILE=${SAST_MERGED_FILE}"

echo "PWD=$(pwd)"

 

# Safer glob handling

shopt -s nullglob

files=( "${SAST_REPORT_DIR}"/gl-sast-report-*.json )

 

if (( ${#files[@]} )); then

echo "Found ${#files[@]} SAST JSON(s): ${files[*]}"

# Create parent dir just in case

# install -d -m 0775 "$(dirname "$SAST_MERGED_FILE")"

 

# Merge with jq (strict GitLab SAST; auto-parse stringified JSON)

# Notes:

# - use -s to slurp all files into a single array for reduce .[]

# - use try fromjson catch {} to safely parse strings

jq -sSe '

# Normalize one report into GitLab SAST shape

def norm($r):

# If top-level is a JSON string, parse it; otherwise use as-is

( if ($r | type) == "string"

then ( try ($r | fromjson) catch {} )

else $r

end

) as $doc

|

if ($doc | has("vulnerabilities")) then

{

version: ($doc.version // "15.0.0"),

scan: ($doc.scan // null),

vulnerabilities: (

$doc.vulnerabilities

| if (type == "array") then . else [] end

)

}

else

{ "__error__": "missing_vulnerabilities_key" }

end;

 

# Normalize all inputs (slurped into an array by -s)

[ .[] | norm(.) ] as $all

 

# Merge: skip invalid inputs; preserve first non-null version/scan; concat vulnerabilities

| {

version: (

($all | map(select(has("__error__")==false) | .version) | first)

// "15.0.0"

),

scan: (

$all | map(select(has("__error__")==false) | .scan) | first

),

vulnerabilities: (

$all

| map(select(has("__error__")==false) | .vulnerabilities)

| add

)

}

' "${files[@]}" >"$SAST_MERGED_FILE"

 


  • SamHouston (Veracode)

    Hi @MClarkson676368 (Community Member)​ -

     

    Our Gitlab Workflow Integration will be helpful here: https://docs.veracode.com/r/GitLab_Workflow_Integration

     

    GitLab pipelines unfortunately doesn't allow any dynamic configuration, so you need to know all artifact-names before you start the pipeline.

     

    Our official GitLab workflow integration has a little JavaScript that is doing the trick. But with GitLab Pipelines on its own, you most probably can't solve this issue. At least we have not found any other way to do that.

    You need some sort of wrapper that is doing the scanning for you.

    Expand Post
    Selected as Best
  • SamHouston (Veracode)

    Hi @MClarkson676368 (Community Member)​ -

     

    Our Gitlab Workflow Integration will be helpful here: https://docs.veracode.com/r/GitLab_Workflow_Integration

     

    GitLab pipelines unfortunately doesn't allow any dynamic configuration, so you need to know all artifact-names before you start the pipeline.

     

    Our official GitLab workflow integration has a little JavaScript that is doing the trick. But with GitLab Pipelines on its own, you most probably can't solve this issue. At least we have not found any other way to do that.

    You need some sort of wrapper that is doing the scanning for you.

    Expand Post
    Selected as Best
  • MClarkson676368 (Community Member)

    Hi @SamHouston (Veracode)​ ,

     

    Thanks for your reply, but it misses the main point.

     

    We built our own integration using GitLab global templates and components before the Veracode GitLab integration existed. We also can’t use your integration today because we self‑host GitLab, and it still only supports GitLab SaaS—not self‑hosted Premium or Ultimate. Realistically, this shouldn’t be difficult to address: making GITLAB_URL configurable in your UI or relying on GitLab’s predefined CI/CD variables (CI_API_V4_URL, CI_REPOSITORY_URL, etc.) instead of hardcoding gitlab.com would solve that.

     

    Additionally, based on the documentation you shared, I don’t see any option to produce a GitLab‑format SAST report file that GitLab can ingest for the Security tab or the Security Dashboard. The integration seems limited to creating issues or viewing results via the job console log or the Veracode platform.

     

    In our setup, we already iterate through the Veracode Packager output directory, run Pipeline Scan on each packaged artifact, and rename/move the resulting files—including those generated with --gl_vulnerability_generation.

    We chose this approach for simplicity instead of triggering a GitLab child pipeline job from a generated yaml artifact for each artifact.

     

    The challenge we faced as we were iterating and invocating multiple pipeline scans was that GitLab doesn’t support multiple report files in a single job, which required us to combine those outputs into one valid GitLab SAST report. The recipe I shared was intended to help others encountering the same limitation.

     

    Michael

    Expand Post

Topics (5)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.