In jedes Softwareprojekt gehört eine CI (Continuos Integration). Sie dient zur Qualitätssicherung, führt bei einem Push ins Repository alle Tests aus, prüft die Integrität des Projekts etc.
Wir können (und sollten) die GitLab CI verwenden. Dafür kann eine .gitlab-ci.yml-Datei im Rootverzeichnis des Projekts angelegt werden und die CI wird automatisch gestartet. AutoDevOps kann auch verwendet werden, um eine CI-Konfiguration zu erraten. Alles weitere könnt ihr den anderen Repositories im GitLab oder der offiziellen Dokumentation entnehmen.
GitLab Secure bietet einige Securitytools für den Codecheck an:
| Secure scanning tool | Vulnerabilities database updates |
| Container Scanning | Uses clair underneath and the latest clair-db version is used for each job run by running the latest docker image tag. The clair-db database is updated daily according to the author. |
| Dependency Scanning | Relies on bundler-audit (for Rubygems), retire.js (for NPM packages) and gemnasium (GitLab’s own tool for all libraries). bundler-audit and retire.js both fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to ruby-advisory-db and retire.js are immediately available. The tools themselves are updated once per month if there’s a new version. The Gemnasium DB is updated at least once a week. |
| Dynamic Application Security Testing (DAST) | Updated weekly on Sundays. The underlying tool, zaproxy, downloads fresh rules at startup. |
| Static Application Security Testing (SAST) | Relies exclusively on the tools GitLab is wrapping. The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. |
Die Tests können bequem in die CI-Pipeline eingebunden werden, hierzu einfach (am Beistpiel von SAST):
include: - template: SAST.gitlab-ci.yml
Und dann muss noch eine test stage angelegt werden, falls noch nicht vorhanden.
stages: - ... - test - ...