I built this project to practice DevSecOps pipeline security using GitLab CI/CD and open-source security tools.
The goal was to create a small demo application, add security checks to the CI/CD pipeline, collect real evidence, and document the results in a clear way.
This project shows how I integrated security checks into a pipeline for:
SAST
secret scanning
dependency scanning
container image scanning
security gate observation
evidence-based reporting
The project uses a safe local/demo Node.js application. It does not scan external targets, third-party systems, real company code, or real production data.
GitHub repository:
https://github.com/gfmcorrea/devsecops-gitlab-pipeline-security
GitLab CI/CD project:
https://gitlab.com/gfmcorrea/devsecops-gitlab-pipeline-security
I built this project to practice how security tools can be added to a CI/CD workflow.
I wanted to understand how a DevSecOps pipeline works from start to finish:
create a demo app
add a GitLab CI/CD pipeline
run security tools
save scan reports as artifacts
review findings
document evidence
explain remediation
This project helped me practice both technical security testing and documentation.
The demo application is a simple Node.js and Express app located in:
app/
Main files:
app/server.js
app/package.json
app/package-lock.json
app/Dockerfile
app/.dockerignore
The app includes controlled demo issues for security validation:
A demo-only insecure code pattern for SAST
A fake API key for secret scanning
Vulnerable dependencies for dependency scanning
A Docker image for container scanning
The fake secret is not real and must never be used in production.
The project was built and tested using:
Ubuntu
Git
GitHub
GitLab CI/CD
Docker
Node.js
npm
Semgrep
Gitleaks
npm audit
Trivy
Markdown
Semgrep:
Used for static application security testing.
Gitleaks:
Used for secret scanning.
npm audit:
Used for dependency scanning.
Docker:
Used to build the demo application container image.
Trivy:
Used to scan the container image for known vulnerabilities.
GitLab CI/CD:
Used to automate the security pipeline.
The GitLab CI/CD pipeline includes these stages:
setup
sast
secret_scan
dependency_scan
container_build
container_scan
report_summary
The pipeline was executed successfully in GitLab CI/CD.
Final result:
Status: Passed
Jobs: 7
Branch: main
Pipeline source: web
Jobs executed:
setup: passed
sast: passed
secret_scan: passed
dependency_scan: passed
container_build: passed
container_scan: passed
report_summary: passed
Evidence:
evidence/screenshots/pipeline/06-gitlab-all-jobs-passed.png
evidence/tool-outputs/24-final-pipeline-summary.txt
Status:
Confirmed
Severity:
Medium
Tool:
Semgrep
Summary:
Semgrep detected user-controlled request data flowing into eval() in app/server.js.
Evidence:
findings/01-sast-insecure-code-pattern.md
evidence/reports/semgrep/
evidence/screenshots/sast/
Status:
Confirmed
Severity:
Medium
Tool:
Gitleaks
Summary:
Gitleaks detected a demo-only fake API key pattern in app/server.js.
The output was redacted.
Evidence:
findings/02-secret-detection-fake-secret.md
evidence/reports/gitleaks/
evidence/screenshots/secret-scanning/
Status:
Confirmed
Severity:
High
Tool:
npm audit
Summary:
npm audit found 8 vulnerabilities in the demo application dependencies.
Observed summary:
Low: 3
Moderate: 1
High: 4
Critical: 0
Total: 8
Evidence:
findings/03-vulnerable-dependency.md
evidence/reports/dependency-check/
evidence/screenshots/dependency-scanning/
Status:
Confirmed
Severity:
Critical
Tool:
Trivy
Summary:
Trivy found vulnerabilities in the demo container image.
Observed summary:
Low: 1478
Medium: 3161
High: 1176
Critical: 197
Total: 6012
Evidence:
findings/04-container-image-vulnerabilities.md
evidence/reports/trivy/
evidence/screenshots/container-scanning/
Status:
Confirmed
Severity:
Informational
Tool:
GitLab CI/CD
Summary:
The pipeline used allow_failure for learning-focused security scan jobs.
The jobs still generated evidence and artifacts for manual review.
Evidence:
findings/05-security-gate-observation.md
evidence/tool-outputs/24-final-pipeline-summary.txt
evidence/tool-outputs/25-final-findings-summary.txt
I saved evidence in:
evidence/
Main evidence folders:
evidence/reports/
evidence/screenshots/
evidence/tool-outputs/
Before publishing evidence, I reviewed the outputs to avoid exposing real secrets or sensitive data.
The Gitleaks outputs use redacted secret values.
The Trivy reports include vulnerability descriptions and CVE information.
Exported Docker image tar files were not committed to the repository.
Go to the app folder:
cd appInstall dependencies:
npm installRun the app:
npm startTest the app:
curl -i http://localhost:3000/
curl -i http://localhost:3000/healthFrom the project root:
docker build -t devsecops-demo-app:local appRun the container:
docker run --rm -d --name devsecops-demo-app-test -p 3001:3000 devsecops-demo-app:localTest the container:
curl -i http://localhost:3001/
curl -i http://localhost:3001/healthStop the container:
docker stop devsecops-demo-app-testThe pipeline is defined in:
.gitlab-ci.yml
To run it in GitLab:
Open the GitLab project
Go to Build > Pipelines
Click New pipeline
Select branch main
Run the pipeline
The pipeline supports manual runs from the GitLab UI using:
- if: '$CI_PIPELINE_SOURCE == "web"'devsecops-gitlab-pipeline-security/
├── app
├── appendices
├── docs
├── evidence
├── findings
├── lessons-learned
├── methodology
├── pipeline
├── remediation
├── reports
└── scope
app:
Demo Node.js application and Dockerfile.
pipeline:
Pipeline documentation and security scanning stages.
findings:
Confirmed findings and security observations.
evidence:
Screenshots, scan reports, CI artifacts, and tool outputs.
reports:
Final project report.
remediation:
Remediation guidance for the identified issues.
lessons-learned:
What I learned while building the project.
This project demonstrates practical experience with:
GitLab CI/CD
DevSecOps pipeline design
SAST
secret scanning
dependency scanning
container scanning
Docker
security artifacts
security gates
evidence-based reporting
technical documentation
Git and GitHub workflow
I learned how to build a simple security pipeline and validate each step with real evidence.
I also learned that security tools need review and tuning. Not every finding should automatically break a pipeline, especially during early adoption or in a learning project.
The most important lesson was that a DevSecOps pipeline is not only about running tools. It is also about collecting evidence, reviewing results, documenting findings, and improving the workflow over time.
This project was created for learning and portfolio purposes.
The application is a safe local demo app.
This project does not include:
real secrets
real company code
real customer data
malware
phishing
persistence
evasion
destructive actions
external target scanning
third-party system testing
All testing was performed against a controlled demo application created for this project.