Jun 23, 2020 - Vanessa Wegner    

DevSecOps basics: 9 tips for shifting left

Here's how to create an efficient DevSecOps practice and shift your security left.

This is the first in a five-part series on getting started with DevSecOps. Part two outlines the steps needed to create silo-free collaboration. Part three looks at the importance of automated security testing. And part four explains how to build a strong security culture to support your DevSecOps efforts.

Speed is required to stay competitive – nearly 83% of our 2020 Global DevSecOps Survey respondents said they’re releasing code faster than ever with DevOps. With the pace of work accelerating, some important details are easily overlooked or underestimated – like security.

Think back to the last several projects your team has launched. Did security testing begin late in your software development lifecycle (SDLC)? Was too much time wasted on friction between siloed development and security? Was the project delayed due to inefficient handoff between teams, lack of visibility across systems, or lack of planning and consideration?

All of these are symptoms of outdated security practices trying to fit into your DevOps or Agile methodologies. Upgrade your organization to DevSecOps by shifting left: Bring security to the front of your development pipeline.

Security is changing – with a long way to go

Security respondents in our 2020 Global DevSecOps Survey report changes in their roles: Being increasingly included as part of a cross-functional team focused on security (27.73%), becoming more involved in the day-to-day/more hands on (26.94%), and focusing more on compliance (22.55%). Only 19.95% report that their role is not changing.

It’s evident that companies are beginning to shift their security practices, but security testing remains a source of frustration: Over 42% of survey respondents said that testing happens too late in the lifecycle. This may be due to conflicting opinions on who is responsible for security. Nearly 33% of respondents said the security team is responsible, while almost as many people (29%) said that everyone was responsible.

However, it’s difficult for everyone to be responsible when developers aren’t provided with the proper tools and resources to assess the security of their code: Surprisingly, static application security testing (SAST) is still not a common developer tool: Less than 19% of companies surveyed in this year’s DevSecOps report put SAST scan results into a pipeline report that developers can access, and over 60% of developers don’t actually run SAST scans.

Key to efficient security: Clarity

Communication cannot be understated when it comes to shifting left. Moving security forward in the software lifecycle won’t help anyone if your team doesn’t understand their responsibilities and expectations. Document any and all role changes when shifting your security practices, and then make sure that all parties have the tools necessary to get the job done.

3 Important reasons to shift left

  1. More code gets tested. By bringing security forward in the SDLC, you provide more opportunities for code to be scanned and vulnerabilities to be remediated. By automating static application security testing (SAST) at every code commit, for example, you can at least ensure that all code has been scanned once.
  2. Planning becomes more well-rounded. Shifting left is not just about technology – it’s also about people. Bring a security DRI into your initial planning meeting to make sure you account for security needs in all stages of the SDLC. This will help streamline end-of-cycle security reviews, reduce friction between teams, and increase the likelihood of hitting your deadline with a secure product.
  3. Better accountability among non-security team members. Shifting left lets your team know that everyone is now expected to take security seriously and make it a part of their daily work.
10 Steps to secure next-gen software Learn how DevOps will impact your security program.

9 Tips for efficient DevSecOps

  1. Measure time lost in dealing with vulnerabilities after code is merged. Next, look for a pattern in the type or source of those vulnerabilities, and make adjustments for improvement.
  2. Identify pain points and bottlenecks between development and security, create a plan to resolve them, and then execute on that plan.
  3. Make small code changes. Smaller updates are easier to review and secure, and can be launched more quickly than monolithic project changes.
  4. Automate and integrate security scans. Make scans ubiquitous, so that every code change is reviewed and vulnerabilities are found at their source of creation.
  5. Build security scans into the developer’s workflow. Integrated security enables developers to find and fix vulnerabilities before the code ever leaves their hands. This also reduces the volume of vulnerabilities sent to the security team, streamlining their review.
  6. Give developers access to SAST and DAST reports. While this is important for remediation, it’s also a valuable tool to help developers build secure coding practices.
  7. Reduce or eliminate any waterfall-style security processes within your SDLC. You should always be able to change direction as needs arise: Keep your organization nimble.
  8. Give the security team visibility into both resolved and unresolved vulnerabilities, where the vulnerabilities reside, who created them, and their status for remediation.
  9. Streamline your toolchain so that employees can focus their attention on a single interface: A single source of truth.

How efficient are your DevSecOps practices? Take our DevSecOps Maturity Assessment to find out.

Learn more about DevSecOps:

How to harden your GitLab instance

Make your toolchain more secure

Our goals with Zero Trust

Cover image by Marc Sendra Martorell on Unsplash

10 Steps Every CISO Should Take to Secure Next-Gen Software Understand three software shifts impacting security, and the steps CISOs can take to protect their business. Get the eBook Arrow
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg