devopsy.kinsta.cloud

Tag: devsecops

OX Security Optimizes DevSecOps to Improve Application Security

OX Security this week updated its application security posture management (ASPM) platform to enable DevSecOps teams to instantly identify applications running in production environments that are running code that could be potentially exploited.

The ASPM platform from OX Security leverages large language models (LLMs) to identify vulnerabilities. The latest version adds an ability to confine the number of alerts generated to instances of code that can actually be exploited.

OX Security CEO Neatsun Ziv said that approach reduces the number of alerts that would otherwise be generated by 99% to enable DevSecOps teams to focus their limited resources on the 1% of alerts that represent an actual risk to the business. OX Security achieves that goal in part because its scanners are integrated with source control, continuous integration/continuous delivery (CI/CD) platforms, registries and cloud computing environments.

The overall goal is to reduce the amount of manual effort currently required to consistently maintain DevSecOps best practices.
The primary reason many vulnerabilities are never addressed is that DevSecOps teams are simply overwhelmed by alerts. Most of the alerts generated by a cybersecurity team are not immediately relevant because either the vulnerability is not present in the application running in a production environment or the application doesn’t connect to the internet.

The OX Security platform makes it possible to identify application security issues that need to be prioritized because it has been confirmed a vulnerability exists that can be exploited, said Ziv.

No matter how precise the alert process becomes, a DevSecOps team will still need to manage it, added Ziv. However, as the alerts generated become more relevant, it should become easier to bridge the historic divide between application developers and cybersecurity teams. Too many developers routinely ignore vulnerabilities identified by cybersecurity teams simply because previous efforts to identify the actual severity they represent have ultimately been a waste of their time.

The challenge just about any organization encounters when trying to better secure their software supply chains is, not surprisingly, getting application developers to buy into the DevSecOps process. Most developers are going to actively resist any approach to remediating vulnerabilities that takes time away from building new applications. Most of them only allocate about 10% of their time or less to remediating vulnerabilities. As such, it’s incumbent on a DevSecOps team to find ways to address application security issues in ways that don’t adversely impact developer productivity.

Organizations could mandate that vulnerabilities be remediated. In fact, there is a growing body of regulations that will require organizations to do just that unless they can prove the vulnerability in question cannot be exploited. The only way to effectively make that case will be to rely more on automation to document that the code running in a production environment is actually secure.

In the meantime, developers should expect to see their code scrutinized more than ever. Of course, the better part of valor is to ensure that as many vulnerabilities as possible are never introduced.

February 1, 2024
Diffblue Integrates Generative AI-Based Testing Platform With GitLab

Diffblue this week generally made available an integration between its automated unit testing platform for Java and the DevSecOps platform from GitLab.

The Diffblue Cover platform makes use of generative artificial intelligence (AI) to automatically create unit tests based on reinforcement learning technologies that don’t rely on LLMs—avoiding their drawbacks of sometimes introducing hallucinations and also requiring human review.

Diffblue CEO Mathew Lodge said the integration with the continuous integration capabilities found in the premium and ultimate editions of the GitLab platform would, for example, streamline regression testing in a way that should ultimately improve both application quality and security. Diffblue Cover, for example, can update tests as much as 250 times faster than a human developer can write them manually without developer review.

That approach also serves to reduce the level of friction many DevSecOps teams encounter when bottlenecks involving testing processes emerge, noted Lodge. The overall goal is to make it simpler for developers to test as much of their own code as possible before integrating it into a build, he added. Otherwise, developers will get fed up because testing is continuously breaking the build, noted Lodge.

Ultimately, instead of having to write unit tests, developers become supervisors of a platform that automatically generates them on their behalf, said Lodge. The job of a developer doesn’t go away, but it does fundamentally change, he added.

To achieve that goal, developers need to be able to access a platform that writes the tests and can then also execute them automatically. If it takes too long to create the test, chances are high that most developers won’t run it. On average, writing and evaluating a single unit test can take a developer 10 minutes. Over the course of any project, thousands of tests need to be written, so the amount of time testing takes away from coding is often much greater than most IT leaders fully appreciate.

Automating those tests should improve developer productivity as more time is available to focus on writing code rather than testing. That doesn’t necessarily eliminate the need for a dedicated testing team, but it does mean that more tests will be run without slowing down the overall pace of application development.

Developers naturally want to be able to test code at the very instant they create it. AI platforms can make that happen by, for example, employing reinforcement learning to write unit regression tests.

Most developers are not going to resist assuming more responsibility for testing if the tools to automate that task are more accessible. Instead of merely shifting responsibility for testing left toward developers, DevOps teams need to find ways to streamline the process. Otherwise, testing just becomes one in a series of tasks that are being shifted to developers in ways that many of them are coming to resent.

It may take some time before AI is fully integrated into software engineering but it’s clear with each passing day more previously manual tasks are being automated. Among the lowest hanging fruit for applying AI to software engineering are clearly testing processes that, if truth be told, few indeed enjoy conducting.

January 25, 2024
5 Security Threats DevOps Teams Should Know

DevOps security, also known as DevSecOps, is a philosophy in which security practices are integrated into the DevOps process. DevOps security involves creating a ‘security-as-code’ culture with ongoing, flexible collaboration between release engineers and security teams. The DevSecOps movement, much like DevOps itself, is focused on creating new solutions for complex software development processes within an agile framework.

DevOps security is about breaking down silos and promoting open collaboration across teams. It’s about making everyone accountable for security with the ultimate aim of improving the quality and speed of code releases. The adoption of a DevOps security model necessitates a cultural shift across the organization. It requires the integration of security into every aspect of the development and operations processes.

DevOps Security is not just about implementing tools and technologies; it’s about changing the way we look at security. Rather than being an afterthought, security should be a key part of the ongoing conversation from the start of the project to the end.

5 Security Threats DevOps Teams Must Know About

As a DevOps professional, it’s crucial to be aware of the potential threats that could compromise your systems, applications, and data. Let’s take a look at the top five security threats that DevOps teams must be aware of.

Phishing Attacks

Phishing attacks are a common security threat that can lead to data breaches. These attacks involve cybercriminals impersonating legitimate organizations to trick individuals into revealing sensitive information, such as passwords and credit card numbers.

Phishing attacks can be particularly damaging for DevOps teams. They can lead to unauthorized access to development systems and data, which can lead to devastating supply chain attacks. For example, an attacker could trick a team member into revealing their login credentials for a critical system, allowing the attacker to gain access and inject malware into a CI/CD pipeline.

Code Injection

Code injection is another common security threat that DevOps teams must be aware of. This involves the exploitation of an application by injecting malicious code. The attacker can then execute the malicious code to compromise the system or steal sensitive data.

For DevOps teams, code injection attacks can be particularly harmful. These attacks can lead to compromised systems and applications, resulting in data breaches and significant downtime.

Man-in-the-Middle Attacks

Man-in-the-middle attacks are a type of security threat where the attacker intercepts and potentially alters the communication between two parties without their knowledge. This can lead to a range of damaging outcomes, including data theft, session hijacking, and even identity theft.

For DevOps teams, man-in-the-middle attacks can be particularly problematic. These attacks can lead to compromised systems and data, and even the unauthorized alteration of code.

Container Vulnerabilities

Container vulnerabilities are a significant security threat for DevOps teams. Containers are a key technology in the DevOps world, allowing for the rapid and reliable deployment of applications. However, like any technology, they come with their own set of security risks.

