devopsy.kinsta.cloud

Category: DevSecOps

  • Cycode Discloses GitHub Actions Vulnerability in Google Bazel Project

    Cycode Discloses GitHub Actions Vulnerability in Google Bazel Project

    Cycode today revealed it discovered a command injection vulnerability in the way the GitHub Actions continuous integration/continuous delivery (CI/CD) platform was used to update the open source Bazel project that many organizations employ to build and test software.

    The vulnerability, now remediated, could have been used to create a backdoor through which malicious code could have been inserted into a codebase that is managed by Google.

    Cycode researchers shared their discovery with Google, which has since updated the way it employs GitHub Actions to manage the Bazel codebase. Specifically, Google updated the base permissions to embrace least privilege principles to resolve the vulnerability discovered by Cycode.

    The vulnerability was discovered using RAVEN, an open source tool for scanning CI/CD platforms for vulnerabilities that Cycode makes available.

    Elad Pticha, senior security researcher for Cycode, said the vulnerability is the latest example of an instance of an open repository for building software that has been shown to be potentially vulnerable to an attack on a software supply chain that could theoretically impact any number of downstream applications and projects, including Kubernetes, Angular and platforms and services provided by Uber and LinkedIn.

    A Custom Actions capability that enables application development teams to create their own workflows presents any cybercriminal attempting to compromise of software supply chain with a tempting target, noted Pticha. A few changes to lines of code in a workflow can translate into thousands or even millions of lines of code, many of which an organization may never detect. Out of 3.4 million workflows examined by Cycode, nearly all (99%) make use of one or more Custom Action.

    Cycode has previously identified dozens of vulnerabilities in open source projects by mainly focusing on vulnerabilities within workflows. This latest research shows those vulnerabilities extend to indirect dependencies, such as Custom Actions, noted Pticha.

    Each DevOps team should review its own workflows for similar vulnerabilities at a time when more cybercriminals than ever are intent on compromising software supply chains. While many organizations have embraced DevSecOps workflows to improve application security, there is a natural tendency to overlook vulnerabilities that might exist in the workflows used to build and deploy software. The challenge is that DevSecOps workflows are still immature. A recent survey of 500 U.S. CISOs, AppSec directors and DevSecOps team members conducted by Cycode found 78% admitted application security attack surfaces are unmanageable, with 90% acknowledging relationships between their security and development teams need to improve.

    It’s not apparent if the vulnerability discovered by Cycode was actually ever exploited, but as most cybersecurity professionals know, if it can be imagined, someone has tried it. As such, any organization that uses Bazel might be well-advised to conduct a code review.

    In the meantime, it’s already apparent that regulations pertaining to securing software supply chains are only going to become more stringent in the months ahead. In the wake of the executive order from the Biden administration requiring federal agencies to lock down their software supply chains, it’s now only a matter of time before similar requirements are baked into legislation and various other regulations are implemented. The challenge and the opportunity now is to get ahead of this issue before a mandate with a hard deadline that can’t be ignored winds up disrupting the entire software development life cycle.

  • Snyk Acquires Helios to Extend Reach of ASPM Platform

    Snyk Acquires Helios to Extend Reach of ASPM Platform

    With its acquisition of Helios, Snyk plans to add an ability to capture application runtime data to extend the capabilities of its application security posture management (ASPM) platform.

    Manoj Nair, chief product officer for Snyk, said Snyk AppRisk will soon provide real-time insights into runtime environments using a Helios observability platform that provides them with deeper insights into issues that need to be resolved. That capability will provide developers with additional context as more responsibility for application security continues to shift left toward application development teams, he added.

    Armed with that insight, it then becomes simpler to prioritize remediation efforts based on the level of risk a vulnerability actually represents to the organization, said Nair. That’s critical to close a longstanding divide between cybersecurity and application development teams that, in the absence of any real ability to determine the severity of a vulnerability, results in developers wasting what limited time they have to allocate to remediation, he noted.

    Nair said the overall goal is to enable organizations to deploy more secure applications while minimizing adverse impacts on developer productivity.

    Snyk last year acquired Enso Security to add an ASPM platform to its portfolio that serves as the foundation upon which Snyk AppRisk was built. It also includes Insights, a Snyk tool that makes use of multiple types of artificial intelligence (AI) models to identify, prioritize and fix vulnerabilities.

    There’s often not a lot of love lost between cybersecurity teams and application developers who typically don’t have a lot of cybersecurity expertise. Most of the issues that cybersecurity teams are tasked to address start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix.

    Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving, but there is still a long way to go before application security truly improves. The one thing that is certain is the level of accountability for vulnerabilities is only going to rise as more stringent regulations go into effect in the months and years ahead.

    In the meantime, DevSecOps teams should assume there will be many more vulnerabilities to remediate. Developers are increasingly using generative AI tools to write code. The challenge is general-purpose large language models (LLMs), such as the one used to drive ChatGPT, were trained using examples of code of varying quality collected from across the web. A lot of the code these platforms generate, not surprisingly, contains vulnerabilities that many developers will not immediately recognize without the aid of some type of scanning tool.

    At the same time, cybercriminals are becoming more efficient at discovering and exploiting vulnerabilities that exist in applications that have already been deployed in production environments. DevSecOps teams should expect that, as a result, more zero-day vulnerabilities requiring immediate attention will soon be discovered.

    One way or another, the percentage of time allocated to application security issues is only going to increase. The only thing left to determine is how best to go about reducing the time and effort needed to make applications as secure as possible.

  • 5 Security Threats DevOps Teams Should Know

    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.

  • 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.

  • Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi added an ability to prevent unauthorized code from running in IT environments that make use of its machine identity management platform.

    Shivajee Samdarshi, chief product officer at Venafi, said the Stop Unauthorized Code Solution leverages the company’s CodeSign Protect offering to ensure that only authorized code can run on any given platform.

    The overall goal is to enable organizations to better secure their software supply chains using a zero-trust approach to software based on identity management and code signing to verify software comes from an approved source and complies with policy controls, he added.

    All code is signed using private digital certificates or those issued by trusted certificate authorities, said Samdarshi. Before code can execute, the security platforms an organization has in place can be configured to check that digital signature against trusted code signing certificates, he noted.

    Interest in securing software supply chains has risen sharply since the Biden administration issued an executive order requiring federal agencies to implement a range of measures, including code signing, to achieve that goal. However, securing software chains is often more challenging than organizations initially appreciate.

    In fact, a recent Venafi survey found that 70% of security and IT leaders believe that software supply chain attacks are their biggest security blind spot. Additionally, 85% believe that continuous security validation of the CI/CD pipeline is vital to reduce the risk of vulnerabilities going undetected during the software development lifecycle. A full 88% said they believe machine identity management is essential to the success of zero-trust models that are being more widely adopted across enterprise IT environments.

    Arguably, the most important thing organizations need to focus on is making sure application developers and cybersecurity professionals develop a working relationship. The biggest barrier to the adoption of DevSecOps best practices required to secure software supply chains remains largely cultural. For more years than anyone cares to admit, many developers have viewed cybersecurity more as a hindrance to application development that needs to be overcome or circumvented rather than being a core aspect of a quality assurance process. The total number of vulnerabilities that exist in applications running in production environments could likely be measured in the billions.

    Remediating all those vulnerabilities may never be practical, but at the very least, DevSecOps teams could make sure that no new code containing vulnerabilities is allowed to execute. Cybercriminals have become especially adept at inserting malware into code that they hope will find its way into any number of downstream applications before they activate it. That capability alone should help mollify cybersecurity teams that are increasingly being tasked with improving software supply chain security. The challenge is those cybersecurity teams don’t always appreciate the impact new policies can have on the pace at which applications are developed and deployed.

    Like it or not, software supply chains will generally be more secure in 2024. The only thing that remains to be determined is how much friction will be injected into DevSecOps workflows to achieve that goal.

  • 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.

  • Legit Security Applies AI to Detect Vulnerable Application Secrets

    Legit Security Applies AI to Detect Vulnerable Application Secrets

    Legit Security today announced it has expanded the scope of its application security posture management (ASPM) platform to make use of artificial intelligence (AI) to discover secrets more accurately in applications that cybercriminals can actually exploit.

    Scanners typically generate high false positive rates to the point where developers often start to ignore them. As a result, it’s not uncommon for secrets to be discovered in an application even though an alert was generated.

    Legit Security CTO Liav Caspi said the company is now applying a large language model (LLM) specifically trained for source code along with prompt engineering techniques and heuristics to reduce the level of alert noise that developers would otherwise see when scanning for secrets. The overall goal is to correctly identify access keys, passwords, application programming interface (API) keys and other personally identifiable information (PII) that should not be exposed once an application is deployed in a production environment, he noted.

    That capability can be applied to detect secrets across all development assets, including code repositories, source code management (SCM) tools, build tools and logs, artifacts and private and public documentation. In addition, this approach also uncovers toxic combinations of secrets or ones that might lie buried within assets such as source code history or modified Confluence pages that developers often forget exist, noted Caspi.

    Legit Security also enables DevSecOps teams to apply preventive guardrails on developer endpoints using the Legit command line interface (CLI) to stop secrets from being exposed before code is pushed. In addition, automated workflows can reach developers as part of a pull request or create Slack messages or Jira tickets to streamline remediation. DevSecOps teams can also continuously triage results to create a baseline that includes exceptions.

    As part of a larger effort to secure software supply chains, Legit Security has developed a software-as-a-service (SaaS) platform designed to apply security policies across an entire software development life cycle. The company is now extending the capabilities of that platform using AI technologies to detect secrets in both source code and all the components that make up a development pipeline as they are added.

    In the wake of an executive order requiring federal agencies to better secure software supply chains, there is now more focus than ever on application security. Unfortunately, many developers are a little too cavalier when it comes to managing secrets during the application development process. They often leave secrets in plain text to facilitate workflows, but more often than many care to admit, those secrets are not removed before an application is deployed. Knowing this, cybercriminals have learned to scan applications for those exposed secrets. Once gained, they then appear to be just another legitimate user of an application that might not be discovered until malware is activated.

    It may be a while before the cultural and technical issues that conspire to make the software supply chain insecure are fully addressed. In fact, the problem may get worse before it gets better—simply because the pace at which distributed applications are being built and deployed only continues to accelerate. At the same, the cost of making a secrets mistake is also only going to increase as regulations become more stringent. In fact, it’s now only a matter of time before stiff fines intended to make an example of one or more unfortunate organizations are eventually going to be levied.

  • 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.