Application Security is hard when security is separated from your DevOps flow. Security has traditionally been the final hurdle in the development lifecycle. Iterative development workflows can make security a release bottleneck. Your team doesn't have enough people to test all of your code, and hiring more analysts won't automatically reduce the friction between your app sec and engineering teams. Only testing major releases, or limiting tests to certain apps, leaves weak spots hackers can exploit. You need a way to balance risk and business agility. Instead of waiting for security at the end of the development process, you can include it with your DevOps workflow. You need DevSecOps.
DevSecOps integrates security best practices in the DevOps workflow. DevSecOps automates security workflows to create an adaptable process for your development and security teams.
Why is DevSecOps needed?
Balancing business velocity with security is possible. With GitLab, DevSecOps architecture is built into the CI/CD process. Every merge request is scanned through its pipeline for vulnerabilities in your code and its dependencies. This enables some magic to happen:
Benefits of DevSecOps
Every piece of code is tested upon commit, without incremental cost.
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 aspects 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.
Easy-to-use reports need to 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.
Support decision makers by giving a very simple way to take the right action, and learn from it. Simplicity is a key value to prevent security features from not being considered due to complexity
Tools are actionable so users can interact with them and provide feedback about their content. When triaging vulnerabilities, users can confirm (creating an issue to solve the problem), or dismiss them (in case they are false positives and there is no further action to take).
Easy to use: Require the minimum amount of effort from users: We don't want to add extra workload on final users.
Shifting Security left: GiLab introduces security into the CI/CD pipeline providing input on ONE application
Security Deep Dive
Static Application Security Testing (SAST): Prevents vulnerabilities early in the development process, allowing to be fixed before deployment
Dynamic Application Security Testing (DAST): Once code is deployed, prevent exposure to your application from a new set of possible attacks as you are running your web applications
Dependency Scanning: Automatically finds security vulnerabilities in your dependencies while you are developing and testing your applications, such as when you are using an external (open source) library with known vulnerabilities
Container Scanning: Analyze your container images for known vulnerabilities
Auto Remediation: Auto remediation aims to automated vulnerability solution flow, and automatically create a fix. The fix is then tested, and if it passes all the tests already defined for the application, it is deployed to production.