These vulnerabilities can range from use of insecure images, to misconfigurations and software bugs, to more serious issues like kernel exploits. If an attacker is able to exploit a container vulnerability, they could potentially gain control over the entire system.

DDoS Attacks

Last but not least, distributed denial-of-service (DDoS) attacks are a significant security threat that DevOps teams must be aware of. These attacks involve overwhelming a production environment with traffic, causing it to become unavailable to users.

For DevOps teams, DDoS attacks can be particularly damaging. Not only can they lead to significant downtime, but they can also result in lost revenue and damage to the organization’s reputation.

How to Mitigate These DevOps Security Threats

While these security threats are concerning, there are effective strategies and techniques that can be used to mitigate them.

Implement Email Security Practices and Tools

To combat phishing attacks, it’s crucial to implement email security tools that can detect and block phishing attempts. These tools can help to filter out phishing emails, reducing the likelihood that team members will fall victim to these attacks.

In addition to implementing email security, it’s also important to provide security awareness training for team members. This training should cover the basics of cybersecurity, including how to recognize and respond to phishing attempts.

Use Input Validation and Sanitization in Applications

To protect against code injection attacks, it’s important to use input validation and sanitization in applications. Input validation involves checking that the data provided by a user meets certain criteria before it’s processed by the application.

Input sanitization, on the other hand, involves cleaning up the data to remove any potentially harmful elements. This can help to prevent malicious code from being executed within the application.

Employ HTTPS and SSL/TLS Encryption for Data in Transit

To guard against man-in-the-middle attacks, it’s important to employ HTTPS and SSL/TLS encryption for data in transit. This ensures that any data being sent between the user and the application is encrypted, making it much more difficult for an attacker to intercept and read the data.

Regularly Scan Containers for Vulnerabilities

To protect against container vulnerabilities, it’s crucial to regularly scan containers for vulnerabilities. This involves using tools that can analyze the containers and identify any potential security risks.

By regularly scanning containers, DevOps teams can identify and address vulnerabilities before they can be exploited by an attacker.

Implement Rate Limiting and Network Filtering

Finally, to mitigate the risk of DDoS attacks, it’s important to implement rate limiting and network filtering. Rate limiting involves restricting the number of requests that a user can make to the application within a certain period of time.

Network filtering, on the other hand, involves blocking traffic from certain IP addresses or ranges that are known to be associated with DDoS attacks. This can help to reduce the impact of a DDoS attack and protect the availability of the application.

In conclusion, DevOps security is a crucial aspect of the DevOps process. By being aware of potential security threats and taking steps to mitigate them, DevOps teams can significantly reduce the risk of a security breach and ensure the ongoing success of their projects.

January 25, 2024
Survey: Widespread Inability to Remediate App Vulnerabilities

A survey of 621 IT and security professionals published this week found only 20% are confident in their ability to detect a vulnerability before an application is released.

Conducted by the Ponemon Institute on behalf of Security Journey, a provider of cybersecurity training services for developers, the survey finds 61% struggling to remediate vulnerabilities effectively, with 55% blaming misalignment between development, security and compliance teams for delays.

A third of respondents (33%) said teams lacked a common view of applications and assets, with 38% acknowledging they lack the ability to hold departments accountable for patching applications. Only 11% of organizations believed they patch vulnerabilities effectively in a timely manner, the survey finds.

In the 12 months prior to the study, 54% of respondents suffered a security incident due to an unpatched vulnerability, with 51% experiencing more than eight incidents.

Overall, half (50%) admitted they fail to test the security of their applications after they have been released. Only 36% specifically teach developers to write secure code. Just one-fifth (21%) educated developers on vulnerability remediation. Less than half (43%) have invested in training provided by a third party.

When training is provided, 68% of respondents also admitted immediate feedback is not provided and less than half (47%) said secure coding training is customized to meet developer needs. Half (50%) of those who provided training have no formal assessment to measure knowledge gain, the survey found.

Amy Baker, chief marketing officer and security education evangelist for Security Journey, said the survey makes it clear much work still needs to be done in terms of teaching developers how to write secure code.

In addition, too many software development teams are overly optimistic about their ability to remediate known vulnerabilities the next time they plan to update an application, said Baker. Many developers move on to the next application simply because either the pressure to meet delivery deadlines is too intense or there is some other emerging technology, such as large language models (LLMs), that needs to be learned, she added. In fact, too many organizations are far too focused on the rate at which applications are built and deployed at the expense of cybersecurity, Baker noted.

That’s especially problematic because cybercriminals have become much more adept at monitoring application deployments and updates, she added.

The amount of time between when code is deployed and when cybercriminals begin scanning it for vulnerabilities is now measured in hours rather than days. Developers, unfortunately, are deploying more insecure code than ever. In fact, much of that code is insecure by design, noted Baker.

Overall, nearly half of respondents (48%) only train developers annually, bi-annually or when an incident occurs. More than two-thirds (68%) only train developers on how to implement secure coding practices to meet compliance requirements. In effect, because developers are not taught security in school, what training they do receive is on the job, said Baker.

Clearly, there is still much work to be done when it comes to implementing DevSecOps best practices to improve application security. In the meantime, the amount of code that needs to be patched has already reached proportions that most application development teams are never going to be able to effectively address.

January 24, 2024
Mobb Extends DevSecOps Reach of Tool to Generate Patches

Mobb today added an ability to instantly surface patches for vulnerabilities at the time when code is being committed during a DevSecOps workflow.

Previously, the tool provided by Mobb to create validated patches based on the scan results of third-party SAST tools would only surface issues to individual developers.

Mobb CEO Eitan Worcel said organizations can now address these issues within the context of DevSecOps workflow.

The Mobb platform combines proprietary security research and traditional semantic analysis with generative artificial intelligence (AI) to automatically create patches for vulnerabilities. The overall goal is to make it simpler for DevSecOps teams to consistently ensure applications with known vulnerabilities are remediated before they are deployed, said Worcel.

The Mobb approach eliminates the need for IT teams to sort through static application security testing (SAST) scans themselves. Each vulnerability typically requires at least 30 minutes to fix, so the Mobb platform improves application security while simultaneously making developers more productive.

Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool automatically creates the necessary patch, so there is less of a need to debate which vulnerabilities are worthy of the time required to create a patch.

For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing software supply chains as part of a larger effort to improve application security.

There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that address common vulnerabilities.

The process by which patches are prioritized, developed and then applied has, of course, long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities. The challenge is finding a way to remediate vulnerabilities that developers will embrace rather than resist. The Mobb approach still provides them with control over what patches are applied but the toil involved with creating a patch in the first place has been substantially reduced.

It’s not clear how long it might be before automated approaches to building patches might improve the overall state of application security but, as always, every journey needs to begin with a first step in the right general direction.

January 23, 2024
AWS re:Invent 2023: Cloud Development Environments

Speaker 1: This is Techstrong tv.

Shira Rubinoff: My name is Shira Rubinoff. I’m the chief cybersecurity officer with the Techstrong Group. I’m here with Rob Whiteley, CEO of Coder. Rob, it’s a pleasure to be with you here today.

Rob Whiteley: Yes, thank you so much for hosting me. This is great.

Shira Rubinoff: Rob, we’ve had some great conversations, and I’d love you to share with the audience who is Coder, what is your story? Please explain who you are, how you came about. Let’s go from there.

