CI/CD Setup

PrismSec integrates seamlessly into your CI/CD pipeline, running security scans on every pull request and commit. You can configure PrismSec to block merges if critical vulnerabilities are detected, ensuring that only secure code reaches production.

How CI/CD Integration Works

When PrismSec is integrated into your CI/CD pipeline:

1. Trigger — A pull request or commit triggers your CI workflow
2. Scan — PrismSec analyzes the changed files for vulnerabilities
3. Status check — PrismSec posts a commit status (Pass/Fail) based on your configured severity threshold
4. Block or allow — If the status is "Fail," the merge is blocked (if branch protection is enabled)

GitHub Actions

PrismSec automatically posts commit statuses for pull requests in GitHub. To enforce blocking:

1. Enable Branch Protection

1. Go to your repository Settings → Branches
2. Add a branch protection rule for main (or your default branch)
3. Enable Require status checks to pass before merging
4. Select PrismSec from the list of required status checks

2. Optional: Run PrismSec Explicitly

If you want to run PrismSec as a workflow step (in addition to the automatic PR scans):

# .github/workflows/security.yml
name: Security Scan
 
on:
  pull_request:
  push:
    branches: [main, develop]
 
jobs:
  prismsec:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Run PrismSec Scan
        uses: prismsec/action@v1
        with:
          api_key: ${{ secrets.PRISMSEC_API_KEY }}
          fail_on_severity: high  # Fail if High or Critical findings

3. Get an API Key

1. Go to the PrismSec dashboard
2. Navigate to Settings → API Keys
3. Click Generate New Key and copy it
4. In your GitHub repository, go to Settings → Secrets and variables → Actions
5. Add a new secret named PRISMSEC_API_KEY with the copied key

GitLab CI

Add a PrismSec job to your .gitlab-ci.yml:

# .gitlab-ci.yml
stages:
  - test
  - security
 
prismsec:
  stage: security
  image: prismsec/cli:latest
  script:
    - prismsec scan --api-key $PRISMSEC_API_KEY --fail-on high
  only:
    - merge_requests
    - main
    - develop
  allow_failure: false  # Block pipeline if scan fails

Set the API Key

1. Go to your GitLab project Settings → CI/CD → Variables
2. Add a new variable:
   • Key: PRISMSEC_API_KEY
   • Value: Your API key from the PrismSec dashboard
   • Flags: Check "Mask variable" and "Protect variable"

Enforce Merge Blocking

1. Go to Settings → Merge requests
2. Enable Pipelines must succeed under merge checks
3. PrismSec failures will now block merges

Bitbucket Pipelines

Add a PrismSec step to your bitbucket-pipelines.yml:

# bitbucket-pipelines.yml
pipelines:
  pull-requests:
    '**':
      - step:
          name: Security Scan
          image: prismsec/cli:latest
          script:
            - prismsec scan --api-key $PRISMSEC_API_KEY --fail-on high
  
  branches:
    main:
      - step:
          name: Security Scan
          image: prismsec/cli:latest
          script:
            - prismsec scan --api-key $PRISMSEC_API_KEY --fail-on high

Set the API Key

1. Go to Repository settings → Pipelines → Repository variables
2. Add a new variable:
   • Name: PRISMSEC_API_KEY
   • Value: Your API key from the PrismSec dashboard
   • Secured: Yes

Configuring Severity Thresholds

You can configure when PrismSec fails the CI build:

Option 1: Config File

Add a severity threshold to prismsec.yml:

# prismsec.yml
severity_threshold: high

Options:

• critical — Only fail on Critical findings
• high — Fail on Critical or High findings
• medium — Fail on Critical, High, or Medium findings
• low — Fail on any finding

Option 2: CLI Flag

Pass the threshold as a flag:

prismsec scan --fail-on high

Option 3: Branch-Specific Thresholds

Apply stricter thresholds to production branches:

# prismsec.yml
branches:
  main:
    severity_threshold: low    # Strict: fail on any finding
    block_on_findings: true
  
  develop:
    severity_threshold: high   # Lenient: fail only on Critical/High
    block_on_findings: false

Handling Scan Failures

When a scan fails in CI, you have three options:

1. Fix the Vulnerability

The recommended approach:

1. Review the finding in the PrismSec dashboard or PR comment
2. Fix the vulnerability (or merge an auto-fix PR)
3. Re-run the CI pipeline — the scan will now pass

2. Ignore the Finding

If the finding is a false positive or accepted risk:

1. Mark it as Ignored in the PrismSec dashboard (with justification)
2. Re-run the CI pipeline — ignored findings do not fail the build

See Triage & Ignoring for details.

3. Bypass the Check (Emergency Only)

If you must merge urgently (e.g., hotfix for a production outage):

1. Temporarily disable the required status check in branch protection settings
2. Merge the PR
3. Immediately re-enable the status check and create a follow-up PR to fix the vulnerability

Scanning Frequency

PrismSec scans run:

• On every pull request — Automatically, when you connect your repository
• On push to protected branches — Optional, configure in CI/CD
• On a schedule — Optional, configure in the PrismSec dashboard (e.g., daily scans to catch newly disclosed CVEs)

Performance Considerations

PrismSec scans are fast:

• Average scan time: 30–60 seconds for most pull requests
• Parallel execution: Scans run concurrently with tests, linting, and builds
• Incremental analysis: Only changed files are scanned in PRs

For large monorepos or PRs with many changed files, scans may take 2-3 minutes but rarely exceed that.

Viewing Scan Results

Scan results appear in three places:

1. Commit status — Pass/Fail indicator on the PR
2. PR comments — Inline findings on specific lines of code
3. PrismSec dashboard — Full findings list with filtering and search

Best Practices

• Fail on High and Critical — Use severity_threshold: high to catch serious vulnerabilities without blocking on low-risk issues
• Stricter for production branches — Apply severity_threshold: low to main or production branches
• Automate fixes — Enable auto-fix PRs to reduce manual remediation work
• Monitor trends — Use the dashboard to track security improvements over time

Next Steps

• Integrate with Slack: Slack
• Understand severity levels: Severity & Risk Score
• Configure scan behavior: Configuring Scans