Skip to content

Back to the catalog

LocxZ/SecureSDLC-Lab
github.comrepo

LocxZ/SecureSDLC-Lab

SecureSDLC-Lab pairs a minimal Node.js/Express/SQLite app with a GitHub Actions pipeline running Gitleaks (secret scanning), Semgrep (SAST), and Trivy (dependency, Docker image, and Kubernetes manifest scanning) plus OWASP ZAP (DAST) on every push and PR. It documents concrete remediations applied during the exercise: bcrypt password hashing, parameterized SQL queries, session-based auth with post-login session regeneration and HttpOnly cookies, RBAC for an admin page, Helmet security headers, env-based secrets, and a hardened Kubernetes deployment (non-root, readOnlyRootFilesystem, dropped capabilities, seccomp, resource limits) alongside a STRIDE threat model.

TL;DR A learning-lab repo showing a full Secure SDLC pipeline (Gitleaks, Semgrep, Trivy, OWASP ZAP in GitHub Actions) fixing real vulns in a toy Node.js app.
Open original ↗
Document

What it is

SecureSDLC-Lab (LocxZ) is a learning project that wires security scanning into a GitHub Actions pipeline around a deliberately simple Node.js, Express and SQLite app. The author says the goal was to learn how to automate checks in CI/CD and fix issues before merge, not to build a product. The page states that every push and pull request runs six checks, and that a PR should pass all of them before merging:

  • Gitleaks secret scan
  • Semgrep SAST
  • Trivy dependency scan
  • Trivy Docker image scan
  • Trivy Docker and Kubernetes config scan
  • OWASP ZAP DAST

What to do

To run the app locally:

git clone https://github.com/LocxZ/SecureSDLC-Lab.git
npm install
export SESSION_SECRET=my-secret
node app.js

The app then listens at http://localhost:3000. The session secret is read from the environment, so the app needs SESSION_SECRET set before it starts.

The README publishes two seeded accounts: admin / admin123 and user / user123. The admin account is the one for checking the RBAC-protected admin page.

Caveats

The author states the project is not production-ready. The list of things to add later shows what is missing from the current app:

  • Rate limiting
  • CSRF protection
  • A Redis session store
  • Persistent storage for Kubernetes
  • Terraform
  • Helm

The app therefore has no CSRF protection or login throttling, even though it uses session cookies and a password login. The seeded passwords are trivially guessable and appear in the README, and the example secret is a placeholder.

The page lists the tools and remediations but gives no workflow configuration, scan findings, severity thresholds or example results. It does not say whether any scanner is set to fail the build on a given severity.

Technologies named here

Techniques named here

Related in DevSecOps