Rob Whiteley: Yeah, I hope you have about two hours. No, I’m just kidding. I’ll give you the short version.

Shira Rubinoff: Sure.

Rob Whiteley: Coder is a cloud development environment solution or CDE is sort of the industry terminology. What that basically means is we’re trying to solve the problem of helping enterprises shift their development from local laptops to more of a cloud native where you’re asking developers to access the cloud and develop there.

The idea is developing locally on laptops is expensive, it’s error-prone, and you often end up with the, “Well, it worked fine on my machine, but then when I ship the code, it doesn’t work.” So we try to solve that. We’ve been around for about seven years, and we actually started life as an open source project called Code Server, which is an IDE. We’ve since grown to have a more complete solution in this CDE space.

Shira Rubinoff: Well, that’s wonderful and certainly very needed. Let’s dive into the security benefits of this because there are many and much are needed. I’d love to for your audience to understand that.

Rob Whiteley: Yeah. Yeah. No, I’m super excited to be here because I think it’s an underappreciated element, right? So to me, if I step back, the reason why companies are investing in cloud development is for developer productivity, right? Only about a third of a developer’s time is actually spent coding. The remaining two-thirds is doing operational stuff, administrative. By going to the cloud, you get productivity gains. Great. That’s why I came.

Why I stay is usually a security benefit. What I mean by that is so many of our customers have told us that, “Well, a developer left his laptop in a cab,” or, “She did not have access when she was on the road.” So by putting things in the cloud, it allows you to connect from any device, and it gets source code off of laptops. That’s now a major source of intellectual property for most companies. The applications run your business, and so to get source code off laptops is a huge benefit.

That’s just the beginning. That’s usually what triggers. So for example, one of our large banks, it was actually the CISO that brought us in solely to solve that problem of getting source code off laptops.

Shira Rubinoff: That’s a huge problem.

Rob Whiteley: It is. I think that alone is worth it, but once you’re in the cloud, I have better access controls, I can do role-based access, I can be more thoughtful about encryption and how I secure it and whether I enforce certain forms of SSH. So there’s a lot of benefits, and I don’t think customers realize that until they’re underway. Part of what we’re hoping to do is front end that conversation a bit more. Security is actually a major driver on shifting to the cloud. It’s not just the productivity gains.

Shira Rubinoff: Certainly. Let’s talk about the no extra steps that we were discussing earlier. The human factors piece of security is a massive piece that organizations and technology companies and all types of security, and certainly with coding there’s many different steps to do in order to get to what you want to do. Where there’s extra steps and people are in a rush, they don’t want to do that. They want to circumvent it, they want to break it, they want to leave it open so they don’t have to think about it, leave passwords around, all sorts of things. So please tell me what Coder does and why.

Rob Whiteley: Yeah. No, it’s great. In fact, Coder’s co-founder Ammar, has a phrase that developers are inherently lazy. He doesn’t mean any disrespect by that. It’s just they’re-

Shira Rubinoff: It’s everybody, right? It’s the multitasking. I wouldn’t just call it coders. Coders are fabulous.

Rob Whiteley: But I think part of the coding ethos is do things as elegantly and simply as possible. That’s what makes good code. If you shift the security burden to the developer, like we in the industry love this concept of shift left, which basically means shift things earlier in the development lifecycle. What that really means is you’re asking the developer to do more, to take on more steps, to build security into his or her workflow. But that is against that ethos of being lazy and trying to do things efficiently.

I think one of the things that we’ve noticed is, let’s flip that on its head a little bit. Let’s shift to the developer right. What if we could make the developer more productive and just make security seamless built into it? They’re not having to worry about it. How does that work? Well, if I’m logging into a cloud to do my development, I’m inheriting the entire security infrastructure I’ve already put in place for my cloud, my firewalling, my access controls, my encryption, my backups, everything that keeps that environment that I’ve probably already put in production. I now automatically shift those security controls to my development environment, which again, used to be laptops, and I was very dependent on making sure my antivirus or my mobile device management kept that device secure. My developer had to battle that. They had to toil, they had to update things, they had to make sure.

We reduce that toil, but more importantly, we take the security off the plate, off the mind. If you access the cloud, it is more secure. Period. Full stop. So that’s what makes I think this work better as opposed to having to send developers through more security training. Yeah, you’ve got to write clean code and have fewer bugs, but that is what the developer should be focused on, not complying with your security policies, which is too much toil.

Shira Rubinoff: Certainly. My background is heavy in security, and I will tell you the best technologies out there have the security built in and have the no extra steps. You want something that’s better, stronger, faster, without the onus being on the user, which is the developer or somebody who has to be responsible for it. You want to make sure they’re doing their job great and they’re doing their job well without having to burden them with thinking about those extra pieces.

Just think about our daily lives. Moving a million miles an hour, and certainly the developers, that’s something they have to keep on top of mind, they have to be answering everything, running around and traveling, everything they’re doing. The last thing you want them to think about is, “Wait a second, did I do all these steps?” Because most of the time they haven’t. So that’s an excellent thing that you had certainly built in.

In terms of the competitors out there that you see or you come face when you’re at the marketplace, what would you say your main differentiators are in the marketplace?

Rob Whiteley: Yeah, sure. I think for us, there’s two primary ways these solutions get deployed. They’re self-hosted, which means you download the software, that’s Coder. So we start as open source, and you can upgrade to the commercial if you want, but you own the software, you deploy it. Or you can consume it as SaaS. The problem with this space in particular when deployed as SaaS, which is pretty much all of our competitors, is I now have a lot of very sensitive metadata about my developers. What environments are they using? What tools are they using? How often are they in those? What languages? What versions? That all could be used to exploit the application. So that metadata is now flowing out to some third party cloud, which by the way, I had to poke a hole in the firewall just to do, only for them to poke a hole right back into my environment in order to provision the developer workstation.

For us, keeping it all hosted inside your cloud, whether it’s on-premise or public, we don’t care, is what has been the biggest inherent differentiation. I love SaaS. SaaS is the future, but in an early adopter market like this, there’s a clear leaning towards self-hosted. Most of these organizations can run software as well as a cloud provider anyway, and so they would rather just do it themselves. So that’s difference one.

The second one I would just say is the majority of solutions in this market, and again I’ll call this the CDE or cloud development environment, is they’re designed with the operator in mind, the backend DevOps team that has to own the infrastructure. We’ve tried to approach it from the developer. What’s going to create the best developer experience? Because one of the things that you hinted at is if you make things difficult, it will not get adopted.

Shira Rubinoff: Correct.

Rob Whiteley: We don’t live in a world where we can force developers anymore. They pretty much have to opt in. So if it’s not a good experience, they just won’t adopt that structure.

Shira Rubinoff: Well, that’s the mindset of developers, and it’s very good that you’re honed in on that. A lot of people are like, “Well, this is what we do for everybody else.” I like the fact that you’re really honed in to what do the developers do? How do they like to work? And work along the path of that. When they talk about security in general or how operating anything really works is think about your user base, work the way they work, and build the security around that.

Rob Whiteley: Exactly.

Shira Rubinoff: Don’t try to force them into something. So that’s key.

Rob Whiteley: Yeah, exactly. So our mindset’s simple. If you make the developer experience clean and you take security friction out of it, they will adopt it. Then you finally benefit from all those advantages we talked about. The worst thing I think you could have is you deploy the solution and they just continue to work on their laptop as if nothing’s changed because they found the new thing too difficult.

