staging-devopsy.kinsta.cloud

Tag: devsecops

  • Survey: Widespread Inability to Remediate App Vulnerabilities

    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.

  • Mobb Extends DevSecOps Reach of Tool to Generate Patches

    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.

  • AWS re:Invent 2023: Cloud Development Environments

    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.

  • Shared Responsibility? Yeah.

    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.

  • KubeCon: DevSecOps and Generative AI

    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.

  • From Machine Learning to DevSecOps: Six DevOps Trends for 2024

    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.

  • What Will DevOps Look Like in 2024?

    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.

  • Vulnerability Management for DevOps Teams: A Practical Guide

    Vulnerability Management for DevOps Teams: A Practical Guide

    Vulnerability management is a process that includes the identification, categorization, prioritization and resolution of security vulnerabilities in software systems. It involves a continuous cycle of protection to ensure that your digital assets are secure and your operations are running smoothly.

    With the rapid evolution of technology, fast-moving cloud-native systems and evolving cyber threats, it’s critical to stay ahead of the game. The goal is to close the gap between the discovery of vulnerabilities and their resolution, thereby minimizing the window of opportunity for potential attacks.

    Vulnerability management is not just about finding and fixing vulnerabilities. It’s also about understanding the nature of the vulnerabilities and the potential impact they could have on your network and systems. This understanding informs the prioritization process, helping teams decide which vulnerabilities need immediate attention and which ones can be addressed later. See this blog post for an in-depth review of vulnerability management.

    Why is Vulnerability Management Important for DevOps Teams?

    With the DevOps approach, development and operations teams work together throughout the software life cycle. This collaboration results in faster development times and more reliable software. However, the fast development cycle also introduces new security challenges. This has given rise to the DevSecOps paradigm, where developers, operations teams, and security experts collaborate during all stages of the development lifecycle.

    Here are a few reasons vulnerability management is a critical part of DevSecOps practices:

    Early Detection of Vulnerabilities

    DevOps teams are under constant pressure to deliver high-quality software quickly. However, the speed of delivery should not compromise the security of the software. Vulnerability management helps DevOps teams identify vulnerabilities early in the development process. This early detection allows teams to address security issues before they become serious problems.

    Early vulnerability detection is not just about finding vulnerabilities; it’s also about understanding the potential impact of those vulnerabilities. It involves analyzing the vulnerabilities to determine their severity and the risk they pose to the system. This analysis informs the prioritization process, ensuring that the most critical issues are addressed first.

    Building Continuous Security Into CI/CD Pipelines

    Integrating vulnerability management directly into continuous integration/continuous deployment (CI/CD) pipelines is essential for maintaining continuous security. CI/CD pipelines automate the steps in software delivery, from code integration to deployment, ensuring faster and more consistent releases. By embedding vulnerability management into these pipelines, DevOps teams can automatically scan for and address security vulnerabilities at each stage of the software development life cycle.

    Incorporating vulnerability management tools into CI/CD pipelines allows for automatic scanning of code repositories, container images, and even infrastructure-as-code (IaC) configurations for known vulnerabilities. This integration means that any security issues are identified as soon as code is committed or containers are built, not just at the deployment stage. The advantage of this approach is twofold: It reduces the risk of deploying vulnerable software, and it allows developers to fix issues in their context of development, making the process more efficient.

    Cost-Effective Development and Operations

    Implementing vulnerability management can lead to cost savings for DevOps teams. By identifying and resolving vulnerabilities early in the development process, teams can avoid the high costs associated with fixing security issues after the software has been deployed. In addition, vulnerability management can help prevent costly security breaches that could damage the company’s reputation and result in financial loss.

    Moreover, vulnerability management can contribute to more efficient operations. By systematically managing vulnerabilities, teams can avoid wasting time and resources on low-priority issues. Instead, they can focus their efforts on addressing the most critical vulnerabilities.

    Enhancing Cross-Team Collaboration

    Vulnerability management can also enhance cross-team collaboration within the DevOps environment and between DevOps and security teams. By providing a clear framework for identifying, categorizing, prioritizing and resolving vulnerabilities, it fosters a shared understanding of security issues among team members. This shared understanding can facilitate communication and cooperation, ultimately improving the software product’s security posture.

    Strategies for Integrating Vulnerability Management Into DevOps Processes

    Adopt a ‘Shift-Left’ Approach

    The ‘shift-left’ approach is a strategy that involves shifting the security measures to the early stages of the DevOps pipeline. Traditionally, security checks and vulnerability assessments were conducted toward the end of the development cycle, often leading to late discovery of security flaws and vulnerabilities.

    By shifting these security measures to the left, i.e., to the earlier stages of the development cycle, DevOps teams can catch and fix security vulnerabilities early on. This approach aligns well with the DevOps philosophy of early error detection and continuous improvement.

    Automation of Vulnerability Scanning and Detection

    Automation is at the heart of DevOps. It allows for rapid, reliable and consistent processes, freeing up the team to focus on what they do best – delivering quality code and features. Automation should also extend to vulnerability management.

    Automating vulnerability scanning and detection means integrating security tools into the DevOps pipeline that can automatically scan the code, detect vulnerabilities and even suggest fixes. This approach ensures that security checks are not skipped or forgotten and that vulnerabilities are dealt with promptly.

    Security as Code

    Another strategy for integrating vulnerability management into DevOps processes is embracing the principle of security-as-code. This principle treats security infrastructure and configurations as code, allowing them to be part of the DevOps pipeline.

    By adopting security-as-code, DevOps teams can ensure that the security configurations and infrastructure are always up-to-date and follow the best practices. Like the rest of the code, security configurations can be version-controlled, reviewed, tested and automatically deployed.

    Collaboration Between Security and DevOps Teams

    One of the key tenets of DevOps is collaboration between different teams. In a DevSecOps paradigm, this collaboration extends to the security team as well. Integrating vulnerability management into DevOps processes fosters close collaboration between the security and DevOps teams.

    The security team can provide valuable insights into the security landscape, vulnerability management tools and best practices. On the other hand, the DevOps team can ensure that these insights and tools are integrated into the DevOps pipeline.

    Continuous Monitoring and Feedback Loop

    Continuous monitoring is crucial for effective vulnerability management. Continuous monitoring ensures that the security state of the system is always known and that any changes or vulnerabilities are promptly detected. The feedback loop ensures that the insights gained from monitoring and vulnerability assessments are fed back into the development process, leading to continuous improvement in security.

    Regular Training and Awareness

    Finally, regular training and awareness are crucial for integrating vulnerability management into DevOps processes. DevOps teams should be trained in security best practices, threat landscape, and use of vulnerability management tools.

    Regular training ensures that the team stays up-to-date with the latest security trends and vulnerabilities. Awareness sessions can help the team understand the importance of security and vulnerability management, encouraging them to take an active role in securing the system.

    Conclusion

    In conclusion, integrating vulnerability management into DevOps processes is not only possible but crucial for secure and reliable systems. Adopting a shift-left approach, automating vulnerability scanning and detection, embracing security-as-code, fostering collaboration, implementing continuous monitoring and feedback and ensuring regular training and awareness are some of the strategies that can help achieve this integration. 

    Remember, vulnerability management is an ongoing process that requires commitment, collaboration and continuous improvement.

  • Synopsys Report Sees Steady Application Security Gains

    Synopsys Report Sees Steady Application Security Gains

    An analysis of the security automation practices of 130 organizations published today by Synopsys suggests significant progress has been made toward securing software supply chains in the last year. However, much work still remains to be done.

    The annual Building Security In Maturity Model (BSIMM) report found there has been a 22% increase in the number of organizations creating software bills of materials (SBOMs) this year. Additionally, there has been a 10% increase in the number of organizations tracking open source software risks.

    At the same time, there has been a 25% increase in the number of organizations that are fixing all defects found in software and a 15% increase in the number of organizations that can identify potential attackers and track attack patterns.

    The report also sees significant gains in activities related to software development practices (44%), penetration testing (35%) and compliance and policy controls (21%). Usage of application behavior monitoring and diagnostics grew 64% and monitoring automated asset creation grew 45%, respectively.

    The finding and publishing of secure design patterns, the required use of approved security features and frameworks and the use of application containers to support security goals all grew about 25%, according to the report.

    However, the report also noted that usage of possible attack lists dropped by 31%, while expert-driven tasks such as building and applying adversarial security tests declined 25% and use of centralized defect reporting dropped 18%.

    The most widely used processes are implementing security checkpoints and associated governance (91%), creating or interfacing with incident response (90%), identifying privacy obligations (88%), using external penetration testers to find problems (88%), ensuring host and network security basics are in place (87%) and automated code review tools (86%).

    Jamie Boote, associate principal security consultant for the Synopsys Software Integrity Group, said the report suggests more responsibility for cybersecurity is shifting everywhere as organizations rely more on automation to apply security controls. Application development and IT operations are, as a result, able to address vulnerabilities more proactively either before an application is deployed or as soon as a vulnerability is discovered, he noted.

    The challenge organizations will encounter when it comes to automating security processes is there is a tendency to set and forget. Once a process becomes automated, not enough organizations will reevaluate that process as the cybersecurity threat landscape continues to evolve, noted Boote.

    Of course, the rate at which security processes are being automated varies widely from one organization to the next, but the more automated they become, the less dependent organizations become on application developers who typically don’t have a lot cybersecurity expertise. All too often, application developers are rushing to meet software delivery deadlines at the expense of security best practices. Unfortunately, it’s usually only a matter of time before an issue that was avoided is later discovered in a production environment and is considerably more problematic to update, given all the dependencies between software and infrastructure that exist.

    One way or another, however, a pending wave of regulations will soon force organizations to pay more attention to securing software supply chains. The only thing left to determine in the absence of automation is how painful the reengineering of DevOps workflows to embrace DevSecOps best practices is going to be.

  • How Encryption Innovation Will Power Cloud Privacy for Developers in 2024

    How Encryption Innovation Will Power Cloud Privacy for Developers in 2024

    For developers, the surge in cloud computing adoption has brought both new opportunities and challenges. On the one hand, developers are turning to cloud services for data storage, processing and accessibility due to their flexibility, convenience and cost-effectiveness. And because the cloud takes care of these infrastructure and operational concerns, it’s allowing developers to focus on coding, innovation and delivering value to end-users. It also allows companies to scale more easily when their market grows or when new hardware becomes available.

    However, this paradigm shift has led to the accumulation of vast volumes of sensitive data on remote cloud servers—including personal, health, financial and proprietary business information. As the volume of sensitive data on the cloud continues to grow, it has naturally raised mounting security concerns, from data breaches and cyberattacks, to unauthorised access and the complexities in complying with specific industry regulations, such as GDPR or CCPA.

    For some, having to rely on the cloud provider to maintain robust security practices and data protection has also led to hesitancy in sharing data, both within and between organizations. This not only limits the potential for data-driven collaboration, research, and innovation—essentially halting progress in fields like health care, science, and social sciences—but businesses of all types and sizes could miss opportunities for cost savings, scalability, and efficiency if they’re not willing to adopt innovative technologies. There are also cases when companies are forbidden to do something by law because of privacy, again causing roadblocks.

    All of this has meant that up until now, maintaining data privacy while making the most of cloud computing has been somewhat of a balancing act for developers and companies. Companies want to fulfill their clients’ needs, while developers have to find technical solutions that provide the level of privacy required.

    Traditional Encryption methods Vs. Fully Homomorphic Encryption (FHE)

    Currently, there are several technologies and practices employed to protect data in the cloud, one of the most commonly used being traditional data encryption, which provides protection only during data transmission and storage.

    However, when data is processed, it must be decrypted—at which point it can expose data to eavesdropping, rendering it susceptible to potential threats. The aim of FHE is to ensure that the computations can be carried out on cloud-based machines while the data itself remains encrypted. With FHE, the data is really encrypted end-to-end: not only is it encrypted during transport and storage, but also it is encrypted during computations. It is only when the data or results are sent back to the client side that they are decrypted.

    This means that in the event of a data leak, the exposed information would be rendered meaningless without the decryption key, which stays securely in the hands of the owner. In other words, neither the cloud provider nor any potential spyware on the cloud machine would have the capability to decrypt the encrypted data.

    This approach, which ensures sensitive data remains encrypted throughout its entire life cycle on the cloud, even during processing and analysis, significantly enhances data security and privacy.

    Current Limitations and FHE’s Future Developments

    While developers using traditional cloud services previously had to decide whether to use the cloud with some privacy concerns or forgo its benefits altogether, with FHE we are starting to see a possible shift in attention from users’ reliance on the cloud provider to a more user-controlled approach.

    As FHE becomes more widespread, users gain the ability to make their computations over any cloud provider, even those they may not fully trust. This means the upfront costs of building new cloud platforms can be lowered by providing only FHE computation.

    While the encryption of data ensures that computations are secure and no unauthorized access or breaches can occur, this new tech is not without its limitations. For the enhanced security FHE offers, there may come a trade-off of longer execution times. Presently, we are mainly reliant on CPUs for computations. However it’s worth noting that as the technology advances and hardware accelerators become available, the execution time is expected to improve in the future. In fact, we anticipate that by 2026, FHE implementations will see a considerable increase in speed, potentially by factors of 100x or 1,000x, expanding the applicability of FHE to a wider range of use cases.

    Other benefits currently being worked on include usability. FHE had a reputation of being very complex and so used to be reserved for those with cryptography PhDs. By developing open source tools and extending the community’s knowledge around FHE, the aim is to democratize FHE so that anyone can use it, companies can experiment free of charge and check if it fulfills their needs.

    Looking to the future, privacy will likely remain high on the agenda for almost everyone. Thankfully, with new encryption technologies rapidly developing in terms of speed and usability, developers look set to achieve this, ensuring their cloud-based applications and services are as secure as possible.