Imported from securesign/tas-integrator (plugins/tas-integrator/skills/scan-jenkins/SKILL.md). Install upstream with npx skills add securesign/tas-integrator --skill scan-jenkins. Copyright stays with the author.

scan-jenkins

Scan a Jenkins environment for TAS integration readiness. Connect to the Jenkins API (read-only), inspect installed plugins, pipeline configurations, credential stores, and network reachability. Evaluate gap detection rules from shared/knowledge-base/gap-detection-rules.md, generate a blueprint using shared/templates/jenkins-blueprint.md with Jenkinsfile snippets, assign confidence scores, and present the result for review before calling /tas-integrator:export-blueprint.

Invocation

/tas-integrator:scan-jenkins

Guardrails

Operate in read-only mode. MUST NOT modify the target Jenkins instance in any way.

MUST NOT attempt to read credential values — the Jenkins API does not expose them via GET, and attempting to do so would violate the read-only guardrail. Read only credential metadata (ID, type, description).

If any step would require a non-GET request to Jenkins, skip that check and record the gap as skip with a note explaining that write access is not permitted.

Inputs

Collect Jenkins connection details and optional TAS endpoint overrides.

Required

Optional

Authentication

When jenkins_user and jenkins_token are provided, send HTTP Basic authentication on all Jenkins API requests:

Authorization: Basic base64(jenkins_user:jenkins_token)

If credentials are not provided, try unauthenticated access. On a 403 or 401 response, prompt the user for credentials and retry.

Processing Steps

Step 1 — Connect to Jenkins

1. Send GET {{jenkins_url}}/api/json to verify connectivity.
2. If the request fails, report the error and stop.
3. Extract Jenkins version from the X-Jenkins response header.
4. Extract the Java version from GET {{jenkins_url}}/systemInfo (requires authentication — if unavailable, record as unknown).
5. Store jenkins_version (e.g. 2.426.3) and java_version (e.g. 17.0.9).

Step 2 — Scan Installed Plugins

1. Send GET {{jenkins_url}}/pluginManager/api/json?depth=2 to list all installed plugins.
2. Extract each plugin's shortName, version, and active status.
3. Check for TAS-relevant plugins:

4. Classify each plugin: mark installed + active as available, mark installed but inactive as disabled (gap), mark absent as missing (gap).

Step 3 — Scan Pipeline Configurations

1. Send GET {{jenkins_url}}/api/json?tree=jobs[name,url,color] to list all jobs.
2. For each Pipeline or MultiBranch Pipeline job, retrieve the pipeline definition:
   • Scripted/Declarative: GET {{job_url}}/config.xml — extract the <script> or <definition> element.
   • MultiBranch: GET {{job_url}}/config.xml — extract the SCM source for Jenkinsfile location.
3. Search each pipeline definition for existing TAS-related patterns:

4. Detect current signing-config mode in existing pipelines:

   • If cosign initialize found AND no --use-signing-config=false → Current mode: TUF
   • If --use-signing-config=false OR explicit --fulcio-url/--rekor-url flags without cosign initialize → Current mode: Explicit URLs
   • If cosign sign found but neither pattern detected → Current mode: Unknown (legacy/non-standard)
   • If no cosign commands found → Current mode: None (no existing integration)

5. Store the total pipeline jobs scanned, which patterns matched in which jobs, whether signing/verification/attestation steps exist, and the detected current mode.

Step 4 — Scan Credential Store

1. Send GET {{jenkins_url}}/credentials/store/system/domain/_/api/json?depth=2 to list system-scoped credentials.
2. For each credential, extract:
   • id — credential identifier
   • typeName — credential type (e.g. Secret text, Username with password, Certificate, SSH key)
   • description — user-provided description
3. Check for TAS-related credentials by matching id or description against:

4. Store which credential types are present and which are missing.

Note: Read only credential metadata (ID, type, description) — never read values (see Guardrails).

Step 5 — Detect TAS Endpoints

Discover TAS endpoint URLs. Use explicit overrides from the input parameters if provided. Otherwise, attempt auto-detection in this order:

5a — From Jenkins Environment Variables

Run GET {{jenkins_url}}/env or inspect pipeline environment blocks for variables matching:

5b — From Kubernetes / OpenShift (if namespace provided)

If namespace is provided and kubectl is available, extract endpoints from individual component CRD status fields:

