The goal of this project was to explore key DevSecOps tools and practices by testing SAST, DAST, SCA, and Git workflows. The exercises were conducted in a controlled lab environment to simulate real-world secure development practices.
- Ubuntu VM (VirtualBox): Host environment for DevSecOps tools and tests
- OWASP Juice Shop: Target vulnerable application for security testing
- Docker: Containerized deployment of testing tools (Horusec, OWASP ZAP, Snyk)
- GitLab: Version control and branching demonstrations
- Using SAST (Horusec) to identify code-level vulnerabilities
- Running DAST (OWASP ZAP) scans against live web applications
- Performing SCA (Snyk) dependency analysis on Node.js projects
- Managing branches, commits, and merges with Git/GitLab
- Understanding DevSecOps workflows for integrating security into the SDLC
- Horusec: Static code analysis
- OWASP ZAP: Dynamic application security testing
- Snyk: Software composition analysis
- Docker: Containerized testing
- OWASP Juice Shop: Vulnerable web app for demos
- Git & GitLab: Version control and branching
- Deploy Juice Shop as the vulnerable target application.
- Perform SAST with Horusec on Juice Shop’s source code.
- Run DAST with OWASP ZAP against the running Juice Shop app.
- Conduct SCA with Snyk on project dependencies.
- Demonstrate Git operations (branching, commits, merges) in GitLab.
- Document findings, flagged vulnerabilities, and remediation paths.
Short demo using SAST to analyse code from OWASP Juice Shop. The tool being used in this scenario is Horusec via a Docker image.
Prerequisite is to install Docker using apt repository https://docs.docker.com/engine/install/ubuntu/
Figure 1 – Installing OWASP Juice Shop inside the Ubuntu VM to provide a vulnerable target application for testing.
Figure 2 – Running Horusec via Docker, scanning the Juice Shop source code for vulnerabilities.
Figure 3 – Horusec analysis results showing identified security issues in the Juice Shop project.
Figure 4 – Navigating the Juice Shop repository to locate the vulnerable i18n assets directory flagged by Horusec.
Figure 5 – Opening the specific file where the critical vulnerability exists.
Figure 6 – Highlighting line 152 containing a hard-coded password, representing a critical security flaw.
Short demo using DAST. Testing a running web application (Juice Shop) with a Docker container (OWASP ZAP).
Figure 7 – Pulling the Juice Shop Docker image to run the application as a container.
Figure 8 – Starting the Juice Shop Docker container using default run commands.
Figure 9 – Verifying in a browser that Juice Shop is running locally on http://localhost:3000.
Figure 10 – Docker network configuration adjusted so Juice Shop listens on all interfaces (0.0.0.0), enabling access via VM IP.
Figure 11 – Running an automated OWASP ZAP scan against the Juice Shop application hosted at 10.0.2.15.
Figure 12 – OWASP ZAP scan summary: The scan completed with 0 new fails, 10 new warnings, and 56 passes. This indicates no critical failures, but 10 issues require review, such as missing security headers and other configuration weaknesses.
Figure 13 – OWASP ZAP identifies 10 warnings, available for review in the alert page.
Figure 14 – Example vulnerability list from OWASP ZAP showing unconfigured Content Security Policy (CSP).
Figure 15 – OWASP ZAP vulnerability details for CSP misconfiguration, including description, impact, and remediation.
Figure 16 – Browser developer tools confirm no CSP header is present in the HTTP response, validating ZAP’s findings.
Short demo using SCA tool Snyk to statically analyse the Juice Shop dependencies. These are listed in the package.json file which can be found in the frontend directory. The dependencies are then installed into a node_modules folder and analysed using Snyk (which again is run via a Docker container).
Prerequisite is to havea Snyk account created so the auth token can be added to the local machines environment varibles. In this instance the token was added to the VM.
Figure 17 - Juice Shop frontend folder containing the package.json dependency list used for SCA.
Figure 18 - Modifying package.json to include lodash 0.5.0 for testing vulnerable dependencies.
Figure 19 - Installing dependencies with npm; initial attempt fails due to peer dependency issues.
Figure 20 - Successful installation using --legacy-peer-deps, introducing additional vulnerable dependencies.
Figure 21 - Node_modules folder created containing all project dependencies.
Figure 22 - Running Snyk via Docker to scan project dependencies for known vulnerabilities.
Figure 23 - Snyk output showing lodash 0.5.0 vulnerability, with a link to remediation guidance.
For this demo of Git an account is required along with a demo page which will get pulled to local VM.
Figure 24 - Cloning a demo GitLab repository into the Ubuntu VM.
Figure 25 - Confirming repository contents are now available locally.
Figure 26 - Creating a new branch TestTicket, adding a file, and committing changes.
Figure 27 - Staging, committing, and pushing changes to the new branch on GitLab.
Figure 28 - GitLab interface confirming the new branch is available remotely.
Figure 29 - File created in the TestTicket branch visible on GitLab.
Figure 30 - Merging TestTicket branch into main via GitLab web interface.
Figure 31 - Main branch updated to include the contents from TestTicket.
- Successfully demonstrated SAST, DAST, and SCA on a vulnerable app.
- Identified real-world security issues including hardcoded passwords, CSP misconfigurations, and vulnerable dependencies.
- Practiced Git workflows with branching, committing, pushing, and merging.
- Built a stronger understanding of how DevSecOps practices integrate security into each stage of the SDLC.