Shira Rubinoff: Right. True. I know you had some really interesting announcement that came out in September. I’d love you to reiterate that and tell our audience a little bit about that and also hint about some new things coming down the pike.

Rob Whiteley: Yes. Yes. We’re very excited.

Shira Rubinoff: If you could give us a little bit of a sneak peek here.

Rob Whiteley: Yeah, back in September we announced something called the Coder Registry. Think of that as a marketplace for Coder plugins. The reason why that’s important is because we believe in developer choice. Developers should choose the tools that make them most productive. What we’ve done is we’ve created this registry so that anybody in the developer tooling ecosystem can write a plugin to Coder. If you want to be able to provision your tool to a developer … Because we sort of own that developer eyeball, if you will … We are the thing they log into to do their work so we can merchandise different tooling. If you want to use a code gen AI tool for assistance, we can make that. By doing these plugins, we’ll create a much more, I think, robust ecosystem where it is not on the developer to do that integration.

We’re just a tile they can click on now to say, “I want that tool.” But we still give the platform team the chance to curate that. If they don’t want to introduce that tool, then they can just kind of exclude that from the developer’s pick list. That registry is what we announced. We’re building more and more third party support for that. That’s sort of the big thing. So that was big announcement.

What I can say for next year that I think is going to be most exciting is we’re really trying to focus on how do we make these platform teams that are responsible for making developers productive, for helping secure source code, and really equip them with a much more advanced set of insights. One of the things that Coder does is we collect a lot of that metadata, and like I said, we don’t beacon it to the cloud. It stays local to your environment.

Shira Rubinoff: That’s important.

Rob Whiteley: Well, that’s a rich data set. There’s a lot we could do with that data set to help make operators’ lives easier. One of the things we’ll be looking at next year early is how do we expose that in a way where maybe you can figure out, “If I increased the amount of compute, what would that correlate to for an outcome?” By kind of front-ending that we can make it a lot easier for operators. Again, if we can remove friction from the developer experience, they will adopt it. So that’s part of what we’re looking at.

Shira Rubinoff: Well, that’s very exciting. Everyone stay tuned for that announcement coming up. Anything else you want to add for our audience? Anything that they should take note of or any helpful hints around anything around the AWS Conference or your company itself that you’d like to share with us?

Rob Whiteley: Yeah, I think the biggest thing would be … So the cloud development environment is new. It’s an emerging market. I think a lot of companies are not necessarily investigating it because they think it’s not right for them, or they don’t want to fit force developers to change behavior. I think what we’ve experienced is every customer that does it has quickly expanded. To me, my biggest call to action is just go look at it. I mean, it’s free. It’s open. You can get started. I’m not even asking you to purchase anything.

But I think just shifting the behavior from local to cloud, getting those security benefits and demonstrating that win back to the business is the first step in I think what’ll be a sea change in arguably the last mile the cloud has not effectively touched yet, which is developers. Production environments have been in the cloud for a while now. Development environments are next. So I think now’s the time to get started.

Shira Rubinoff: Well, that’s wonderful. Thank you so much for sharing your insight with our audience.

December 22, 2023
Shared Responsibility? Yeah.

One of the things that the last decade or two of enhancements has brought about is an increasing reliance on everyone across the organization to be more secure. While users have long since thrown up their hands and looked for ways to minimize the fallout when a vendor they frequent is compromised, enterprises have to lock down their own things. And given the ever-increasing volume and sophistication of attacks, the demands are growing.

Cloud brought us the concept of a ‘shared responsibility‘ model. It is necessary in a world where an org does not control the physical servers and supporting infrastructure that applications ultimately run on. The fact is, the shared responsibility model was really cloud vendors reminding us that we still have to protect our apps, no matter where they’re deployed.

This model and DevOps together have driven us to demand more of developers and DevOps teams with regard to security. It has also driven ops to have to care more, as more is exposed and security demands are up while security staff isn’t.

And I’ll just remind you of the obvious. If you are responsible for security at the organization, you can get help from everyone, but those people’s job and direct responsibility is not security. They’re lending a hand because everyone cares, and that is the current state of most enterprises – DevOps made everyone involved in the SDLC a bit more responsible for all the things that aren’t their jobs (often a very good thing, often … not), but they’re not specially trained for it. That’s what security teams are for. And high-quality development security/policy management tools offer Dev and Ops and everyone in between a bit of guidance to good security practices along the way. I’ve praised putting security feedback right in the IDE half a dozen times here and elsewhere, and as a security-conscious developer, will continue to do so until it is so pervasive that people start to worry I’m losing it by going on about it. That’s a great example of helping everyone be more secure without requiring a ton of security staff hours in training. Developers don’t purposely write insecure code any more than they set out to make buggy spaghetti code. Giving tools to help them make the code more secure is a huge bonus – to them and to the corporate security team. So, if you’re not using them, start. And look into all of the other options to help non-security staff lock down their bit. The number of available security people on the market is perhaps the largest it has ever been (It’s so bad I actually know a security researcher who took months to find a new gig – that is pretty much unheard of or a unique case before recent days), but budgets to grow the security team aren’t there – any more than they are currently there to grow most teams. So tools to help are still imperative because you’re not going to get double the security staff in 2024 unless there’s only one of you … and you threatened to quit if they don’t get you help, which no one recommends as a negotiation tactic, so even if you’re solo, no doubling for you.

Just remember who is responsible for overall infosec. Make use of the specialist and their knowledge in their space by finding tools to help them secure in a manner that matches workflow. Then verify because the organization’s security posture is security’s job.

And keep rocking it. We’ve got so much cool stuff going on at the moment in IT in general that there is plenty of opportunity to improve architectures that are even relatively recent. Check what you have, consider it from a security perspective, improve what you have and keep rolling along.

But first, relax, take a breather, and enjoy the holiday period.

December 20, 2023
KubeCon: DevSecOps and Generative AI

Speaker 1: This is Techstrong TV.

Alan Shimel: Hi, everyone. Alan Shimel back here at Chicago KubeCon, North America 2023. If you’ve watched our coverage of past KubeCons or RSA or even sometimes on Techstrong TV, you know this fellow right here, he’s my friend, David DeSanto. David, is the… Is it Chief Product Officer?

David DeSanto: Chief Product Officer.

Alan Shimel: Yep, at GitLab. And GitLab always has something doing, especially if it’s the 22nd of the month, right?

David DeSanto: Correct.

Alan Shimel: How many consecutive 22nd of the month releases are we up to now? Do you know?

David DeSanto: Over 150. I know that.

Alan Shimel: Over 150.

David DeSanto: Yeah.

Alan Shimel: But GitLab is also a big community member of CNCF, as well as a bunch of the other Linux Foundation-

David DeSanto: Absolutely.

Alan Shimel: Foundations as well. And David’s always a wealth of information. So David, I hope I didn’t put too much pressure on you, but welcome.

David DeSanto: It’s fine. Thank you for having me.

Alan Shimel: Always a pleasure. So let’s first talk a little bit about the show.

David DeSanto: Yeah, absolutely.

Alan Shimel: GitLab is here. What are you seeing, hearing? What are you thinking about?

David DeSanto: Yeah, so I would say this probably is no surprise to everyone who’s watching, but this year it’s all about security and AI. And sure enough, at GitLab’s booth here, we’re booth M1, it’s also about…

Alan Shimel: Security and AI.

