GitLab
DevSecOps:
Improved Collaboration to Deliver Better Software Faster
Cut the Friction Between Dev and Security
With today’s frenzied development pace key elements in your projects can get overlooked or underestimated — like security. Think back to the last few projects your team 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?
If any of the above sounds familiar, know that they are usually symptoms of outdated security practices trying to fit into your DevOps or Agile methodologies. By upgrading your organization to DevSecOps, you’re shifting left and bringing security to the front of your development pipeline.
Security is changing — with a long way to go
Security respondents in the GitLab 2020 Global DevSecOps Survey reported 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.
The results of the 2020 are echoed in the GitLab 2021 Global DevSecOps Survey which showed nearly 28% of respondents are now part of a cross-functional team (identical to last year’s results), while 26% are now more focused on compliance (up nearly 4% from 2020) and 24% are more involved in daily tasks/more hands on (down slightly from last year).
It’s evident that companies are beginning to shift their security practices, yet 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% surveyed say their organization does not run SAST scans.
3 Reasons to Shift Left
While consistent communication is an important reason for many organization making the shift left, ultimately it’s the desire to save time and money that drives the decision to make the transition. Consider the following:
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 and avoid creating new technical debt.
Collaborative DevSecOps 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.
Empowered accountability. No developer wants to be ‘the one’ that brought down their organization with a security flaw. Empower them with the tools they need to be responsible for the security of the code they create.
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 vulnerabilities, and make adjustments for improvement.
- Identify pain points and bottlenecks 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. Embed scans within 4 standard CI/CD pipelines, so that every code change is reviewed and vulnerabilities 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 vulnerabilities sent to the security team, streamlining their review.
- Provide comprehensive scan results directly to the developer. While this is important for remediation, it’s also a valuable tool to help developers build their skills as different scan types find different security flaws, SAST alone is not enough.
- Eliminate any waterfall-style security processes within your SDLC. Find and fix security flaws as they are created to avoid new technical debt and rework.
- Give the security team visibility into both resolved and unresolved vulnerabilities, where the vulnerabilities reside, who created them, and their status for remediation.
- Streamline your tool chain. A DevOps platform can provide a single source of truth and a single user interface to improve collaboration.