REKOR_URL=$(kubectl get rekor -n {{namespace}} \
  -o jsonpath='{.items[0].status.url}')
FULCIO_URL=$(kubectl get fulcio -n {{namespace}} \
  -o jsonpath='{.items[0].status.url}')
TUF_URL=$(kubectl get tuf -n {{namespace}} \
  -o jsonpath='{.items[0].status.url}')
TSA_URL=$(kubectl get timestampauthority -n {{namespace}} \
  -o jsonpath='{.items[0].status.url}')
# Append /api/v1/timestamp if not already present (for older operator versions)
[[ -n "$TSA_URL" && "$TSA_URL" != */api/v1/timestamp ]] && TSA_URL="${TSA_URL}/api/v1/timestamp"

5c — From RHEL Configuration

If the Jenkins controller runs on RHEL, check for the /etc/rhtas/ directory to detect an Ansible-deployed TAS instance.

5d — Endpoint Health Checks

Run a health check for every discovered endpoint:

Store pass/fail for each endpoint check.

5e — OIDC Provider Type and Client Detection

Classify the detected OIDC provider and, for Keycloak-based providers, probe for client type.

Provider Classification:

Examine the oidc_issuer URL pattern to determine the provider type:

Record oidc_provider_type for use in Step 8b blueprint generation.

Keycloak Client Type Detection:

If oidc_provider_type is keycloak, probe the token endpoint to detect whether the client is public or confidential:

PROBE_RESPONSE=$(curl -s -X POST \
  "{{oidc_issuer}}/protocol/openid-connect/token" \
  -d "grant_type=client_credentials" \
  -d "client_id={{oidc_client_id}}" \
  2>&1)

Classify the client type based on the error response:

Record oidc_client_type as public, confidential, or unknown.

Non-Keycloak Providers:

For non-Keycloak providers, skip client type detection and set oidc_client_type to not-applicable. The blueprint will include provider-specific guidance instead of Keycloak-specific snippets.

Step 6 — Evaluate Gap Detection Rules

Run all 25 rules from shared/knowledge-base/gap-detection-rules.md against the data collected in Steps 1–5. Record for each rule:

Rule Evaluation Sources

OIDC-005 Evaluation: Evaluate OIDC-005 using the oidc_client_type result from Step 5e:

• pass if client type is public or confidential (detected successfully)
• fail if client type is unknown (detection failed or was skipped)
• Include the detected client type in the details field

Mark rules as skip when the required data source is unavailable (e.g., no kubectl access for POLICY rules).

Step 7 — Compute Confidence Scores

Compute confidence scores using the weights from shared/knowledge-base/gap-detection-rules.md:

Convert the weighted percentages to labels:

Store overall_confidence/overall_details, detection_confidence/detection_details, and compatibility_confidence/compatibility_details.

Step 8 — Generate Blueprint Data

Build the blueprint data object for the export-blueprint skill.

8a — Header Data

Set from scan results:

8b — Platform Data

Fill placeholders for shared/templates/jenkins-blueprint.md:

Credential, Pipeline & Validation Placeholders

Jenkinsfile Snippet Generation

Generate Groovy pipeline snippets using patterns from shared/knowledge-base/cosign-signing-patterns.md and shared/knowledge-base/oidc-setup.md (Jenkins section).

Provider-Specific Token Acquisition:

Based on the oidc_provider_type detected in Step 5e, generate appropriate guidance:

For keycloak providers:

Generate Keycloak-specific snippets based on oidc_client_type:

• If confidential: Use client_credentials grant with OIDC_CLIENT_SECRET
• If public or unknown: Use password grant with OIDC_USER/OIDC_PASSWORD

For non-Keycloak providers:

Generate a guidance section instead of executable snippets. Include:

• Provider name and detected issuer URL
• Note that Jenkins lacks native OIDC for this provider
• Link to RHTAS Deployment Guide section for the specific provider
• Recommendation to use Keycloak/RHBK for Jenkins CI/CD automation

See "Non-Keycloak Provider Guidance" section below for templates.

Mode Selection: TUF Mode vs Explicit URL Mode

Choose which mode to generate based on existing configuration, TUF availability, and customer preference.

Priority order (highest to lowest):

Decision Logic:

1. Check if user explicitly requested explicit URL mode in their query (see detection patterns below)
   • If yes → Use Explicit URL Mode (override everything)
2. Check current_mode from Step 3 pipeline scanning:
   • If TUF → Use TUF Mode (preserve existing)
   • If Explicit URLs → Use Explicit URL Mode (preserve existing)
   • If Unknown or None → Continue to step 3
3. Check if tuf_url was discovered in Step 5:
   • If yes → Use TUF Mode (greenfield recommendation)
   • If no → Use Explicit URL Mode (fallback)

User Query Detection: Look for these phrases to detect explicit URL mode override:

• "use explicit URLs"
• "without TUF"
• "--use-signing-config=false"
• "don't use TUF"
• "explicit service URLs"
• "disable signing config"

Mode Recommendation Output:

Include a recommendation section in the blueprint that explains the choice and alternatives:

## 🎯 Signing-Config Mode: {{selected_mode}}

**Current Configuration:** {{current_mode_status}}
**Selected Mode:** {{selected_mode}} ({{selection_reason}})

### Mode Comparison

| Aspect | TUF Mode | Explicit URL Mode |
|--------|----------|-------------------|
| **Security** | ✅ Uses TUF for service discovery & root-of-trust | ⚠️ Manual URL configuration, no automatic root updates |
| **Maintenance** | ✅ Automatic service URL updates via TUF | ⚠️ Manual updates needed when URLs change |
| **Setup Complexity** | Requires `cosign initialize` once | Simpler - no initialization step |
| **URL Management** | Hidden in TUF metadata | Explicit in pipeline code |
| **RHTAS Compatibility** | ✅ Recommended for RHTAS 1.0+ | Compatible with all versions |
| **Transparency** | Service URLs abstracted | Service URLs visible in pipeline |

### When to Use TUF Mode (Recommended)

✅ **Use TUF Mode if:**
- TUF service is available and reachable
- You want automatic root-of-trust updates
- You prefer centralized service URL management
- You're following RHTAS deployment best practices
- **Current status:** {{tuf_recommendation_status}}

### When to Use Explicit URL Mode

✅ **Use Explicit URL Mode if:**
- TUF service is unavailable or unreachable from Jenkins
- You need full visibility of service URLs in pipeline code
- You're migrating from Sigstore Public Good to RHTAS
- You have compliance requirements for explicit service configuration
- **Current status:** {{explicit_recommendation_status}}

### Recommendation

{{mode_recommendation_text}}

Placeholder substitutions:

Example recommendations:

Scenario 1: TUF available, no existing integration (greenfield)

We recommend **TUF Mode** for this greenfield deployment. TUF provides better security 
and simpler long-term maintenance. Your TUF service at {{tuf_url}} is reachable and 
healthy.

If you prefer explicit URLs for transparency, re-run with "use explicit URLs" in your request.

Scenario 2: Existing pipelines use TUF mode

Your existing pipelines already use **TUF Mode** (detected `cosign initialize` in 3 
pipelines). This blueprint preserves that configuration for consistency.

To migrate to Explicit URL Mode, re-run with "use explicit URLs" in your request.

Scenario 3: TUF unavailable (forced explicit mode)

**TUF Mode is recommended** but your TUF service is currently unreachable from Jenkins. 
This blueprint uses **Explicit URL Mode** as a fallback.

Once TUF connectivity is established, consider migrating to TUF Mode for better security 
and easier maintenance.

Scenario 4: User explicitly requested explicit URLs

Using **Explicit URL Mode** per your request. All service URLs will be explicitly 
configured in pipeline environment variables.

TUF Mode is available ({{tuf_url}}) if you prefer centralized service management in the future.

Initialize TUF Stage (TUF Mode Only):

Generate the TUF initialization stage that runs once before signing. This stage extracts the TAS server CA certificate and initializes cosign with the TUF root, enabling TUF mode for all subsequent cosign commands.