David DeSanto: Security, AI, and visibility.

Alan Shimel: So we’ve been talking a little bit about security and AI too. Surprise. And one of the… We actually, just a quick plug. We actually have a great virtual event coming up in December on AI, and it’s sort of where does AI meet, rubber meet the road. And I want to turn that around to you, David. Look, AI has tremendous potential to help, I think, with security.

David DeSanto: It does.

Alan Shimel: I don’t know how much of it is real today. I think a lot of it will be real, certainly. But what’s real today? No holds barred. What’s your take?

David DeSanto: Yeah, so maybe we’ll start with the AI part of that and then tie it into security. So I always look at new technology through the lens of my parents. They’re both much older than I am. And to them, when I showed them AI, it was magic because to them-

Alan Shimel: It really was.

David DeSanto: How is that happening, right? But then I also had to help ground that in reality for them to say, “Well, this is generative AI. It works by predicting the next word based off the series, right?”

Alan Shimel: Putting one foot in front of the other, right. It’s not sentient.

David DeSanto: When you look at it though, some people have thought it’s sentient.

Alan Shimel: No, your parents, I go by my wife’s sister, she’s 74, and yeah, she thought there was a little person in there, but yeah.

David DeSanto: Yeah, and actually just as a quick note, and the viewers will love this, but I introduced them to it at my sister’s wedding earlier this year. I needed to do a toast. So I had Bard generate the toast for me. And they were like, “How is this happening?” Right?

Alan Shimel: They’re beautiful, I hear you.

David DeSanto: But to kind of ground in reality and you realize how generative AI works, you have to then ask yourself what are the best use cases to apply it to? It’s not going to be able to tell you how many pages there are in a book, how many words are in a book. Those aren’t things that are questions it can build, right? But it can help you with tasks that can sometimes be mundane. It can help you with understanding something better. And that’s how I kind of tie it back to AI. So when GitLab started applying AI to our platform, we started in 2021 with code review because that was a huge pain point helping customers get through code review. The next area we looked at was actually security.

Alan Shimel: Really?

David DeSanto: And the reason why we did that is that GitLab is, in essence was a developer platform when we started, we’re an enterprise DevSecOps platform today.

But it was about helping developers be more effective. And developers don’t start their day off by saying, “You know what? I want to write a zero day vulnerability in the application today. I want to make it super vulnerable.” Right? They want to write really good code. And so we said, “We’ve helped shift security left. How do we help now those developers understand that security they’re seeing?” And so we launched at RSA this year, explained this vulnerability where it actually explains the vulnerability, natural language using AI gives them an example of how that vulnerability is exploitable. And it gives them an example of how to resolve it. And those code snippets it shows are in the language the developer’s writing it. And so when I think about AI and security, I think about it making security truly approachable. And if you can do that, then everyone starts to win.

Alan Shimel: So I would give you guys the Oscar for best use of AI, right? Because I think that’s where it shines. I had a very similar experience with me. So I’m not a coder.

David DeSanto: And I claim to be one, but it’s been a decade plus since I’ve run any code.

Alan Shimel: But you know what? Try putting a little code into your generative AI chatbot and say, “Explain this,” or, “What does this mean?” And it goes through line by line and tells you, “That’s what this is for. This is what it’s calling, this is what it’s doing.” And you can be a complete neophyte around let’s say Python or name your language, wherever you want to do it in. And it really teaches you how to code.

David DeSanto: It does. It does.

Alan Shimel: Line by line, syntax by syntax. So to me, that’s a great use of AI. That’s what we should be using it for. It’s not Google search. A lot of people I know, they think it’s Google. It’s not Google search.

David DeSanto: No.

Alan Shimel: But those kind, and it’s good for writing toasts for a best man or whatever, or an anniversary as someone in my office I know used it and his wife called him on it. But anyway, it’s really great for learning tool. Now, when we talk about AI and security, though, there’s an evil dark side to it.

David DeSanto: There is.

Alan Shimel: Which is how do you secure AI?

David DeSanto: Yeah. And so I love that question. So the first time we spoke, which now is four or five years ago, the question you asked me is, “GitLab and security, explain that.” And we talked about why we’re taking that journey. And today, GitLab is recognized as a security player in the space.

Alan Shimel: Absolutely.

David DeSanto: And it’s one of those things that we are very proud about because we helped define what shift left actually meant. And so if you bring this back to AI, the one thing I always tell people is that, yeah, code generation can be scary. You’re not sure, is it writing good code? Is it writing functional code? But if you’re using GitLab, that code gets committed back into your CICD pipeline and the GitLab security scanners run. And now you know that vulnerability has been resolved and nothing new has been introduced. And so if you pair AI with the right things around it, it can be truly powerful. But you’re right, if you’re not doing that and you’re thinking it is the person living inside the machine, you give a little too much trust to it today. AI is not a hundred percent there yet.

Alan Shimel: Absolutely. Well, so that’s the next segue. Don’t give up any secrets. Let’s not get in trouble. You’re a public company now, but where do you see AI going with GitLab specifically over the next, let’s say between now and RSA in May or something like that?

David DeSanto: Yeah, great question. So fortunately, we’re a very transparent company, so I can talk about roadmap and not get in trouble, but thank you for making sure that I don’t get myself in trouble with legal.

Alan Shimel: Or me.

David DeSanto: So where we see AI going with GitLab is there’s really two paths that we’re exploring. The first is GitLab Duo Chat. We released it back in June, it continues to mature. We’re seeing people gravitate towards wanting to talk to chat and not necessarily click a button in the UI or engage with AI that way. And it makes sense. If you think about it, we’re humans, you and I are talking, we’re having a conversation. That’s how we’d want to engage with it. And that’s why the chatbots are so popular.

And so what we’re looking to do is continue to take what we’ve released. We have 14 AI features today.

Alan Shimel: Really?

David DeSanto: Yeah. Everything from, GitLab is for the entire SDLC. So we have AI assistance in planning, coding, securing, deploying, the whole way across. And so we’re slowly moving those features into chat. An example that explained this vulnerability is a great example. So that’ll be available in chat here shortly. And the reason why we’re doing that is the natural thing is, “Well, help me resolve it. Here’s my code.” And so we want to help AI be not just a pair programmer for the developer, but be that trusted partner that can help write more secure codes. So I would say over the coming several months going into RSA, you’ll see a lot of AI and security and our Duo Chat feature coming together.

Alan Shimel: I love it.

David DeSanto: The other area is our-

Alan Shimel: Wait, hold on one second.

David DeSanto: Oh, sorry. Yeah, go ahead.

Alan Shimel: I want to make sure Duo Chat, not everyone out here is going to know Duo Chat.

David DeSanto: Yeah, so perfect. Yeah. So GitLab Duo is the name of our AI workflows within the GitLab platform.

Alan Shimel: Got it.

David DeSanto: The name is based off the fact that it’s you as a user, plus AI makes the AI dynamic duo.

Alan Shimel: A duo. Okay.

David DeSanto: It also helps that I’m a huge Batman fan and dynamic duo has that in it.

Alan Shimel: All right. I love it. I love it.

David DeSanto: I didn’t tell marketing that though.

Alan Shimel: No, no, no.

David DeSanto: No, no. No. Hopefully they don’t watch this. They’ll now know my secret.

Alan Shimel: What does marketing ever? I’m only kidding. I’m only kidding. I love my marketing people.

