Shift Left with DevSecOps

DevOps allows to deliver code faster but this acceleration should not put security at risk, hence the concept of DevSecOps.

DevSecOps induces a shift left approach to security. An outdated approach to security such as late security testing in the SDLC, or frequent handoff between siloed teams cannot fit with the DevOps methodology.

The philosophy behind DevSecOps is to begin security testing earlier in the software development lifecycle. To give you a concrete example, here's how you could shift your CI to GitHub Action.

Security testing is not done only when the application is released into production. Security testing is shifted to the left by including security planning, testing and monitoring into each phase of the DevOps pipeline. DevSecOps becomes a complement to traditional security testing and secure software development practices.
Security testing prior to production release is still mandatory, but it is more of a final check.

On the developer’s side understanding application security and having the tools to help them write secure code are key components of the DevSecOps approach. The market is moving fast on this topic and GitLab DevSecOps annual survey records this trend: “Could 2021 be the year that DevSecOps becomes a reality? Perhaps. An unprecedented 72% of security pros reported their organizations’ security efforts were either “good” or “strong.” That’s a significant change from last year when only 59% said the same thing. Another positive sign: Security is also continuing to shift left and at a faster pace than we’ve seen before. Over 70% of security pros report their teams have shifted left, up from 65% last year”.

Scanning using SAST and DAST tools is increasing around 50%, but what about the 50 other percent? And the main issue is that the scanning results are not made available to developers. Shift left cannot be a reality if developers cannot access results.

The DevOps methodology puts in place an automated pipeline of tooling and practices which build, test and release applications. DevSecOps will therefore require additional tooling to automate security testing and this tooling will need to break the barriers between Devs and Sec teams.

---

Automated security testing for an efficient shift left

Shifting left security implies that every change to the codebase goes through a series of security tests before it is accepted into a build that is ready to be released into production.
When a security test fails, the build could fail and the developer would be notified immediately, or if the problem has a low severity, the issue could be logged into the ticket management system for prioritization by the agile lead.

For more code to be tested you need to automate scanning and to remediate vulnerabilities. Secrets detection is a good example of how systematic code scanning can deliver cleaner code.

Security scans need to be integrated into the developer’s workflow. This enables developers to find and fix vulnerabilities before the code ever leaves their computers.

Consequently, the volume of vulnerabilities that the security team needs to review is heavily decreasing, leaving them with the most complex issues that require their skillset.

Another positive impact of shifting left security is that developers will be involved in the remediation process early. They will still have their code fresh in mind and they will learn from the alert. It definitely helps developers become better and build long-term secure coding practices.

As security becomes a shared responsibility between development and security teams tooling and processes should follow.