CDP Pipeline Failures & Best Practices for DefectDojo Integration

When working with the pipelines, you’ll often encounter jobs that are expected to “fail” when they detect security issues. Understanding why certain jobs can be allowed to fail—and how to handle scan results in DefectDojo—helps you keep your pipeline efficient, your reports clean, and your compliance posture strong. This article walks through the rationale behind permissive‑failure settings for specific CDP jobs and offers guidance on what scan data should be sent to DefectDojo.

Table of Contents

1. Why Some Jobs May Be Allowed to Fail

2. Configuring “Allow Failure” for Specific Jobs

3. DefectDojo Integration: What to Send and What to Exclude

4. Practical Example: End‑to‑End Pipeline Setup

5. Tips & Common Questions

Why Some Jobs May Be Allowed to Fail

1. Jobs Designed to Surface Vulnerabilities

• sast-with-vm – Runs static application security testing (SAST) inside a virtual machine. A failure indicates that the scanner discovered one or more code‑level vulnerabilities.

• sca-frontend – Executes software component analysis (SCA) on front‑end dependencies. A failing status means vulnerable libraries were found.

These jobs are intentional gatekeepers. Treating a failure as a hard pipeline break would stop the build even when the only issue is a newly discovered vulnerability that you may want to triage first.

2. Jobs That Should Remain Strict

• sslscan – Checks TLS configurations. A failure usually points to misconfigurations that could expose data in transit.

• ansible-hardening & inspec – Enforce hardening standards and compliance checks. Failures here often indicate non‑compliant infrastructure that must be remediated before proceeding.

Bottom line: Only allow failure on jobs whose primary purpose is to report findings, not to enforce mandatory compliance.

Configuring “Allow Failure” for Specific Jobs

1. Open the .gitlab-ci.yml (or equivalent) file in your repository.

2. Locate the job definitions for sast-with-vm and sca-frontend.

3. Add the allow_failure: true flag:

sast-with-vm:
  stage: test
  script:
    - ./run-sast.sh
  allow_failure: true   # <-- permits the job to fail without breaking the pipeline

sca-frontend:
  stage: test
  script:
    - ./run-sca.sh
  allow_failure: true   # <-- same rationale as above

1. Commit and push the changes. The pipeline will now continue even if these jobs report vulnerabilities, while still publishing the findings for review.

Note: Keep allow_failure off for jobs like sslscan, ansible-hardening, and inspec to ensure that critical security misconfigurations halt the pipeline.

DefectDojo Integration: What to Send and What to Exclude

DefectDojo is a powerful vulnerability management platform, but it expects certain formats and scan types. Sending only relevant results avoids clutter and improves triage speed.

What to Send

What to Exclude

How to Push Findings to DefectDojo

1. Export the scan results in a supported format (e.g., SARIF, JUnit XML, JSON).

2. Use the DefectDojo API or the built‑in CI integration:

curl -X POST "https://defectdojo.example.com/api/v2/import-scan/" \
     -H "Authorization: Token <YOUR_API_TOKEN>" \
     -F "scan_type=SAST" \
     -F "file=@sast-results.sarif" \
     -F "engagement=123" \
     -F "product_name=MyApp"

1. Verify the import in the DefectDojo UI and assign findings to the appropriate remediation sprint.

Practical Example: End‑to‑End Pipeline Setup

Below is a simplified snippet that ties everything together:

stages:
  - test
  - report
  - upload

sast-with-vm:
  stage: test
  script: ./run-sast.sh
  allow_failure: true
  artifacts:
    paths: [sast-results.sarif]

sca-frontend:
  stage: test
  script: ./run-sca.sh
  allow_failure: true
  artifacts:
    paths: [sca-results.json]

sslscan:
  stage: test
  script: ./run-sslscan.sh
  # No allow_failure – must pass

defectdojo-upload:
  stage: upload
  script:
    - ./upload-to-defectdojo.sh sast-results.sarif SAST
    - ./upload-to-defectdojo.sh sca-results.json SCA
  dependencies: [sast-with-vm, sca-frontend]
  only:
    - main

• allow_failure: true ensures the pipeline proceeds even when vulnerabilities are found.

• The final defectdojo-upload job sends only the relevant scans to DefectDojo.

Tips & Common Questions

✅ Tips for a Smooth Integration

• Standardize output formats across all security tools (prefer SARIF or JSON).

• Tag each upload with the pipeline ID or commit SHA to maintain traceability.

• Run a dry‑run of the DefectDojo import script locally before committing to CI.

❓ Common Questions

Bottom Line

Allowing failure for sast-with-vm and sca-frontend is intentional—these jobs are meant to surface vulnerabilities without halting the build. Conversely, keep strict enforcement on compliance‑oriented jobs. When integrating with DefectDojo, send only the scans it can parse (SAST, SCA, dynamic tests) and omit hardening or compliance outputs. Following these practices will keep your CDP pipelines lean, your security reporting accurate, and your remediation workflow efficient.