stage('Initialize TUF') {
    steps {
        echo 'Initializing TUF for TAS...'
        sh '''
            # Remove any cached sigstore config
            rm -rf /var/jenkins_home/.sigstore || true

            # Extract TAS server CA certificate for TLS verification
            TAS_HOST=$(echo "${TAS_TUF_URL}" | sed 's|^https://||' | cut -d/ -f1)
            echo | openssl s_client -showcerts -connect "${TAS_HOST}:443" 2>/dev/null \
                | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' > /tmp/tuf-ca.crt

            # Set CA cert for TUF initialization
            export SSL_CERT_FILE=/tmp/tuf-ca.crt
            export CURL_CA_BUNDLE=/tmp/tuf-ca.crt

            # Initialize TUF
            ROOT_CHECKSUM=$(curl -s "${TAS_TUF_URL}/1.root.json" | sha256sum | awk '{print $1}')
            cosign initialize \
                --mirror="${TAS_TUF_URL}" \
                --root="${TAS_TUF_URL}/1.root.json" \
                --root-checksum="${ROOT_CHECKSUM}"

            echo "TUF initialized successfully"
        '''
    }
}

CRITICAL: After cosign initialize, TUF mode is enabled (--use-signing-config=true by default). All subsequent cosign sign, cosign attest, and cosign verify commands automatically use TUF-provided service URLs. Do NOT pass explicit URL flags like --fulcio-url, --rekor-url, or --oidc-issuer as they conflict with TUF mode and cause "cannot specify service URLs and use signing config" errors with Red Hat cosign 3.x.

Keycloak Signing Stage Snippets:

Generate the signing stage with conditional token acquisition for Keycloak providers.

CRITICAL: Use TUF mode (no explicit URL flags) per redhat-cosign-tuf-patterns.md.

For confidential clients (TUF mode):

stage('Sign Image') {
    steps {
        withCredentials([string(credentialsId: 'oidc-client-secret', variable: 'OIDC_CLIENT_SECRET')]) {
            script {
                def IDENTITY_TOKEN = sh(
                    script: """
                        export SSL_CERT_FILE=/tmp/tuf-ca.crt
                        export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                        curl -s -X POST \
                          "\${TAS_OIDC_ISSUER}/protocol/openid-connect/token" \
                          -d "grant_type=client_credentials" \
                          -d "client_id=\${OIDC_CLIENT_ID}" \
                          -d "client_secret=\${OIDC_CLIENT_SECRET}" \
                          | jq -r '.access_token'
                    """,
                    returnStdout: true
                ).trim()

                sh """
                    export SSL_CERT_FILE=/tmp/tuf-ca.crt
                    export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                    export COSIGN_YES=true
                    export COSIGN_OIDC_CLIENT_ID=\${OIDC_CLIENT_ID}
                    export SIGSTORE_ID_TOKEN=${IDENTITY_TOKEN}
                    
                    cosign sign \${IMAGE_REFERENCE}
                """
            }
        }
    }
}

For public clients (TUF mode):

stage('Sign Image') {
    steps {
        withCredentials([
            usernamePassword(credentialsId: 'oidc-user-credentials', 
                           usernameVariable: 'OIDC_USER', 
                           passwordVariable: 'OIDC_PASSWORD')
        ]) {
            script {
                def IDENTITY_TOKEN = sh(
                    script: """
                        export SSL_CERT_FILE=/tmp/tuf-ca.crt
                        export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                        curl -s -X POST \
                          "\${TAS_OIDC_ISSUER}/protocol/openid-connect/token" \
                          -d "grant_type=password" \
                          -d "client_id=\${OIDC_CLIENT_ID}" \
                          -d "username=\${OIDC_USER}" \
                          -d "password=\${OIDC_PASSWORD}" \
                          -d "scope=openid email" \
                          | jq -r '.access_token'
                    """,
                    returnStdout: true
                ).trim()

                sh """
                    export SSL_CERT_FILE=/tmp/tuf-ca.crt
                    export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                    export COSIGN_YES=true
                    export COSIGN_OIDC_CLIENT_ID=\${OIDC_CLIENT_ID}
                    export SIGSTORE_ID_TOKEN=${IDENTITY_TOKEN}
                    
                    cosign sign \${IMAGE_REFERENCE}
                """
            }
        }
    }
}

Note: Include both snippet variants in the blueprint with clear conditional headers indicating which one applies based on the detected client type. If client type is unknown, default to the public client snippet with a warning note.

Important: The Initialize TUF stage (from Step 8b) runs once before signing and sets up the signing config. After cosign initialize, all subsequent cosign sign, cosign attest, and cosign verify commands automatically use TUF-provided service URLs via --use-signing-config=true (the default). Do NOT pass explicit URL flags like --fulcio-url, --rekor-url, or --oidc-issuer as they conflict with TUF mode.

