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.
The importance of collaboration between security and development teams
Security is a top priority in DevOps methodology because security breaches are troublesome and expensive, and the threats are persistent. Historically dev and sec have not gotten along, and when communication between groups is poor, it can be easier for security vulnerabilities to take hold. Also, dev and sec rarely agree on who owns security, which is a problem seen time and again in GitLab’s Annual DevSecOps Surveys.
Our survey isn’t the only one finding strife between the teams. The Ponemon Institute Research report indicated that 71 percent of AppSec professionals believe security isn’t taken seriously by devs; specifically, they believe developers aren’t building in security at a sufficiently early stage.
But, when security and development teams collaborate early and often on security scanning for their code, there are a number of improvements, including:
- Improved code quality
- Fewer time-consuming and costly fixes
- Full visibility of security measures for the whole organization
- Minimized risk of security breaches
- Top-notch security testing
Security tools and automation can only take teams so far. There is no “set it and forget it” option when it comes to security. There needs to still be a human at the wheel. Collaboration between development and security teams needs to be as much of a priority as security itself. DevSecOps needs to be a culture, not just a practice.
To remove team siloes around security, here are a few considerations:
- Understand what is driving each respective team. The motivations behind the choices significantly affect how DevSecOps efforts turn out.
- Do the big things together. Auditing existing security tools, processes, and places where automation is or isn’t in place should be a group effort, not an individual team effort.
- Define security objectives and responsibilities at every stage of the SDLC. Early scanning and testing are vital to security, and everyone can be part of checking that these security checks are happening.
- Plan and execute a comprehensive security training plan. Have clear guidelines on security goals and steps to follow in case of an active threat.
- Consider creating a security champions program.
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.
What is shifting left?
Shift left is a DevOps testing concept to speed up development while at the same time improving code quality. Think of the code development process as starting on the “left” with development and ending on the “right” with deployment, so shifting the testing stage left means moving it from the end of the process to close to the beginning. Shifting left is made far easier with test automation.
3 Important reasons to shift left
- 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.
- 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.
- 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.
9 Tips for efficient DevSecOps
- Measure time lost in dealing with vulnerabilities after code is merged. Next, look for a pattern in the type or source of those security vulnerabilities, and make adjustments for improvement.
- Identify pain points and software risks between development and security, create a plan to resolve them, and then execute on that plan.
- Make small code changes. Smaller updates are easier to review and secure and can be launched more quickly than monolithic project changes.
- Automate and integrate security scans. Make scans ubiquitous so that every secure code change is reviewed and security flaws are found at their source of creation.
- 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 open-source vulnerabilities sent to the security team, streamlining their review.
- 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.
- 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 and your security controls nimble.
- Give the security team visibility into both resolved and unresolved vulnerabilities in code, where the vulnerabilities reside, who created them, and their status for remediation.
- 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
Cover image by Marc Sendra Martorell on Unsplash
