It is that time of the year when the state of the “insert your paradigm of choice” reports are crossing the desks of Execs and Senior Managers, that purport to show the direction a particular industry is moving it. So do these reports have any value? They do.
Yes, they may be sponsored by a particular vendor. In this case GitLab sponsored the report on the state of DevSecOps. The fact remains that the information that is contained within is usually well researched. Gitlab has been releasing its state of DevOps report for many years and this is the fourth iteration.
The Mapping the DevSecOps Landscape survey report was released mid-May. The sampling that made up this report covered a reasonable cross-section of the DevOps community – over 3650 respondents from 21 counties contributed to this report across many functional teams. What is interesting from the results that over a third of the responders stated that developers define and create the infrastructure their application runs on with 14% monitoring, capturing, and responding to infrastructure events.
The Rise of CI/CD
Over a third (38%) of the respondents stated that their DevOps activities have evolved to include a CI/CD platform with over 91% using either GitLab (59%), GitHub (23%) or Bitbucket (11%), these numbers are not exactly unexpected for a report sponsored by GitLab as I would expect their customers to make up the vast majority of the core respondents. But that aside, GitLab as a product has included a fully functional CI/CD platform from its inception whereas GitHub Actions has only recently been released into the market and as such is playing catchup. Bitbucket was a late entrant into the pipeline and workflow space as well.
The Changing Role of the Developer
The rising popularity of the CI/CD paradigm dovetails nicely to the concept of ‘every company is a software company’. This idea was coined to conceptualize digitization and digital transformation of business processes, as well as the evolving discipline of infrastructure and operations to embrace software development methodologies to manage the lifecycle of the infrastructure.
Infrastructure as Code (IaC) became the main method of deploying new infrastructure in Cloud and virtualized environments and thereby driving quicker returns on development cost and resulting in a quicker route to value for the business.
The report has found that the gap between development and operational teams is continuing its trend and reducing, the report found that as the developer’s role evolved the lines are blurring between Developers and Operational staff. 35% of developers now say that they define or create the infrastructure that their applications run on. With 14% now having the responsibility of the monitoring and response to of that infrastructure and application.
It is even more critical for teams to understand how the role of the developer is evolving – and how it impacts security, operations, and test teams’ responsibilities. GitLab found that the lines are blurring between developers and operations teams as 35% of developers say they define and/or create the infrastructure their app runs on and 14% actively monitor and respond to that infrastructure – a role traditionally held by operations. Additionally, over 18% of developers implement code for production monitoring, while 12% serve as an escalation point when there are incidents. As an ex-Operational guy, this is worrying for a lot of my former colleagues and should further reinforce the notion that tin-bashing is now a dead-end role. If you are in operations and have not started to learn how to code. Then get started now or you will be left behind.
The adoption of DevOps is growing, according to the report 25% of companies could be called mature having between three to five years of DevOps practice, and 37% have between one to three years DevOps practice. Overall, this means that over 60% of companies approached are utilizing DevOps principles to a greater or lesser extent, again considering the sponsoring company this is not an unexpected result. As if you are a customer of GitLab it would be expected that you are further on your DevOps journey than many that are not as utilizing a Software Development Lifecycle management program in their development processes.
One part of the report that I find odd is that nearly 60% of those who responded are deploying multiple times a day, once a day, or once every few days (this is up from 45% as per last year’s report). This could just be report bias, ie those that respond do so because they have found the focus of the report relevant and those who were approached are not doing DevOps in any meaningful manner decided that responding was not worth their effort, if this is the case then this is a shame as it skews the report by overstating DevOps principle adoption. This also goes hand-in-hand with the statement from the report that 70% of Operational staff state that Developers can deploy their own environments. This second part is more believable than the first statement. But it must be said that the report makes no mention of whether the 60% of deployments are purely in production, but include Dev, Test, and Staging. If the latter, then the numbers are more believable. It does however show a significant move in roles and responsibilities within corporate IT.
One of the new and upcoming technologies according to this report is micro-services, this is where applications are distilled to such a level that individual processes are considered as a micro-application. According to the Wikipedia entry on micro-services, there is no clear definition of what one is, but some agreed common features are:
- Services in a micro-service architecture (MSA) are often processes that communicate over a network to fulfill a goal using technology-agnostic protocols such as HTTP.
- Services in a micro-service architecture are independently deployable.
- Services are organized around business capabilities.
- Services can be implemented using different programming languages, databases, hardware, and software environments, depending on what fits best.
- Services are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized, and built and released with automated processes.
According to the report, almost 40% of respondents stated that they “partially” use micro-services, while 26% state that they fully utilize them, a fact that seems odd as there is no real definition of what a micro-service is, personally I do not consider Kubernetes a micro-service but according to the report38% of the respondents have adopted them and consider them to be a micro-service.
According to the report there continues to be a clear disconnect between developers and corporate security teams, there is uncertainty as to who should be responsible for security efforts this is to be expected. 25% of Developers state that they feel that they are solely responsible for the security of their applications, again understandable, the vast majority of Security Team members have traditionally come from an infrastructure background with their bias pointed firmly on physical security. Their lives still revolve around WAS, WAPs Firewalls, IP Tables, and IPS and IDS systems. They have no experience with coding and as such, they rely on their traditional backgrounds. But that said, security teams, believe that developers are still not finding enough bugs in their code and are not fixing them quickly enough. 42% of Security respondents state that testing is still happening too late in the development cycle and 36% report that it was hard to understand the development process, and fix any discovered vulnerabilities, again this is understandable considering the biases of the majority of traditional Security teams.
Despite the progress that DevOps and DevSecOps have made in the industry, the survey makes it clear there is still much work to be done. With testing for example More than 42% of respondents stated that testing did not start quickly enough. Over 47% identified testing as their top DevOps bottleneck for the second year in a row. And only 12% said they have completely automated testing, that is a low number for DevOps to be truly successful automated testing, vulnerability testing needs to be automated, otherwise the increases gained in operational agility will be lost to in a weed patch of a QA department.
Even though DevSecOps is a growing paradigm, it is still has a very small footprint. There seems to be pushback from security teams that see security as their fiefdom and there is continuing effort to marginalize them because of these actions. With DevOps and DevSecOps gaining ground, companies like Sysdig, GitLab are focusing their development education on increasing security posture. Perhaps one of the areas that will benefit from greater security oversight would be the QA department, if Testing had more rigor, with security built-in from start rather then a bolted-on afterthought. The Testing bottleneck would lessen. Sec teams spend the vast majority of their time analyzing reports generated by their automated tooling, these tools are designed to highlight anomalies and vulnerabilities, according to Jonathon Hunt VP Security at GitLab; ”there is an industry-wide push to shift left, our research shows that greater clarity is needed on how teams’ daily responsibilities are changing because it impacts the entire organization’s security proficiency Security teams need to implement concrete processes for the adoption of new tools and deployments to increase development efficiency and security capabilities.”
This resonates, having had to liaise with Security teams over many years there is still the common lament that Security teams are not agile enough, they need to wake up, learn some new tricks or else they like the Mainframe Operations team will be going the way of the dodo.