Integrating Security into DevSecOps

Application Security is hard - when it is a separate process

You want to test everything but you…

Can’t afford to test all of your code or have everyone use it
Lack security analysts to validate results, prioritize and triage
Experience friction between app sec and engineering that hinders remediation
Already have found more vulnerabilities than you have time to fix.

So you may…

Only test externally-facing apps because they have higher risk
Only test mission critical apps
Only test major releases
Focus on one testing method alone

Even though you know that…

Hackers can traverse laterally across your enterprise. They look for the weakest link so internally-facing apps must be tested too.
Different types of scans are best at finding different types of vulnerabilities.
Exploits change all the time. Penetration testing only tests a snapshot in time.
You must strike a balance between risk and business agility.

Benefits of an integrated approach

Balancing business velocity with security is possible. With GitLab, application security testing is built into the CI/CD process. Every merge request is scanned for vulnerabilities in your code and that of its dependencies. This enables some magic to happen:

Every piece of code is tested upon commit, without incremental cost.
One source of truth for both the developer and the security pro promotes collaboration and empowers the developer to identify vulnerabilities within their own workflow.
The developer can remediate now, while they are still working in that code, or create an issue with one click.
The dashboard for the security pro is a roll-up of vulnerabilities remaining that the developer did not resolve on their own.
Vulnerabilities can be efficiently captured as a by-product of software development.
A single tool also reduces cost over the approach to buy, integrate and maintain point solutions.

The GitLab Secure Paradigm

GitLab secure capabilities support the decision-makers. Instead of security being a blocker, we want to provide a very simple way to take the right action and learn from it. Keeping it simple is a key value so that security features will not be considered more effort than the perceived benefit. What is a false positive can be very subjective, and risk assessment will be mostly a human process. That's why we believe security features should not automatically block a pipeline or prevent a new version to be released to production. Key ideals of our design include:

Reports are interactive, actionable, and iterative. When triaging vulnerabilities, users can confirm them (creating an issue to solve the problem), or dismiss them (in case they are false positives). This information will be collected to improve the signal-to-noise ratio that the tool could provide in future executions.
Reports also need to be easy to use, and require the minimum amount of effort from users. Otherwise, security checks will likely be disabled or not considered at all, missing their primary goal.
Unlike traditional application security tools primarily intended for use by security pros, GitLab secure capabilities are built into the CI/CD workflow where the developers live. We empower developers to identify vulnerabilities and remove them early, while at the same time, providing security pros a dashboard to view items not already resolved by the developer, across projects. This vulnerability-centric approach helps each role deal with items that are most important and also most relevant to their scope of work.

Learn more about the GitLab Secure Paradigm.

Continuous security testing within CI/CD

When using GitLab CI/CD, every merge request is automatically testing using the following methods.

Static Application Security Testing (SAST)

Scan the application source code and binaries to spot potential vulnerabilities.
Because these open source tools are installed as part of GitLab Ultimate, there are no added costs.
Vulnerabilities are shown in-line with every merge request and results are collected and presented as a single report.
Evaluate vulnerabilities from the GitLab pipeline and dismiss or create an issue with one click.

Dynamic Application Security Testing (DAST)

Dynamic scanning earlier in the SDLC than ever possible, by leveraging the review app CI/CD capability of GitLab.
Test running web applications for known runtime vulnerabilities.
Users can provide HTTP credentials to test private areas.
Vulnerabilities are shown in-line with every merge request.

Open Source Dependency Scanning

Analyze external dependencies (e.g. libraries like Ruby gems) for known vulnerabilities on each code commit with GitLab CI/CD.
Identify vulnerable dependencies needing updating.
Vulnerabilities are shown in-line with every merge request.

Container Scanning

Check Docker images for known vulnerabilities in the application environment.
Avoid redistribution of vulnerabilities via container images.
Vulnerabilities are shown in-line with every merge request.

Why stop there? While GitLab runs application security scans on every code commit, why not also verify compliance with open source licenses.

License Management

Automatically search project dependencies for approved and blacklisted licenses defined by your policies.
Custom license policies per project.
License analysis results are shown in-line for every merge request for immediate resolution.

Want to know where we're headed? Learn about the future of GitLab's Secure capabilities