DevSecOps Pipeline with SonarQube, OWASP ZAP and Nuclei

The problem: security controls drift between repositories

Security pipelines are often assembled independently in every repository. One application blocks a pull request on critical findings, another only uploads a report, and a third has no quality gate at all. Scanner configuration drifts, developers receive inconsistent feedback, and audit evidence becomes difficult to compare.

This blueprint treats application security as a shared delivery capability. Repositories consume one reusable workflow while application-specific values—URLs, exclusions, authentication, and risk acceptance—remain explicit inputs.

Pipeline architecture

The pipeline separates fast pull-request feedback from deeper runtime testing:

1. Build and unit tests establish whether the application is structurally ready for analysis.
2. SonarQube evaluates maintainability, reliability, security hotspots, duplication, and coverage on new code.
3. The quality gate prevents promotion when the agreed policy is not met.
4. A deployable preview or test environment becomes the target for OWASP ZAP and Nuclei.
5. Findings are normalized into consistent severity and policy outcomes.
6. Pull-request summaries and retained artifacts provide feedback to engineers and evidence for review.

SonarQube quality gate

SonarQube is positioned before DAST because it can give developers feedback while the code context is still fresh. The gate focuses on new code instead of forcing teams to remediate every historical issue before improving current delivery.

Typical gate inputs include new vulnerabilities, security-review status, maintainability rating, duplication, and coverage. Thresholds remain organization-owned policy rather than hard-coded scanner defaults.

Dynamic security testing

OWASP ZAP provides web application crawling and active testing. Nuclei complements it with template-driven checks for exposed services, known misconfiguration, and technology-specific weaknesses. Running both behind one contract prevents every repository from inventing its own invocation, report format, and failure rules.

The workflow distinguishes scanner execution failure from a genuine security finding. That difference matters operationally: an unreachable target needs pipeline troubleshooting, while a confirmed vulnerability needs triage and remediation.

Policy and evidence

Normalized findings can be evaluated into PASS, WARN, and FAIL outcomes. Critical exploitable findings may block promotion, accepted risk can be documented with an expiry, and lower-severity observations remain visible without creating permanent pipeline fatigue.

Each run retains machine-readable reports, a concise pull-request summary, scanner versions, target context, and the final policy decision. This makes the pipeline useful for developers, security review, and later audit evidence.

For the surrounding supply-chain control, see the guide to scanning dependency CVEs with Syft and Grype and the notes on designing audit evidence early.

Operational value

• one maintained security workflow instead of duplicated scanner YAML
• fast quality feedback before expensive runtime tests
• consistent security policy across participating applications
• clear separation between pipeline errors and security findings
• audit-ready artifacts tied to the commit and workflow run
• an adoption path that can begin in warning mode before enforcement