David DeSanto: So that’s the name of the suite of those AI workflows. And so there are things like explain this vulnerability. You’re explaining of codes for, we actually haven’t explained this code.

Alan Shimel: I love it.

David DeSanto: We’ll explain the code. We have our code suggestions, which is going to generate either code completion, your cursors in the file, it’s reading what’s before and after the file’s open and recommending code.

Alan Shimel: I love that.

David DeSanto: Or code generation where you can actually do comment decode, that’s actually the most popular for our users. As well as things in helping you do your planning, summarizing conversations, helping with CI configurations and beyond. So that’s what GitLab Duo is, and Duo Chat is part of that. And so that’s the chatbot you can launch within GitLab’s UI.

Alan Shimel: Now, is there a way to kind of implant this into your IDE, or?

David DeSanto: And that’s the last thing I was going to mention that we’re working on. Yeah. So the other thing-

Alan Shimel: You didn’t pay me to say that.

David DeSanto: I did not.

Alan Shimel: Okay.

David DeSanto: I did not.

Alan Shimel: Go ahead.

David DeSanto: It’s almost like you read our GitLab issues and read our roadmap.

Alan Shimel: We may not coordinate our wardrobes. But we do-

David DeSanto: We didn’t. I do wish I would’ve worn the fall shirt today.

Alan Shimel: Next time.

David DeSanto: We will. Next time we’ll do that.

Alan Shimel: All right.

David DeSanto: But anyway, we’re going to be bringing Duo Chat to the IDEs. So today we have it as an experimental feature and we’re trying it at GitLab today to make sure it works. But it’ll be available in all the IDEs that we support today, including the JetBrains Suite, Visual Studio, VS Code, Neovim, and the GitLab IDE.

Alan Shimel: I love it. I love that. Fantastic.

David DeSanto: But by the way, that’ll also then bring those same actions that are in the GitLab UI into chat in your IDE, so you can actually explain the vulnerability, explain the code, all those things directly where you’re working. You don’t have to leave your IDE to get that.

Alan Shimel: While we’re on this subject. A lot of people out here, look, there’s so much, there’s so much controversy around AI. Is it going to kill off humanity? Is it going to take everyone’s jobs away? Is it going… My feeling is, it’s not… Will it do some jobs? Yeah, but for the most part, it’s going to make a lot of people who do these jobs 10x more effective. How do you view it, and how does GitLab view this, in a world where chat and Duo Chat is built in and AI is built into the entire GitLab SDLC pipeline.

David DeSanto: Yeah.

Alan Shimel: Does it really 10x these people?

David DeSanto: So that’s our target. And to give a little context for everyone, GitLab Ultimate, which is our top tier, includes every future GitLab has including AI. We did a survey of our customers. We had an independent company do that. They found that people using GitLab Ultimate get a 7x boost in efficiency for their organization.

Alan Shimel: So you’re over halfway there.

David DeSanto: Yeah. And an ROI within six months of what they paid for it. And so when we asked ourselves, “How does AI help?” We set ourselves a 10x goal. So continuing to accelerate that efficiency. And our customers using GitLab today and GitLab Duo are talking about that. They’re talking about getting through code review faster. They’re talking about resolving vulnerabilities faster. And to the first part of your comment, we don’t see AI as a replacement for your team members. We see it as helping them be more effective, removing some of the mundane tasks that can slow them down and unlocking their true potential.

Imagine a world where your developers don’t have to worry about doing things like creating the template for the code and now they can just go in and write the actual strategic parts. And same thing across the entire software development lifecycle. I personally benefit from Duo almost on a daily basis, in that as the CPO of the company, I get pinged on our GitLab issues or GitLab Epic or whatever, and someone will say, “What are your thoughts on this?” And I’ll look at it and I go, “How long is this?” And I’ll go up and say, “PDF it.” And it’s like it’s a hundred pages, the issue’s been open eight months.

Alan Shimel: Summarize.

David DeSanto: Customers are coming, yeah. So I say-

Alan Shimel: I do the same thing.

David DeSanto: “Summarize the discussion,” right?

Alan Shimel: We’re connected. I do the same thing.

David DeSanto: And so that’s where I see it. That made me more efficient. I now didn’t spend two hours doing that.

Alan Shimel: I’m doing the same exact… As CEO at Techstrong, I’m inundated. Inundated with content. “Should we publish this? Is this the right tone? Here’s the abstracts.” And a lot of times, and I don’t mean to sound callous, but I just don’t have the time to go through it all. But a summary, man, just give it to me in five bullets.

David DeSanto: Right. And by the way, the other part of that that I use is that it could also help generate descriptions and tasks. And so-

Alan Shimel: A bot.

David DeSanto: Right? So I’ll just say, “I read all that. I have an action, remind me to do this. Help me create the task for it,” and so forth. But you are the great example, right? Same thing with the developer, a security person. There are other things that your brainpower should be used for and why spend the time doing those things that-

Alan Shimel: I agree.

David DeSanto: Truly are not moving Techstrong forward or that company’s application for it.

Alan Shimel: We’ll come up with a, we have a theme for given event, a virtual or in-person event. We need the abstract. I can have other people write the abstract, but it doesn’t really capture my vision for it. I find just putting that into bot, into a chat, it nails it. But here’s another thing that I think is, and again, for those of you out there who don’t use generative AI yet, you should. Don’t be afraid to give it a nice long prompt or give it a lot of back. Because the more info you give it, the better it kicks back to you.

David DeSanto: It does. It actually goes off feedback and you can like something or thumbs it down.

Alan Shimel: That was another kind of revelation. And I think it’d probably work the same way with code.

David DeSanto: It actually does. So the backend of GitLab Duo is monitoring for the amount of code you keep. So do you accept the recommendation? Do you not? It also measures retention. So is that code still there after you move on? And same thing with the chat. So I’ve actually had to say to it, and there’s a joke on the internet about you have to be polite back to the chatbot. I actually just recommend it because I’ve seen that documentary Terminator with Skynet. I’m just afraid-

Alan Shimel: One day they might come for you.

David DeSanto: You want to suck up to them now, so when they take over, they remember you.

Alan Shimel: They’ll remember it.

David DeSanto: But no, I’ll actually say back, “That’s interesting, but have you thought about this? And here’s why.” And then I see that it actually learns from it because we constantly fine tune models based off that feedback. Right?

Alan Shimel: I agree.

David DeSanto: So, absolutely. Please be kind to the chatbots. GitLab Duo will always be chat to you.

Alan Shimel: Be kind to your chatbots. And be kind to everyone else, right?

David DeSanto: If it is-

Alan Shimel: Especially in this day with everything in our world going on.

David DeSanto: If it’s anything, you should be polite. There you go.

Alan Shimel: If you can be anything, be polite. Non-AI stuff, what’s your impressions of the show this year?

David DeSanto: I’ve enjoyed it so far. RSA conference used to be my favorite conference to go to. I think KubeCon is now tied for first and might sometimes edge it out. And the main reason why is that here is one of the few times I feel like it reminds me of the Black Hat Conference back in the day.

Alan Shimel: Back in the day.

David DeSanto: You’ve got all the, it is not meant to sound negative, but the doers here, right?

Alan Shimel: Yeah.

David DeSanto: You’re having real conversations with developers who are trying to understand operations better, security professionals who are here trying to make sure they’re supporting developers’, operations. Same thing with operations. So you get this really good mix of people and it just reminds me of almost like a large startup, if that’s a good way to look at it.

