GROUPE TROIS · SPRINT 1 — IT Security module, TH Aschaffenburg
Overview / Setup / SAST Research / Unit Testing
| Owner | Sprint | Status |
|---|---|---|
| Docs Lead | Week 1 | Active |
This repository is the written record of a DevSecOps group project: the brief, the scope decisions, the team structure, the sprint goals and the research behind the tooling choices. It holds documentation only — no source code.
The software the documentation describes lives separately:
| Repository | Contents |
|---|---|
| Agile-Security | The Vulnerability Dashboard — Express + SQLite service that ingests and deduplicates scanner findings, plus its dashboard UI, Docker setup and GitLab CI pipeline |
| (internal GitLab) | The two applications under test — an in-house to-do list and OWASP Juice Shop — hosted on lv-gitlab.intern.th-ab.de and not mirrored publicly |
The dashboard is the deliverable this brief builds toward: sections 1.5 and 2 below define the pipeline stages whose output it aggregates.
- 1. Project Overview
- 2. Sprint 1 Documentation
- 3. SAST Research — to do
- 4. Unit Testing — to do
The team works as software developers in a company that provides software to medium-sized customers, delivered both as a SaaS solution and as an on-premise installation. Two applications are already finished and in use: a to-do list and an online store (OWASP Juice Shop).
Both applications have so far been developed using an agile but traditional software development approach. This has led to an increase in operational errors due to the lack of automated quality assurance. As the customer base continues to grow, management has decided to adopt a DevOps approach to respond more efficiently to customer requests and new feature demands. At the same time, potential security risks must be urgently mitigated — the decision has been made to fully and sustainably implement security alongside DevOps.
Project Goal: Build two working CI/CD pipelines with integrated security tooling, and develop a custom Vulnerability Dashboard that aggregates and prioritises the results of the security tools across both applications.
The project focuses on two questions:
- Security in coding — how can the team ensure that applications are developed securely? (secure coding, SAST, DAST, fuzzing)
- Securing the code — how can the source code and the technical infrastructure used for development be protected? (secret detection, dependency scanning, container scanning)
Out of scope: the secure operation of the SaaS solutions themselves and general IT infrastructure (email, telephony, accounting, etc.).
The team is composed of five roles, each responsible for a distinct area of the project:
- Scrum Master / Product Owner — takes responsibility, involves stakeholders, clarifies issues, and prioritises the backlog.
- Developer — implements application features and unit/integration tests; works in a structured, time-boxed manner.
- Security Expert (Security Champion) — researches SAST tools, defines secure coding guidelines, and leads vulnerability analysis.
- DevOps Engineer — enforces standards, designs and implements the GitLab CI/CD pipeline stages and jobs, and maintains the deployment infrastructure.
- Technical Writer — structures and summarises project knowledge, maintains documentation across all sprints, and keeps an overview of progress.
- Source control: GitLab server (
lv-gitlab.intern.th-ab.de) — one project per application plus one for the Vulnerability Dashboard. - Deployment: Ubuntu VM with Docker Engine assigned to each team.
Each pipeline must implement the following security stages using open-source tools — GitLab Auto DevOps and GitLab Templates are explicitly excluded:
- SAST — static analysis of source code (e.g. Semgrep, SpotBugs, SonarQube)
- Secret Detection — scan for accidentally committed secrets (e.g. gitleaks, TruffleHog)
- Dependency Scanning — identify vulnerable third-party libraries
- Container Scanning — analyse Docker images for known CVEs (e.g. Trivy)
- Web API Fuzzing — automated fuzzing of REST endpoints
- DAST — dynamic analysis of the running application (e.g. OWASP ZAP)
Establish the foundation for secure CI/CD by setting up repositories, implementing automated tests, and preparing initial security knowledge (SAST) for both applications.
The to-do list is a lightweight task-management web application. It covers the fundamental CRUD operations — creating, reading, and deleting tasks — and serves as the primary application for CI/CD pipeline development in Sprint 1.
- Stack: Java, Spring Boot, Apache Maven
- Sprint 1 focus: repository setup, unit tests, build stage in GitLab CI
- Build artifact: executable JAR (
mvn package)
User Story: As a developer, I want unit tests for the to-do list application so that individual components work correctly and regressions are prevented.
Acceptance criteria for Sprint 1: the source code is pushed to the group GitLab repository with a proper folder structure, a README file, and access permissions set for all team members. The project must build locally without errors.
Juice Shop is an intentionally vulnerable e-commerce web application created and maintained by OWASP. It contains a wide range of deliberately introduced security vulnerabilities spanning the OWASP Top 10. In this project it serves as the target for security analysis and SAST evaluation. For Sprint 1 the application is deployed as a Docker container using the official image published on Docker Hub.
- Deployment: Docker —
docker run --rm -p 3000:3000 bkimminich/juice-shop - Docker image:
bkimminich/juice-shop(Docker Hub) - Sprint 1 focus: repository setup, unit tests on selected modules
- Modules under test: authentication, product handling
- Security purpose: provides realistic, known vulnerabilities to validate SAST tool effectiveness
User Story: As a developer, I want unit tests for the Juice Shop application so that important business logic is validated independently.
Note on scope: because Juice Shop is a large codebase, Sprint 1 unit tests are intentionally scoped to selected modules only. Full coverage is not a goal at this stage.
Three impediments were identified during sprint planning and logged in the impediment backlog.
- Lack of CI/CD experience — the team is unfamiliar with structuring a GitLab pipeline. Mitigation: a dedicated learning backlog item covers GitLab CI/CD basics.
- Unclear test strategy — uncertainty about the boundary between unit and integration tests was causing delays. Mitigation: testing scope was defined explicitly during sprint planning.
- Juice Shop complexity — the large codebase makes it hard to identify testable units quickly. Mitigation: Sprint 1 testing is restricted to pre-selected modules.
Status: To Do — This section will document the SAST research once completed. It will cover tool selection, static analysis methodology, and CI/CD integration guidance based on the Security Expert's findings.
Status: To Do — This section will document the unit test implementations once they have been written and verified for both applications.