The number one objection to adding compliance checks in CI/CD is speed. Engineering teams that deploy ten times a day are not going to wait 30 minutes for a full compliance validation on every push. They should not have to.
Here is how to build meaningful compliance validation into your pipeline without turning your deploys into a bottleneck.
The two-tier approach
Split your compliance validation into two categories: fast checks that run on every commit, and comprehensive validations that run on a schedule or before releases.
Tier 1: Pipeline checks (under 2 minutes). These run on every PR or merge request. They cover configuration policy validation, infrastructure-as-code compliance checks, and secret detection. The goal is catching compliance drift and policy violations before they reach staging.
Tier 2: Scheduled comprehensive validations (15-45 minutes). These run nightly or before each release. Full framework validation, evidence collection, cloud posture assessment, and audit report generation. Results feed into your compliance dashboard and ticketing system.
GitHub Actions setup
Add the SecTests action to your workflow file. The --quick flag runs Tier 1 checks:
- name: Compliance check
uses: sectests/action@v2
with:
target: ${{ secrets.STAGING_URL }}
api-key: ${{ secrets.SECTESTS_API_KEY }}
mode: quick
fail-on: critical
The action pulls a lightweight Docker image, runs compliance validation against your staging environment, and posts results as a PR comment. If a critical policy violation is detected, the check fails and the merge is blocked.
GitLab CI setup
Add a compliance stage to your .gitlab-ci.yml. The validator runs in a Docker container:
compliance_check:
stage: test
image: sectests/validator:latest
script:
- sectests validate --target $STAGING_URL --mode quick --fail-on critical
artifacts:
reports:
junit: sectests-results.xml
The JUnit XML output integrates with GitLab's test reporting UI. Compliance findings appear alongside your unit test results.
Jenkins setup
Install the SecTests Jenkins plugin from the plugin marketplace. Add a build step with your target URL and API key. The plugin supports both freestyle and pipeline jobs. For pipeline scripts, use the sectests step:
stage('Compliance') {
steps {
sectests target: env.STAGING_URL, mode: 'quick', failOn: 'critical'
}
}
What to fail on
This is the question every team debates. Our recommendation:
- Pipeline checks (Tier 1): Fail on critical policy violations only. Non-critical findings generate warnings but do not block. This keeps deploys moving while catching compliance-breaking changes.
- Release validations (Tier 2): Fail on critical and high-priority findings. These run less frequently, so the team has time to investigate and remediate before the next release.
Avoid failing on low-priority findings in CI. It trains developers to ignore compliance checks or find workarounds. Start strict on critical issues and expand the threshold as your team matures.
Performance impact
Tier 1 checks with the --quick flag typically complete in 45 to 90 seconds. They run in parallel with your other CI steps, so the added wall-clock time is often zero if your test suite takes longer than that.
If even that is too slow, use the --diff flag to validate only configurations that changed in the current commit. This reduces check time to 10-20 seconds on most PRs.
Compliance validation in CI/CD is not about checking every control on every commit. It is about establishing a baseline, catching compliance drift, and making sure policy violations never reach production. Start with Tier 1 on your next PR.