Alan Shimel: Yeah, no, there’s an energy that’s palpable, that I think works.

David DeSanto: But I do want to just make sure RSA, I still love you.

Alan Shimel: We’ll be there, May 6th-

David DeSanto: I’ll be there as well.

Alan Shimel: Is our DevSecOps. It’s going to be all about AI in the future of security, our event as well as the larger AI event all week. Or the larger RSA event all week. What about re:Invent? You guys are going to be at re:Invent?

David DeSanto: We will be at re:Invent. I will personally not be there.

Alan Shimel: No?

David DeSanto: No. I actually, I hit the point where this is my last whole week of the year. I’ve been gone three weeks a month for this entire year. I want to stay married.

Alan Shimel: I hear you.

David DeSanto: I want to spend some time with my dogs. And so I’m taking December and most of January off from travel.

Alan Shimel: Good for you.

David DeSanto: Yeah.

Alan Shimel: I’m getting a new dog Friday.

David DeSanto: What kind of dog are you getting?

Alan Shimel: I guess I could share it. So we’ve had bulldogs for about almost 30 years.

David DeSanto: Okay.

Alan Shimel: Our last one passed away in May. She was 14 and a half.

David DeSanto: Actually, I think you and I talked about that.

Alan Shimel: Yeah. So it took a little while for us to get back in the, I need a dog, but I need a dog. So it’s a new bulldog puppy. Her name is Kaia, K-A-I-A, which means sea in Hawaiian. Her father’s name is Ocean.

David DeSanto: Oh, wow.

Alan Shimel: And yeah, I’ll post pictures.

David DeSanto: Okay. I think I’ve shared this to you before, but we have two rescues. They’re both Chihuahua mixes.

Alan Shimel: Oh, yeah. Yeah.

David DeSanto: One’s really dumb and the other one’s really smart, so [inaudible 00:18:47].

Alan Shimel: It’s good mix. Yeah.

David DeSanto: I will tell you, when I get home, they’re so excited to see me and they get really sad when I’m packing, so.

Alan Shimel: There’s nothing like the love of a dog.

David DeSanto: I completely agree.

Alan Shimel: No doubt.

David DeSanto: But about the conference.

Alan Shimel: Yeah, we went off there, but go ahead.

David DeSanto: Completely derailed us.

Alan Shimel: Yes.

David DeSanto: So for GitLab, a couple things. So if people are watching and they’re here, they want to see it. If not, check it out after the conference on our website. We brought our product analytics feature to market. We already have some customers adopting it and we’re demoing it. And I wanted to share it here because KubeCon’s also about visibility and you can’t close the SDLC without user feedback. And so similar to how we have observability, just about the application running in production, the value stream analytics and value stream management. This is now user feedback. So as part of GitLab CICD, we can embed telemetry into the application. So when it’s deployed, it can connect back to GitLab and start giving you data about your monthly active, daily active usage, the return rate of those users.

Alan Shimel: This is available now?

David DeSanto: It is available now.

Alan Shimel: Or you’re just demoing?

David DeSanto: No, it’s available. It is available.

Alan Shimel: What do you call that?

David DeSanto: Well, we love our boring names at GitLab, it’s one of our values. So it’s just called GitLab Analytics.

Alan Shimel: GitLab Analytics. Okay.

David DeSanto: Yeah, GitLab Product Analytics to be specific.

Alan Shimel: All right.

David DeSanto: But yeah, we started using it earlier this year for our handbook and we’re able to learn about how our users use the handbook, our employees and team members. And so I’m excited how make this available because other people want to understand how their apps are being used. Long term, we’ll be able to pull in things like retention rate, user adoption journey metrics. But today it’s just those raw metrics like the active usage, return rate, the graphs of how the usage is going. But we’re very excited to be demoing it here. It’s really cool.

Alan Shimel: Absolutely. Very cool. GitLab user analytics.

David DeSanto: Yep.

Alan Shimel: David, it’s always a pleasure, my friend.

David DeSanto: Love our chats.

Alan Shimel: You know what? I spoke to you. We’re going to do another chat with David before you leave for two months with the dogs.

David DeSanto: Yeah. I will be working, for everyone. I’m not taking time, I’m just staying home. I’ll be-

Alan Shimel: Okay. You’re just not on the road.

David DeSanto: Yeah, I’ll be working from home that entire time.

Alan Shimel: I was going to say that’s a lot of vacation time.

David DeSanto: No, no, no. I did have my first big vacation since the pandemic though.

Alan Shimel: Really?

David DeSanto: Yeah, we went to Bar Harbor for two weeks and hiked Acadia National Park.

Alan Shimel: Oh, that’s beautiful.

David DeSanto: Yeah.

Alan Shimel: And when was this?

David DeSanto: End of August. Last two weeks of August.

Alan Shimel: Oh, so it’s still nice there.

David DeSanto: It was very beautiful, but-

Alan Shimel: Not really peak color season there yet. But beautiful time, summer.

David DeSanto: But we’ll definitely can connect because I’m working. I’m just not on the road.

Alan Shimel: But we’re going to have you on Techstrong TV because you guys have more news.

David DeSanto: We do.

Alan Shimel: That we can’t talk about yet.

David DeSanto: Yeah, that’s a good teaser. Everyone tune in.

Alan Shimel: That was my, that’s what we call it.

David DeSanto: For the big news. It’s the hook.

Alan Shimel: That’s what we call it in the industry. My hook.

David DeSanto: Going back to our marketing friends. That’s the hook.

Alan Shimel: All right. Hey, we better take a break here. We’re getting a little loony. We’ll be back. We’re live in Chicago at KubeCon with our friends at GitLab. We’ll be right back.

December 19, 2023
From Machine Learning to DevSecOps: Six DevOps Trends for 2024

The DevOps market is set to grow by 25% annually between 2024 and 2032, fueled by the growing demand for faster software delivery and higher-quality output. Emerging technologies like AI-driven development and serverless architectures have introduced new products in the space, while traditional processes like version control and CI/CD will be further refined. But amongst this innovation, security and quality should remain as organizations’ highest concerns. Looking into the coming year, it’s hard not to see where the DevOps industry is going based on the past year. As such, we have endeavored to provide six distinct DevOps trends we think will be particularly influential in the new year.

The Integration of AI and Machine Learning

One of the most notable trends in the future of DevOps is the increasing incorporation of artificial intelligence (AI) and machine learning (ML) into the software development life cycle. The explosion of AI technology in 2023 has set the stage for more predictive analytics in code development, automated testing and intelligent monitoring in the operations phase.

As Google’s 2023 State of DevOps Report highlighted, DevOps teams feel that AI will contribute most to analyzing data and security, alongside identifying bugs. However, a solid use case has yet to materialize for most teams, and the report shows that early adopters of AI have experienced a minor decrease in their software delivery performance and a significant decrease in their operational performance. So, it’s possible that at this stage teams are implementing AI without considering what problems they’re trying to solve, or without paying full attention to the security and quality implications.

Emphasis on Increased Productivity

While AI adoption will be driven by the underlying push for increased productivity in DevOps tools and practices, DevOps teams should focus on drawing maximum value from the existing tools that automate mundane and repetitive tasks, allowing them to focus on more critical aspects of development and operations. This will be made possible by DevOps vendors that provide enhancements to collaborative tools, simplified interfaces and more intuitive workflows, reducing the cognitive load on developers and operations professionals.

