In this article, I walk through how I implemented an end-to-end DevSecOps pipeline using Jenkins, Gitleaks, and Trivy, and integrated the results into GitHub through Pull Request comments, commit status checks, and security reporting.<\/p>\n
Architecture Overview<\/h2>\n
The workflow is designed as follows:<\/p>\n
![\"\"](\"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2026\/08\/Flow-chart-1024x512.png\")
<\/p>\n
This setup enables:<\/p>\n
- \n
- Automated security scanning during CI<\/li>\n
- Visibility directly in Pull Requests<\/li>\n
- Structured reporting and feedback for developers<\/li>\n<\/ul>\n
Tools Used<\/h2>\n
- \n
- Jenkins (CI\/CD orchestration)<\/li>\n
- Gitleaks (secret detection)<\/li>\n
- Trivy (vulnerability scanning)<\/li>\n
- GitHub CLI (
gh<\/code>) for API interaction<\/li>\n- Jenkins HTML Publisher Plugin (for report visualization)<\/li>\n<\/ul>\n
\nAlso Read: Jenkins Alternatives in 2026<\/a><\/p>\n<\/div>\n
<\/p>\n
Pipeline Workflow<\/h2>\n
The pipeline is structured into the following stages:<\/p>\n
- \n
- Checkout source code from GitHub<\/li>\n
- Run Gitleaks for secret detection<\/li>\n
- Run Trivy for vulnerability scanning<\/li>\n
- Generate reports in JSON, SARIF, and HTML formats<\/li>\n
- Publish HTML reports in Jenkins UI<\/li>\n
- Create a summarized Pull Request comment<\/li>\n
- Upload SARIF reports for GitHub security<\/a> visibility<\/li>\n
- Update commit status based on scan results<\/li>\n<\/ol>\n
<\/p>\n
![\"\"](\"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2026\/08\/image-77-1024x231.png\")
<\/p>\nKey Features Implemented<\/h2>\n
- \n
- Secret scanning using Gitleaks<\/li>\n
- Vulnerability scanning using Trivy<\/li>\n
- HTML reports accessible within Jenkins<\/li>\n
- Automated Pull Request comments with scan summaries<\/li>\n
- Commit status checks indicating success or failure<\/li>\n
- Integration with GitHub security reporting using SARIF<\/li>\n<\/ul>\n
<\/p>\n
Challenges and Solutions<\/h2>\n
This implementation involved several practical challenges.<\/p>\n
1. Jenkins Detached HEAD Issue<\/h3>\n
Jenkins<\/a> checks out code in detached HEAD mode, which prevents direct branch detection.<\/p>\n
Problem:<\/strong><\/p>\n
<\/p>\n
\ngit rev-parse --abbrev-ref HEAD \u2192 HEAD<\/code><\/pre>\n<\/div>\nSolution:<\/strong><\/p>\n
The default branch was dynamically extracted using:<\/p>\n
<\/p>\n
\ngit remote show origin | grep 'HEAD branch'<\/code><\/pre>\n<\/div>\n2. SARIF Upload Failure<\/h3>\n
Initial attempts to upload SARIF reports to GitHub resulted in API errors.<\/p>\n
Root cause:<\/strong><\/p>\n
The GitHub API expects SARIF data to be compressed and encoded.<\/p>\n
Solution:<\/strong><\/p>\n
- \n
- SARIF files were compressed using gzip<\/li>\n
- Encoded using base64<\/li>\n
- Uploaded using GitHub API<\/a><\/li>\n<\/ul>\n
3. Missing commit_sha and ref<\/h3>\n
The SARIF upload API requires explicit commit and branch references.<\/p>\n
Solution:<\/strong><\/p>\n
<\/p>\n
\ncommit_sha = $GIT_COMMIT\r\nref = refs\/heads\/<branch><\/code><\/pre>\n<\/div>\n4. Private Repository Limitation<\/h3>\n
SARIF uploads failed when using private repositories or restricted organizational environments.<\/p>\n
Learning:<\/strong><\/p>\n
GitHub security reporting using SARIF is not always available in private repositories or organization-level setups without additional configuration or subscription.<\/p>\n
Working with Private and Organization Repositories<\/h2>\n
While full SARIF-based integration works smoothly with public repositories, limitations arise when working with private repositories or organization environments.<\/p>\n
In such scenarios, direct integration with the GitHub Security dashboard may not be available.<\/p>\n
Temporary Workaround<\/h3>\n
To maintain visibility without relying on platform-specific features, an alternative approach was implemented:<\/p>\n
- \n
- Security scan results were summarized and posted as Pull Request comments<\/li>\n
- Commit status checks were updated based on scan outcomes<\/li>\n
- Jenkins HTML reports provided detailed insights<\/li>\n<\/ul>\n
This ensured that:<\/p>\n
- \n
- Developers continued to receive immediate feedback in Pull Requests<\/li>\n
- Security issues remained visible during code reviews<\/li>\n
- The workflow maintained enforcement of security checks<\/li>\n<\/ul>\n
Although this approach does not provide native dashboard-level visibility, it serves as a practical and effective solution in constrained environments.<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2026\/08\/image-79-1024x440.png\")
<\/p>\nFinal Output<\/h2>\n
After successful pipeline execution:<\/p>\n
Jenkins<\/h3>\n
- \n
- HTML reports for Trivy and Gitleaks<\/li>\n
- Centralized visibility of scan results<\/li>\n<\/ul>\n
GitHub Pull Request<\/h3>\n
- \n
- Automated comments summarizing findings<\/li>\n
- Commit status indicating pass or failure<\/li>\n<\/ul>\n
GitHub Security Visibility<\/h3>\n
- \n
- Structured security reporting using SARIF (where supported)<\/li>\n<\/ul>\n
<\/p>\n
![\"\"](\"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2026\/08\/image-80-1024x513.png\")
<\/p>\nCost Comparison<\/h2>\n
\n
- Structured security reporting using SARIF (where supported)<\/li>\n<\/ul>\n
- Update commit status based on scan results<\/li>\n<\/ol>\n
- Jenkins HTML Publisher Plugin (for report visualization)<\/li>\n<\/ul>\n