GitLab vs. GitHub: DevSecOps Pipeline

by Romano Roth and Patrick Steger

This video series will show you how to build up an enterprise-ready DevSecOps Pipeline with GitLab and GitHub and compare the two platforms.

​Topic	​GitLab	​GitHub
​Introduction	Provides integration points to include security tools. Offers GitLab maintained integrations for GitLab recommended default security tools.	Provides integration points to include security tools. There are no default GitHub recommended/maintained security tools. There are security tools provided by the community for open source and commercial tools.
​Creating a simple project	Can create new empty repository Offers to start with GitLab provided default project/repo-structure (e.g. C#, SpringBoot, PHP, etc). They are easy to find. Can import from other repositories like any Git repository (URL), GitHub, Jira, Bitbucket, etc. .gitlab-ci.yml is the entry point defining the whole pipeline. Option to include additional files (their content is included automatically at runtime). Pipeline is broken down into stages and jobs, where stages are executed after each other and all jobs of a stage run in parallel (dependencies can be configured) This is a very neat approach but can become tricky to understand for complex pipelines. So it was easier to understand for us at the beginning, but we feel its slightly harder to maintain and understand for projects with many pipelines / complex scenarios) Pipeline runs are found in menu CI/CD -> pipelines. Very easy to create a simple first pipeline because GitLab provides defaults for most everything that is required to start Nice UI for navigating the repositories/projects Artifacts can simply be declared and are then available in the pipeline results view for download, this is GitLab provided and well documented. Standard artifacts like test-results can be made visible in the GitLab UI using default GitLab functionality. Integreation into the GitLab UI is professional out-of-the-box. Different pipelines (ways to execute the pipeline) must be configured with rules (e.g. based on what branch was commited). This may become complicated when basically wanting different pipelines to run for different conditions (because pipelines view does not cleanly separates them and offers just views for different branches and tags). It may get a bit messy for complex scenarios. Nice graphical view to visualize stages and jobs as well as their dependencies (but not the conditions)	Can create new empty repository Can create a new repository based on a template project. Template projects are hard to find when there are none in your organization. (Searching on GitHub with tag called #github-templates or #template-repository produces some...). Can import from existing Repositories. Including GitLab. But does not work when using Social-Login (i.e. Login with Account not provided by GitLab). Pipelines are called Workflows. We can have a dedicated file for each workflow we want. Within the worflow file we define what triggers the workflow/pipeline. It is possible to "call" sub-workflows (files) from a workflow file. Pipelines/Workflows are cleanly separated in the UI and make it easy to find the right workflow/pipeline. Pipeline/Workflow runs are found cleanly listed by Workflow in tab "Actions" in the UI. Workflows use actions to implements jobs/steps. Such Actions are available over a Marketplace and not always easy to be found. This is a flexible way to design pipelines. It took us longer to understand how everything works, but we feel that it is easier to maintain and understand projects with many pipelines/complex scenarios) Quite complex to get the first simple pipeline running because not much is automatically provided by GitHub Nice UI for navigating the repositories/projects. Artifacts are made available using an Action (for example using upload-artifact Action found in the Marketplace) Standard artifacts like test-results require other actions from the marketplace to make them available in the GitHub UI. The UI quality and integration into the GitHub UI varies. Different pipelines are simply configured in extra workflow files. This becomes natural after some time and supports complex scenarios but requires clear guidance within the project team. Nice graphical view to visualize the workflow/pipeline run for executed runs.
​​​Software Composition Analysis (SCA)	GitLab provided open source scanner available, documented and easily found Simply add a GitLab provided template (or copy the file to the project) The default tool has adequate quality and findings and is enterprise ready Findings are well integrated in GitLab UI (Pipeline view, Security&Compliance -> Vulnerability report) Vulnerabilities are also available as a download (json). Commercial tools and custom tools can also be integrated but require quite a bit of work. Integrating their findings into GitLab as a central platform can proof difficult. GitLab uses a GitLab specific format to integrate vulnerabilities in the GitLab UI. No built-in scheduled re-scans, but can be defined explicitly. (See later video). Special feature: Comparable simple editor of files in the project.	No GitHub provided default tool Find one in the Marketplace. We choose CRDA of RedHat based on Snyk (which proofed to be not enterprise ready because it was instable regarding availability and it limits the number of scans).There are not to many open source options available that integrate well into GitHub. Using commercial tools usually leads to situations where the findings are only found within the commercial tool selected. Marketplace tools (Actions) are provided by third parties. Be aware of the risk and consider what providers you trust. Consider also building your own tool. GitHub has also some built-in functionality (called Dependabot, enabled in the project settings) that can be enabled in settings and allows regular, scheduled scans of unchanged code. That is great. The GitHub format to display vulnerabilities in the GitHub UI is based on standards. This proofs to be better for custom integration of tools because some tools provide these standard formats. Dependabot can alert of new findings and offer pull requests for known fixes. But it is not executed on commit and cannot block merges and similar. Dependabot dependencies are visibale in the GitHub UI. Dependabot findings can be found in tab Security -> Dependabot. We did not get any findings here when the video was made although we should have. Special Feature: Fully integraded development environment (similar to Visual Studio Code). This proofed to be very powerful.
​License Compliance	License compliance is provided as a managed GitLab tool (based on License-Finder open source project) that is easy and straightforward to add. Yet at time of recording the tool had a bug we required to fix (marking a file as executable) All used licenses of the project are visible in a default GitLab UI. Can configure acceptable licenses as part of the platform (project settings; we can define a license policy). Support of basic workflows to verify and accept new licenses (i.e. include a security team member as acceptor/reviewer) Failed (not marked as acceptable) licenses are reported.	Requires community provided (Marketplace) or custom Action to implement this. It's meaningful to define an extra sub-workflow (pipeline) for this. Our session on this topic led to improvements for Action license-finder-scan (GitHub support helped us to create this, it is now in the Marketplace available). Note that the license finder image we use in the video had a bug requiring us to mark a file as executable in the image (i.e. same as with GitLab, as both use the same open source tool/image). Can define what licenses are configurable, get error/failed pipeline when other licenses are found. Failed (not marked as acceptable) licenses are - in our case - reported as "customized Test Results". Results are visible in the pipeline run only (not in the scan results view of the platform). There is no easy way to see "all licenses used by the project" (this is only in the log-output of the pipeline run).
​​Static Application Security Testing (SAST)
​Container Scanning
​​Secret Detection
​​Dynamic Application Security Testing (DAST)
​​Vulnerability Management
​Merge Request
​Schedule Pipeline
Our Recommendation

Summary