Culturally, the continuing trend towards remote and hybrid work environments is influencing productivity strategies in DevOps, with tools and practices that support remote collaboration and communication becoming vital. Cloud-based DevOps tools are facilitating seamless collaboration, allowing teams to work efficiently irrespective of their physical locations.

Alignment to Existing Cloud and Microservices Architecture

We can expect the new alignment of DevOps with cloud and microservices architectures to continue into 2024. This integration is about more than just adopting new technologies — it’s about creating efficiencies that enhance agility and revenue growth.

The combination of DevOps practices with cloud and microservices enables organizations to leverage the inherent benefits of these platforms. Cloud infrastructure is scalable and flexible, reducing overhead costs associated with physical servers. Microservices allow for rapid development, testing and deployment of independent components without disrupting the whole system. Together with DevOps automation and continuous practices, these architectures accelerate innovation and time-to-market.

This alignment of DevOps with cloud and microservices will lead to enhanced scalability, resilience, collaboration and customer experiences. By being able to quickly scale, update, and respond to demands, organizations can better satisfy customers and meet market needs, and this, in turn, will drive revenue growth and productivity.

The Drive for Higher Quality

While increased productivity and revenue generation will be a key priority in 2024, it’ll be matched by an unwavering commitment to quality. With the rising complexity of software and the increasing dependency of businesses on digital platforms, the margin for error is slimming. Quality assurance practices will become more integrated into the DevOps workflow, ensuring that each release meets the highest standards of performance, security, and user experience.

Continuous integration/continuous deployment (CI/CD) practices are evolving to include more rigorous and automated testing protocols. These protocols are designed not just to catch bugs but to assess performance under diverse and real-world scenarios. Real-time monitoring tools are being integrated more deeply into DevOps workflows, providing ongoing insights into application performance and user experience. This continuous feedback loop ensures that any issues are identified and addressed promptly, thereby maintaining high standards of quality post-deployment.

DevSecOps Maturity

In the same vein, cybersecurity will continue to be a primary concern in 2024, with core DevOps tooling and processes stepping up by incorporating advanced security features. Version control systems will take the lead here by introducing robust access controls, encryption of code repositories and integration with security testing tools to ensure that the code is not only efficient but also secure from vulnerabilities.

Security integrations in version control will become more advanced, possibly incorporating real-time scanning for security vulnerabilities, tighter integrations with identity management platforms and pattern analysis to predict and prevent potential security breaches in code.

And as AI is pioneered throughout DevOps tooling, organizations will need to consider the security implications. The Open Worldwide Application Security Project (OWASP) has predicted that data leaks, permission issues and insecure plugins could pose serious security vulnerabilities for software. Teams that can harness growth with AI in 2024 while building sufficient security through DevSecOps practices like backup and monitoring will future-proof themselves.

Speed and Security

The speed of DevOps growth, innovation and adoption is only set to increase in 2024. We’ll see teams pioneer new technologies to meet business priorities and revenue targets. In doing so, it’s very easy to jump on the AI or serverless bandwagon and assume that sprinkling it on every technical discipline will make for a bright and shiny future. While some key opportunities in the DevOps space will benefit from the acceleration and tighter integration that new technology brings, organizations looking for lasting growth will need to prioritize quality and security practices.

The key trend we’ll see in 2024 is teams getting smarter and more focused on how they apply new technology to their DevOps trajectory, delivering faster, more accurate releases that free up time to deliver ever greater value to their customers and business. So, the DevOps winners of 2024 will be the organizations that manage to balance the speed of new technology adoption with robust security.

December 19, 2023
What Will DevOps Look Like in 2024?

The last two years have been marked by significant downsizing in technology companies. As large layoffs at companies like Amazon, Meta and Google make major headlines, there is a general shift away from the “spending cash and growing fast” mindset that free capital and strong growth during the pandemic launched in the tech industry. The name of the game is to be more conservative with spending, and that mindset will drive a lot of investments in the next year. While these cost pressures may feel challenging to technology organizations, there are a few key opportunities as well. Many trends are starting, sustaining and ending, so let’s focus on the top six likely to drive changes in the industry in 2024 and beyond.

1. AI—Specifically Generative AI—Move Right on the Hype Cycle

While AI is not new, OpenAI and ChatGPT have created an amazingly accessible and powerful tool that is positioned to drive a lot of value. The hype cycle is still in full swing as dozens of new uses of the technology hit the market daily, and if you’re not trying to build a generative AI-enabled product, you’re getting asked when you will start. In 2024, we will likely see LLMs move into the trough of disillusionment as inflated expectations and projects don’t all play out. However, those organizations with generative AI products that truly deliver value to users should expect to see massive growth. Technology organizations will need to make hard decisions about AI products. You will either find traction in the next year and see huge growth or quickly find it doesn’t work and shift focus back to non-AI products.

2. Developer Experience Gains Momentum

While DX has been talked about for years, we’re seeing new investments in tools that empower developers. This trend is partially born out of a need to reduce tool and system sprawl for engineering teams, to empower teams and allow them to move faster and to improve efficiency. While you may not build or buy a DX platform, you will likely start a DX team or committee that better represents the folks building your software. This will lead to some great internal changes and key efficiencies getting attention that may have been previously overlooked. The wonderful thing about this trend is that it both brings efficiencies to the organization and makes developers’ lives easier. It’s a win-win!

3. Increased Pressure to Reduce Costs

Even for organizations that have avoided layoffs, most are seeing pressure to shift into a leaner existence. This often means critically looking at all sources of spending and taking on new projects to optimize them. Maybe a cloud re-platform can reduce hosting spend by 20%, or maybe you start looking to remove or combine SaaS tools to reduce seats. You may even see hiring freezes for critical teams. Organizations will have to embrace other trends to increase the efficiencies of their teams to meet business demands here. Don’t be surprised to hear “do more with less” become a mantra around the office.

4. Increased Accountability Through Data

While data platforms for technology organizations continue to grow, teams are finding that it’s not enough to just measure a few metrics. Organizations will be required increasingly to use the data they have to show they are delivering value. Partially due to increased pressures mentioned above, teams will need to become more predictable, and better at identifying and handling risk at every stage of development. It’s no longer enough to just build a great development engine, teams must ensure that the engine can power them to their destination.

5. ESG in Technology

Focus on DEI in technology continues to require significant investment, however, organizations are starting to consider a broader umbrella of social responsibility. This can range from considering the environmental impacts or carbon production of your servers to changing your software supply chain to avoid supporting particular organizations. These types of requirements are appearing sooner and more overtly in the software development process, and may significantly impact how teams choose to build or implement software.

6. DevSecOps Continues to Grow

There has been a renewed focus on security in recent years after some critical attacks exposed vulnerabilities in the software supply chain. It’s not surprising that security is now written into the fabric of how we build and deliver software. Teams are now expected to consider security at all stages of development from product planning to operation in production, and require additional experts, training and resources to both monitor and ensure compliance. Requirements for SaaS products continue to evolve as the last remnants of on-premises solutions evaporate, and teams should be prepared to move quickly as new threats are discovered and need to be patched.

As the technology industry prepares for 2024, it’s clear that innovation and adaptation will be the keys to success. From the continued evolution of AI and the growing focus on the developer experience to the imperative to reduce costs, increase accountability through data, embrace ESG practices and fortify security through DevSecOps, technology organizations face an exciting future.

December 19, 2023