Generate the verification stage — run cosign verify with certificate identity.

TUF mode (after cosign initialize): Use only certificate flags, no URL flags:

stage('Verify Image') {
    steps {
        sh """
            export SSL_CERT_FILE=/tmp/tuf-ca.crt
            export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
            
            cosign verify \
              --certificate-identity=\${EXPECTED_IDENTITY} \
              --certificate-oidc-issuer=\${OIDC_ISSUER} \
              \${IMAGE_REFERENCE}
        """
    }
}

Generate the attestation stage — run cosign attest with SBOM predicates (TUF mode).

For confidential clients (TUF mode):

stage('Attest Image') {
    steps {
        withCredentials([string(credentialsId: 'oidc-client-secret', variable: 'OIDC_CLIENT_SECRET')]) {
            script {
                def IDENTITY_TOKEN = sh(
                    script: """
                        export SSL_CERT_FILE=/tmp/tuf-ca.crt
                        export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                        curl -s -X POST \
                          "\${TAS_OIDC_ISSUER}/protocol/openid-connect/token" \
                          -d "grant_type=client_credentials" \
                          -d "client_id=\${OIDC_CLIENT_ID}" \
                          -d "client_secret=\${OIDC_CLIENT_SECRET}" \
                          | jq -r '.access_token'
                    """,
                    returnStdout: true
                ).trim()

                sh """
                    export SSL_CERT_FILE=/tmp/tuf-ca.crt
                    export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                    export COSIGN_YES=true
                    export COSIGN_OIDC_CLIENT_ID=\${OIDC_CLIENT_ID}
                    export SIGSTORE_ID_TOKEN=${IDENTITY_TOKEN}
                    
                    cosign attest \
                      --predicate=\${SBOM_FILE} \
                      --type=spdxjson \
                      \${IMAGE_REFERENCE}
                """
            }
        }
    }
}

For public clients:

stage('Attest Image') {
    steps {
        withCredentials([
            usernamePassword(credentialsId: 'oidc-user-credentials', 
                           usernameVariable: 'OIDC_USER', 
                           passwordVariable: 'OIDC_PASSWORD')
        ]) {
            script {
                def IDENTITY_TOKEN = sh(
                    script: """
                        curl -s -X POST \
                          "\${TAS_OIDC_ISSUER}/protocol/openid-connect/token" \
                          -d "grant_type=password" \
                          -d "client_id=\${OIDC_CLIENT_ID}" \
                          -d "username=\${OIDC_USER}" \
                          -d "password=\${OIDC_PASSWORD}" \
                          -d "scope=openid email" \
                          | jq -r '.access_token'
                    """,
                    returnStdout: true
                ).trim()

                sh """
                    cosign attest \
                      --fulcio-url=\${FULCIO_URL} \
                      --rekor-url=\${REKOR_URL} \
                      --oidc-issuer=\${OIDC_ISSUER} \
                      --oidc-client-id=\${OIDC_CLIENT_ID} \
                      --identity-token=${IDENTITY_TOKEN} \
                      --predicate=\${SBOM_FILE} \
                      --type=spdxjson \
                      --yes \
                      \${IMAGE_REFERENCE}
                """
            }
        }
    }
}

Explicit URL Mode Snippets (when TUF not available or customer requests it):

If TUF is not available or customer explicitly requests --use-signing-config=false, generate these snippets instead (no cosign initialize, explicit URL flags with --use-signing-config=false).

Note: Even without TUF, you still need to extract and trust the TAS server CA certificate for HTTPS calls. Add this to the beginning of the Sign stage or as a separate preparation stage:

stage('Prepare TAS CA Certificate') {
    steps {
        echo 'Extracting TAS server CA certificate for TLS verification...'
        sh '''
            # Extract CA certificate from any TAS endpoint
            TAS_HOST=$(echo "${TAS_FULCIO_URL}" | sed 's|^https://||' | cut -d/ -f1)
            echo | openssl s_client -showcerts -connect "${TAS_HOST}:443" 2>/dev/null \
                | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' > /tmp/tuf-ca.crt
        '''
    }
}

For confidential clients (Explicit URL mode):

