Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.pipefort.com/llms.txt

Use this file to discover all available pages before exploring further.

FieldValue
CategoryCICD-SEC-10
SeverityLOW
OWASPCICD-SEC-10: Insufficient Logging and Visibility
Auto-fix✗

​
What the check does

Flags any job that declares continue-on-error: true at the job level (not the step level). Only a literal true (or "true") is flagged — values driven by an expression (${{ ... }}) are intentionally dynamic and left alone. Step-level continue-on-error: true is fine: it scopes failure-suppression to one step, the job still fails if other steps fail, and the run’s conclusion correctly reflects the failure.

​
Why it matters

continue-on-error: true at the job level changes the job’s reported conclusion from failure to success whenever its steps fail. The downstream consequences are not just cosmetic:
  • Branch-protection required checks see green and let the merge through.
  • if: success() and needs: dependents treat the job as having passed, so downstream jobs run on broken state.
  • Audit dashboards (GitHub’s Actions overview, status badges, third-party CI heat-maps) record the run as passing — the failure leaves no breadcrumb anyone is monitoring.
  • Incident review later sees a green run and has nothing to correlate against the actual breakage.
The pattern almost always reflects “this job is flaky and I want CI to stop bothering me about it” — which is exactly the visibility loss CICD-SEC-10 is about.

​
Vulnerable example

jobs:
  flaky-integration:
    runs-on: ubuntu-latest
    continue-on-error: true       # ← whole-job failure is hidden
    steps:
      - run: ./run-integration-suite.sh

​
Safe alternatives

If a single step is expected to fail, scope it there: 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: ./run-integration-suite.sh
        continue-on-error: true   # ← only this step's failure is absorbed
        id: tests
      - if: steps.tests.outcome == 'failure'
        run: echo "::warning::integration suite reported failure"
If the job is genuinely advisory (not a gate), mark it as such in branch protection rather than hiding the failure — exclude the check from “required status checks” in repo settings, and leave the job’s conclusion honest so dashboards see the real signal.