Companies want their software projects delivered faster. They want results quicker, teams to work more efficiently, and they think that investing in areas like the cloud will help to deliver this.
While it is true that using cloud services will provide more flexibility and faster delivery, it’s not the whole story when it comes to security. The push to get more software projects delivered faster can lead to corners being cut, assumptions that software components are secure by default, or ignoring best practices in security altogether in the rush to get things done. Whether it is due to overlooking obvious issues or not applying standard security benchmarks like CIS, this can be dangerous.
DevSecOps involves improving collaboration around software development, operations and security so that things get achieved securely and efficiently. The discussion that takes place around how to “shift left” and get security embedded into software development process is a worthy one. However, that description – “worthy” – itself shows up the biggest problem that exists around how to make this work in practice.
Eat your software greens
It’s all too easy for security to be something viewed as the equivalent of eating your vegetables when you are a child: something you know you should do, but there are so many other interesting and exciting things that you could be doing instead. Breaking the mindset that security is too hard, or that it prevents those interesting projects, is an essential step to building better processes.
Adding guidance on how to solve problems in a secure way and providing feedback early can effectively position a security team as helping their developers in advance.
For developers, security can still be a nebulous concept too. According to Gitlab’s Global Developer Report: DevSecOps for 2019, 69 percent of developers stated that they were expected to produce secure code, but only 25 percent rated their organizations’ security approaches as “good.”
Around 45 percent stated they received feedback and were able to address issues during the development process – while this is encouraging, it means that more than half don’t have security remediation taking place during the initial software development phases.
Changing this situation should be a priority for security teams, as it is easier to fix issues before they move further into the deployment and production phases. The same survey found that this was a challenge, as nearly half of all security professionals found that they struggled to get developers to take action on fixing vulnerabilities as a priority.
In our research with customers, companies do have multiple tools in place to track their implementations and provide them with data – however, many teams don’t fully use the valuable data these tools produce.
Around 60 percent are using cloud native security services such as AWS CloudTrail (60%) and VPC Flow Logs (34%) for audit and reporting purposes according to our customer benchmarking report. These services can provide useful data for tracking activity, while it can also be used for benchmarking your results against others too.
However, the challenge facing many security teams is the time, resources, and knowledge needed to extract any insight from this data and how to use it over time.
It’s not that people are not aware of security, or that they don’t want to produce secure code. Instead, the issue is around how to make the processes involved easier for everyone.
Continuous deployment creates data continuously
For security teams, embedding security into the continuous integration (CI) and continuous deployment (CD) pipeline involves understanding the steps that are taking place and getting the right data from them.
For developers, this data can help to flag potential issues and how much impact they are having. This data is generated continuously from the pipeline, so it’s worth taking the time to get that data into the right formats for both developers and security teams to understand for their own requirements, as well as getting a unified dashboard for priority setting.
This continuous intelligence data can help make DevSecOps a reality. By getting all teams to look at data – and to provide this information in different formats for people to understand – you can avoid some of the issues around the negative aspects of collaboration such as finger-pointing and blame. Instead, this can be viewed as a faster way to get to root causes and fixes that can proactively deliver better and more secure code at the same time.
This emphasis on process supported by data is essential, as it is hard to make changes to how people work if they don’t see benefit consistently from any new approach. Indeed, it’s all too easy for people to look for workarounds or for individual teams to go off on their own approaches rather than follow new rules. Getting a consistency of approach is easier when you have data from your own processes to work with and use to show results.
As an approach, DevSecOps involves bringing the best of the new approaches to software delivery out to a wider world through improving how teams work together. For security teams, supporting CI/CD pipelines and obtaining accurate data on how any changes affect the security of systems can enable issues to be flagged quickly.
At the same time, developers and IT operations teams can use this data to improve their environments and remove issues before they hit production. By collaborating on these problems, DevSecOps can improve how businesses operate overall.