stage('Sign Image') {
    steps {
        withCredentials([string(credentialsId: 'oidc-client-secret', variable: 'OIDC_CLIENT_SECRET')]) {
            script {
                def IDENTITY_TOKEN = sh(
                    script: """
                        export SSL_CERT_FILE=/tmp/tuf-ca.crt
                        export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                        curl -s -X POST \
                          "\${TAS_OIDC_ISSUER}/protocol/openid-connect/token" \
                          -d "grant_type=client_credentials" \
                          -d "client_id=\${OIDC_CLIENT_ID}" \
                          -d "client_secret=\${OIDC_CLIENT_SECRET}" \
                          | jq -r '.access_token'
                    """,
                    returnStdout: true
                ).trim()

                sh """
                    export SSL_CERT_FILE=/tmp/tuf-ca.crt
                    export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                    
                    cosign sign \
                      --use-signing-config=false \
                      --fulcio-url=\${TAS_FULCIO_URL} \
                      --rekor-url=\${TAS_REKOR_URL} \
                      --oidc-issuer=\${TAS_OIDC_ISSUER} \
                      --oidc-client-id=\${OIDC_CLIENT_ID} \
                      --identity-token=${IDENTITY_TOKEN} \
                      --yes \
                      \${IMAGE_REFERENCE}
                """
            }
        }
    }
}

For public clients (Explicit URL mode):

stage('Sign Image') {
    steps {
        withCredentials([
            usernamePassword(credentialsId: 'oidc-user-credentials', 
                           usernameVariable: 'OIDC_USER', 
                           passwordVariable: 'OIDC_PASSWORD')
        ]) {
            script {
                def IDENTITY_TOKEN = sh(
                    script: """
                        export SSL_CERT_FILE=/tmp/tuf-ca.crt
                        export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                        curl -s -X POST \
                          "\${TAS_OIDC_ISSUER}/protocol/openid-connect/token" \
                          -d "grant_type=password" \
                          -d "client_id=\${OIDC_CLIENT_ID}" \
                          -d "username=\${OIDC_USER}" \
                          -d "password=\${OIDC_PASSWORD}" \
                          -d "scope=openid email" \
                          | jq -r '.access_token'
                    """,
                    returnStdout: true
                ).trim()

                sh """
                    export SSL_CERT_FILE=/tmp/tuf-ca.crt
                    export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
                    
                    cosign sign \
                      --use-signing-config=false \
                      --fulcio-url=\${TAS_FULCIO_URL} \
                      --rekor-url=\${TAS_REKOR_URL} \
                      --oidc-issuer=\${TAS_OIDC_ISSUER} \
                      --oidc-client-id=\${OIDC_CLIENT_ID} \
                      --identity-token=${IDENTITY_TOKEN} \
                      --yes \
                      \${IMAGE_REFERENCE}
                """
            }
        }
    }
}

Verify stage (Explicit URL mode):

stage('Verify Image') {
    steps {
        sh """
            export SSL_CERT_FILE=/tmp/tuf-ca.crt
            export CURL_CA_BUNDLE=/tmp/tuf-ca.crt
            
            cosign verify \
              --use-signing-config=false \
              --rekor-url=\${TAS_REKOR_URL} \
              --certificate-identity=\${EXPECTED_IDENTITY} \
              --certificate-oidc-issuer=\${TAS_OIDC_ISSUER} \
              \${IMAGE_REFERENCE}
        """
    }
}

Attest stage (Explicit URL mode):

Follow the same pattern as Sign stage, but replace cosign sign with:

cosign attest \
  --use-signing-config=false \
  --fulcio-url=\${TAS_FULCIO_URL} \
  --rekor-url=\${TAS_REKOR_URL} \
  --oidc-issuer=\${TAS_OIDC_ISSUER} \
  --oidc-client-id=\${OIDC_CLIENT_ID} \
  --identity-token=${IDENTITY_TOKEN} \
  --predicate=\${SBOM_FILE} \
  --type=spdxjson \
  --yes \
  \${IMAGE_REFERENCE}

Note: Explicit URL mode requires setting all service URLs as environment variables in the pipeline (TAS_FULCIO_URL, TAS_REKOR_URL, TAS_TSA_URL, TAS_OIDC_ISSUER).

Non-Keycloak Provider Guidance:

For non-Keycloak providers, generate a guidance section in the blueprint instead of Jenkinsfile snippets. Use the templates below based on oidc_provider_type:

GitHub Actions:

## ⚠️ GitHub Actions OIDC Detected

