Skip to main content
This lesson shows how to build a custom transformer that converts an OWASP Dependency-Check Jenkins stage into an equivalent GitHub Actions step. The transformer:
  • Parses the Jenkins plugin configuration to find additionalArguments.
  • Extracts key flags such as --format and --failOnCVSS.
  • Emits a GitHub Actions step that runs the dependency-check/Dependency-Check_Action and uploads generated reports.
Goal: produce a GitHub Actions job step that runs dependency-check, writes reports to reports/, and uploads those artifacts. Desired GitHub Actions step (excerpt)
What data do we get from Jenkins? The Dependency-Check plugin configuration appears as a structured hash. The important field is additionalArguments (a multi-line string). Example:
What we need to parse from additionalArguments Transformer scaffolding and environment Add or reuse your transformer (example filename: ci-pipeline-transformer.rb). You can set up a runner and environment variables for the transformer runtime. Example runner/env config:
Transformer implementation The transformer locates the additionalArguments string, applies regular expressions to extract --format and --failOnCVSS, and builds the step hash for GitHub Actions. Defaults are applied if values are absent.
Skip the publisher stage Jenkins’ dependencyCheckPublisher can be omitted for GitHub Actions because the dependency-check action writes the reports directly. Return nil in the transformer to skip that identifier:
Run a dry-run import Validate the transformation with a dry-run using the importer tool:
When you run a real migration, the tool can create a pull request in the target repo:
Pull request and converted workflow The generated workflow keeps the original environment, runners, and converted jobs. The OWASP job contains the dependency-check action and a subsequent upload-artifact step to collect reports.
A screenshot of a GitHub pull request page titled "Convert ci-pipeline-poll-scm to GitHub Actions" showing a green "All checks have passed" panel with multiple successful "Solar System CI / unit-testing" checks and a green "Merge pull request" button.
Excerpt of the generated workflow (converted OWASP job)
Execute the workflow and read logs When the action runs it triggers dependency-check, which generates multiple formats (XML, HTML, JSON, CSV, SARIF, JUnit). The action receives the --format, --out, and --failOnCVSS settings from the with.args we provided. Sample logs (trimmed):
Handling failures and ensuring artifact upload If dependency-check finds vulnerabilities above the --failOnCVSS threshold the process exits non-zero and the step fails. By adding continue-on-error: true to the dependency-check step, the job will continue and the upload-artifact step will still run so you can download the reports for inspection. Example error when threshold is exceeded:
Because continue-on-error: true is set, the Upload Artifacts step still runs and uploads the reports for inspection.
Screenshot of a GitHub Actions workflow run for the jenkins-demo-org/solar-system repo. The run "Update ci-pipeline-poll-scm.yml" shows Failure because the "Dependency Scanning - OWASP Dependency Check" job failed while steps like Installing Dependencies and NPM scanning succeeded.
Using continue-on-error: true for the dependency-check step lets subsequent steps (for example, uploading artifacts) run even if dependency-check exits non-zero. If you prefer the job to fail on vulnerabilities, omit continue-on-error (or set it to false) and make the upload conditional (for example, if: failure() or use if: always() for unconditional uploads depending on your policy).
Final notes and verification
  • After merging the generated PR, your repository will contain the converted GitHub Actions workflow. The OWASP dependency check will run as a job, produce multiple report formats, and upload them as artifacts.
  • To have the job fail on vulnerability findings, keep the required --failOnCVSS value and remove continue-on-error.
  • To always collect reports regardless of findings, keep continue-on-error: true and upload artifacts afterward.
  • The example transformer is intentionally simple: it extracts --format and --failOnCVSS and hard-codes project, path, and out. Extend the transformer to pull additional parameters (project name, report directory, credentials, etc.) from other Jenkins arguments as needed.
Screenshot of a GitHub Actions page for the jenkins-demo-org/solar-system repo showing the "ci-pipeline-poll-scm" workflow and three recent workflow runs on the main branch. The left sidebar shows workflow navigation and management options like Caches, Runners, and Usage metrics.
That’s the complete flow: parse Jenkins additionalArguments, implement a custom transformer that emits a GitHub Actions step using dependency-check/Dependency-Check_Action@main, ensure reports are written to a defined out directory, and upload those reports as artifacts even if the scanner step flags vulnerabilities.

Watch Video