DarkMoon in Jenkins: a pipeline step that gates the build on real findings

CI is where security either becomes routine or stays a quarterly event. The DarkMoon Jenkins plugin adds a single pipeline step that runs an autonomous assessment on the agent and gates the build on what it actually finds, not on a scanner exit code.

One step

The plugin exposes a darkmoonScan(...) step. A minimal declarative usage:

stage('Pentest') {
  steps {
    darkmoonScan(
      target: 'https://staging.example.com',
      mode: 'pro',
      apiUrl: 'https://darkmoon.internal',
      credentialsId: 'darkmoon-token',
      failOn: 'critical,high',
      recordIssues: true,
      archiveReport: true
    )
  }
}

The step wraps the portable darkmoon-ci CLI on the agent (Node 18+). It launches and waits, reads the fail verdict and campaign id, then pulls findings, the severity summary and the report.

Gate the build from the severity summary

The build result is set from the finding severities, not from CLI exit codes: failOn marks the build a failure, unstableOn marks it unstable. A run that never completes within timeout is a failure, never a silent pass.

SARIF for Warnings Next Generation

Findings are mapped to SARIF 2.1.0 (darkmoon-reports/darkmoon.sarif) so the Warnings Next Generation plugin renders the severity donut, the trend and per-issue detail in the build view. The report, the SARIF file and the CLI log are archived as build artifacts.

Auto or OSS or Pro

The mode parameter selects auto-detect, the open-source CLI reading a local data directory, or the Pro API. The same step works in all three, so a team can start on OSS and move to Pro without rewriting the pipeline.

The plugin targets Jenkins 2.479+ on JDK 17 and ships an .hpi via Releases. See the integrations catalog and the GitLab component for the same idea on another CI system.