Your RHTAS deployment is configured with GitHub Actions as the OIDC provider:
- **Issuer:** {{oidc_issuer}}
- **Client ID:** {{oidc_client_id}}

**Jenkins Limitation:** Jenkins does not provide native integration with GitHub
Actions OIDC. GitHub Actions OIDC tokens are only available within GitHub Actions
workflows.

**Recommended Approach:**
1. **Option A (Recommended):** Configure Keycloak or Red Hat SSO as an additional
   OIDC issuer in Fulcio for Jenkins-based signing. See the RHTAS Deployment Guide
   section on "Configuring multiple OIDC issuers."

2. **Option B:** Perform signing within GitHub Actions workflows instead of Jenkins.
   Refer to the RHTAS Deployment Guide section on "Signing with GitHub Actions."

Google OAuth:

## ⚠️ Google OAuth OIDC Detected

Your RHTAS deployment is configured with Google OAuth as the OIDC provider:
- **Issuer:** {{oidc_issuer}}
- **Client ID:** {{oidc_client_id}}

**Jenkins Limitation:** Google OAuth uses browser-based authentication flows and is
not suitable for Jenkins CI/CD automation (non-interactive pipelines).

**Recommended Approach:**
Configure Keycloak or Red Hat SSO as the OIDC issuer for CI/CD automation. Keycloak
can optionally federate to Google for interactive user authentication while providing
service account credentials for Jenkins pipelines.

Refer to the RHTAS Deployment Guide sections:
- "Configuring Keycloak OIDC Issuer"
- "Keycloak Identity Provider Federation" (optional Google integration)

Microsoft Entra ID:

## ⚠️ Microsoft Entra ID OIDC Detected

Your RHTAS deployment is configured with Microsoft Entra ID as the OIDC provider:
- **Issuer:** {{oidc_issuer}}
- **Client ID:** {{oidc_client_id}}

**Jenkins Limitation:** Microsoft Entra ID uses browser-based authentication flows
and is not suitable for Jenkins CI/CD automation (non-interactive pipelines).

**Recommended Approach:**
Configure Keycloak or Red Hat SSO as the OIDC issuer for CI/CD automation. Keycloak
can optionally federate to Microsoft Entra ID for interactive user authentication
while providing service account credentials for Jenkins pipelines.

Refer to the RHTAS Deployment Guide sections:
- "Configuring Keycloak OIDC Issuer"
- "Configuring Microsoft Entra ID" (for user federation)

AWS STS:

## ⚠️ Amazon STS OIDC Detected

Your RHTAS deployment is configured with Amazon Security Token Service:
- **Issuer:** {{oidc_issuer}}
- **Client ID:** {{oidc_client_id}}

**Jenkins Limitation:** AWS STS uses Kubernetes service account tokens and requires
pods running in an EKS cluster with IAM roles for service accounts (IRSA) configured.

**Recommended Approach:**
1. **If Jenkins runs on EKS:** Configure Jenkins pod service accounts and refer to
   the RHTAS Deployment Guide section on "Signing with Amazon STS."

2. **If Jenkins runs elsewhere:** Configure Keycloak or Red Hat SSO as an additional
   OIDC issuer for Jenkins-based signing.

GitLab (Native OIDC):

## ⚠️ GitLab Native OIDC Detected

Your RHTAS deployment is configured with GitLab native OIDC:
- **Issuer:** {{oidc_issuer}}
- **Client ID:** {{oidc_client_id}}

**Jenkins Limitation:** Jenkins does not provide native integration with GitLab OIDC.
GitLab OIDC tokens (`id_tokens` keyword) are only available within GitLab CI pipelines.

**Recommended Approach:**
1. **Option A (Recommended):** Configure Keycloak or Red Hat SSO as an additional
   OIDC issuer in Fulcio for Jenkins-based signing.

2. **Option B:** Perform signing within GitLab CI pipelines instead of Jenkins.
   Refer to the RHTAS Deployment Guide section on "Signing with GitLab CI."

Generic OIDC Provider:

## ⚠️ Generic OIDC Provider Detected

Your RHTAS deployment is configured with a custom OIDC provider:
- **Issuer:** {{oidc_issuer}}
- **Client ID:** {{oidc_client_id}}

**Jenkins Integration:** Token acquisition depends on your OIDC provider's
supported grant types. Jenkins requires programmatic token access (non-interactive).

**Recommended Approaches:**
1. Check if your OIDC provider supports `client_credentials` grant (service accounts)
   or `password` grant (resource owner credentials).

2. Consult your OIDC provider's documentation for CI/CD integration patterns.

3. For enterprise Jenkins deployments, consider using Keycloak or Red Hat SSO, which
   provide well-tested CI/CD integration patterns and can federate to your existing
   identity provider.

Refer to the RHTAS Deployment Guide section on "Configuring custom OIDC issuers."

Substitute detected endpoint URLs for environment variable references when known. Keep variable references when endpoints are not detected so the user can configure them manually.

8c — Gaps Data

Include the evaluated gap results from Step 6 as the gaps array.

8d — Endpoints Data

Include the discovered endpoints from Step 5 as the endpoints object.

Step 9 — Present for Review

Display a summary to the user for review before exporting the blueprint:

## Scan Summary

| Field | Value |
|-------|-------|
| Jenkins URL | {{jenkins_url}} |
| Jenkins Version | {{jenkins_version}} |
| Java Version | {{java_version}} |
| Plugins Scanned | {{total_plugins}} |
| Pipelines Scanned | {{total_pipelines}} |
| TAS Deployment | {{deployment_method}} or Not detected |

## Confidence Scores

| Category | Score | Details |
|----------|-------|---------|
| Overall | {{overall_confidence}} | {{overall_details}} |
| Detection | {{detection_confidence}} | {{detection_details}} |
| Compatibility | {{compatibility_confidence}} | {{compatibility_details}} |

## Gap Summary

- **Passed:** X rules
- **Failed:** Y rules
- **Skipped:** Z rules
- **Critical gaps:** list of failing critical rule IDs or "None"

## Detected Endpoints

| Component | URL | Status |
|-----------|-----|--------|
| Fulcio | {{fulcio_url}} or Not detected | Healthy / Unreachable / — |
| Rekor | {{rekor_url}} or Not detected | Healthy / Unreachable / — |
| TSA | {{tsa_url}} or Not detected | Healthy / Unreachable / — |
| TUF | {{tuf_url}} or Not detected | Healthy / Unreachable / — |

Prompt the user:

"Review the scan results above. Would you like to proceed with blueprint generation, adjust any findings, or re-scan with different parameters?"

Wait for confirmation before proceeding to Step 10.

Step 10 — Export Blueprint

Call export-blueprint with the assembled blueprint data from Step 8 and the user's output parameters:

/tas-integrator:export-blueprint --output={{output}} --format={{format}}

Blueprint data:
- header: (assembled in Step 8a)
- platform: (assembled in Step 8b)
- gaps: (assembled in Step 8c)
- endpoints: (assembled in Step 8d)

Let export-blueprint handle template rendering, gap assessment summary, validation command summary, metadata block, and output formatting.

Jenkins API Reference

Send GET requests with the /api/json suffix for JSON responses.

Filter fields with the tree query parameter:

GET /api/json?tree=jobs[name,url,color]

Knowledge Base References

Read these knowledge-base files during scanning:

Error Handling

Examples

Basic Scan (Display Only)

Run a scan and display results in the conversation:

/tas-integrator:scan-jenkins

Jenkins URL: https://jenkins.example.com
Username: admin
Token: 11a2b3c4d5e6f7

Scan with TAS Namespace

Run a scan and auto-detect endpoints from the Securesign CR in the namespace:

/tas-integrator:scan-jenkins

Jenkins URL: https://jenkins.example.com
Username: admin
Token: 11a2b3c4d5e6f7
Namespace: trusted-artifact-signer

Scan with Explicit Endpoints and YAML Save

Override endpoint URLs and write the blueprint as YAML:

/tas-integrator:scan-jenkins --output=save --format=yaml

Jenkins URL: https://jenkins.example.com
Username: admin
Token: 11a2b3c4d5e6f7
Rekor URL: https://rekor.tas.example.com
Fulcio URL: https://fulcio.tas.example.com
TUF URL: https://tuf.tas.example.com

Scan with Display and Save

Display the blueprint and save it to a custom output path:

/tas-integrator:scan-jenkins --output=both --output_path=./reports/jenkins-scan.md

Jenkins URL: https://jenkins.example.com
Username: admin
Token: 11a2b3c4d5e6f7
Namespace: trusted-artifact-signer