Blog Dezvoltare Software & IT: Articole & Ghiduri

From the blog

September 25, 2023

mTLS: When certificate authentication is done wrong

Although X.509 certificates have been here for a while, they have become more popular for client authentication in zero-trust networks in recent years. Mutual TLS, or authentication based on X.509 certificates in general, brings advantages compared to passwords or tokens, but you get increased complexity in return. In this post, I’ll deep dive into some interesting attacks on mTLS authentication. We won’t bother you with heavy crypto stuff, but instead we’ll have a look at implementation vulnerabilities and how developers can make their mTLS systems vulnerable to user impersonation, privilege escalation, and information leakages. We will present some CVEs we found in popular open-source identity servers and ways to exploit them. Finally, we’ll explain how these vulnerabilities can be spotted in source code and how to fix them. This blog post is based on work that I recently presented at Black Hat USA and DEF CON. Introduction: What is mutual TLS? Website certificates are a very widely recognized technology, even to people who don’t work in the tech industry, thanks to the padlock icon used by web browsers. Whenever we connect to Gmail or GitHub, our browser checks the certificate provided by the server to make sure it’s truly the service we want to talk to. Fewer people know that the same technology can be used to authenticate clients: the TLS protocol is also designed to be able to verify the client using public and private key cryptography. It happens on the handshake level, even before any application data is transmitted: If configured to do so, a server can ask a client to provide a security certificate in the X.509 format. This certificate is just a blob of binary data that contain information about the client, such as its name, public key, issuer, and other fields: $ openssl x509 -text -in client.crt Certificate: Data: Version: 1 (0x0) Serial Number: d6:2a:25:e3:89:22:4d:1b Signature Algorithm: sha256WithRSAEncryption Issuer: CN=localhost //used to locate issuers certificate Validity Not Before: Jun 13 14:34:28 2023 GMT Not After : Jul 13 14:34:28 2023 GMT Subject: CN=client //aka “user name” Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:9c:7c:b4:e5:e9:3d:c1:70:9c:9d:18:2f:e8:a0: The server checks that this certificate is signed by one of the trusted authorities. This is a bit similar to checking the signature of a JWT token. Next, the client sends a “Certificate verify” message encrypted with the private key, so that the server can verify that the client actually has the private key. How certificates are validated “Certificate validation” commonly refers to the PKIX certificate validation process defined in RFC 5280. In short, in order to validate the certificate, the server constructs a certification path (also known as a certificate chain) from the target certificate to a trust anchor. The trust anchor is a self-signed root certificate that is inherently trusted by the validator. The end entity certificate is often signed by an intermediate CA, which is also signed by another intermediate certificate or directly by a trust anchor. Then, for each certificate in the chain, the validator checks the signature, validity period, allowed algorithms and key lengths, key usage, and other properties. There are also a number of optional certificate extensions: if they are included in the certificate, they can be checked as well. This process is quite complicated, so every language or […]

September 25, 2023

A faster way to manage version updates with Dependabot

GitHub Security

When the next Log4j lands, you don’t want to find out that you’re several versions behind, and that it’s going to take the team days to fix all of the breaking changes. Dependabot version updates automate the patching process, giving you a measure of protection from unwelcome surprises. But just as with any inbox, the sheer volume of available updates can quickly swell into a management hassle. And given that some types of related dependencies must be updated together–such as with Storybook, Angular, and AWS SDK–it’s all too easy to put off these tasks until it’s too late. Today’s general availability release is all about making it easier to stay on top of version updates and prevent breaking changes. Previously, Dependabot would open individual pull requests for each update, adding overhead to a developer’s workflow and raising the possibility that related dependencies could fall out of sync. Now, you can specify groups of dependencies to update with a single pull request. Grouped version updates confer significant benefits to your development process: simplified dependency management, a reduced risk of breaking changes, and an opportunity to phase out third-party tools and manual workarounds. I’ve been testing the grouped Dependabot updates and just wanted to say it is awesome! Grouping functionality and configuration are exactly what we want.– Nick Gibson, Causeway Capital Management How it works To take control of how Dependabot structures its pull requests, you can define groups of dependencies that will be updated together using groups in dependabot.yml. For example, you can configure groups that update many dependencies at once, or groups that minimize the risk of breaking changes. When you first configure a group, specify a group name that will display in pull request titles and branch names. Then, define other options to include or exclude specific dependencies from the group. dependency-type: specify a dependency type to be included in the group. dependency-type can be development or production. patterns: define strings of characters that match with a dependency name (or multiple dependency names) to include those dependencies in the group. update-type: specify the update type based on semantic versioning (for instance, where 1.2.3 equates to major.minor.patch) to include all updates of the same level in the same group. You can also exclude dependencies from groups to always manage their updates individually: exclude-patterns: define strings of characters that match with a dependency name to exclude them from a group. For these dependencies, Dependabot will continue to raise single pull requests to update the dependency to its latest version. Bear in mind that you can only create groups for version updates. Example 1: Group by dependency-type In this example, “production” and “development” dependencies are grouped together, excluding those that match the pattern “rubocop*”: # `dependabot.yml` file using the `dependency-type` option to group updates # in conjunction with `patterns` and `exclude-patterns`. groups: production-dependencies: dependency-type: “production” development-dependencies: dependency-type: “development” exclude-patterns: – “rubocop*” rubocop: patterns: – “rubocop*” Example 2: Group by patterns In this example, a group named dev-dependencies will update dependencies in the bundler ecosystem at a weekly interval: # `dependabot.yml` file with customized bundler configuration # In this example, the name of the group is `dev-dependencies`, and # only the `patterns` and `exclude-patterns` options are used. version: 2 updates: # Keep bundler dependencies up to date – package-ecosystem: “bundler” directory: “/” schedule: […]

September 25, 2023

CodeQL team uses AI to power vulnerability detection in code

GitHub Security

AI is fundamentally changing the technology and security landscape. At GitHub, we see AI as a way for developers to both speed up their development process and simultaneously write more secure code. For instance, GitHub Copilot includes a security filter that targets the most common vulnerable coding patterns in Python and JavaScript–including hardcoded credentials, SQL injections, and path injections–to prevent vulnerable suggestions from being made. We’re also looking at ways security teams can use AI to enhance their organizations’ security posture, specifically leveraging prescriptive security intelligence to contextually assess, prioritize, visualize, and audit security posture in complex and interconnected and hybrid environments. For example, our CodeQL team is responsible for creating models for frameworks/APIs to help CodeQL discover more vulnerabilities out of the box. Creating and testing these models is a time consuming process, so we started thinking about ways to use AI to help speed things up. The results have been incredibly exciting; the team was able to leverage AI to optimize our modeling process and power the way we detect vulnerabilities in code. How the CodeQL team discovered a new CVE using AI modeling For CodeQL to produce results, we need to be able to recognize APIs as sources, sinks or propagators of untrusted user data also known as tainted data. The open source software (OSS) community has developed thousands of packages that potentially contain APIs that we need to recognize. Keeping up with these packages is critical because missing a source, a sink or a taint propagator could lead to false negatives. Traditionally, we modeled the APIs manually, but this was incredibly time consuming for our team given the thousands of OSS frameworks. In the last six months, we’ve started using Large Language Models (LLMs) to automatically model APIs for us. This not only turbo charged our modeling efforts, but allowed CodeQL to recognize more sinks, reducing CodeQL’s false negative rate, and helping it detect more vulnerabilities. When we make improvements to CodeQL, we often test them using a technique called variant analysis, which is a way to identify new types of security vulnerabilities. We often use this technique to run CodeQL queries across thousands of repositories hosted on GitHub.com. We did exactly that, and ran queries that use the AI-generated models across the most impactful repositories on GitHub.com. This combination of AI generated models and variant analysis led the team to discover a new CVE (CVE-2023-35947), a path traversal vulnerability in Gradle. For more information about the exact vulnerability, check out the entry on the Security Lab’s CodeQL Wall of Fame and the GitHub Advisory Database entry. Learn more about multi-repository variant analysis AI is fundamentally changing the way we secure our software. We will continue to strategically leverage AI to iterate and improve upon our security offerings with an eye towards bringing AI-powered security testing into your development workflows. The discovery of the CVE in Gradle is just one example of how GitHub’s security teams have been leveraging GitHub Advanced Security and AI to unlock incredible results. In March this year, we shipped Multi-Repository Variant Analysis (MRVA) allowing you to perform variant analysis at scale. If you’re looking to get started with CodeQL and code scanning on your repository, check out our documentation. As always, CodeQL is free to use on open source repositories. If […]

September 25, 2023

Introducing auto-triage rules for Dependabot

GitHub Security

Since the May beta release of our GitHub-curated Dependabot policies that detect and close false positive alerts, over 250k repositories have manually opted in, with an average improvement of over 1 in 10 alerts. The impact so far: auto-dismissal of millions of alerts that would have otherwise demanded a developer’s attention to manually assess and triage. Starting today, you can create your own custom rules to control how Dependabot auto-dismisses and reopens alerts, so you can focus on the alerts that matter without worrying about the alerts that don’t. Today’s ship—our public beta of custom auto-triage rules—makes that engine available for everyone, so you can specify and delegate specific decision making tasks to Dependabot with your own custom rules. Today’s release is part of a series of ships that make it easier to scale your security strategy, whether you’re an open source maintainer or an application developer on a centralized security team. Custom auto-triage rules for Dependabot are free for public repositories and available as part of GitHub Advanced Security for private repositories. Together with auto-triage presets and a renewed investment in alert metadata, custom auto-triage rules relieve developers from the overhead of alert management tasks so they can focus on creating great code. What are auto-triage rules? Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale. Rules contain criteria that match the targeted alerts, plus the decision that Dependabot will perform on your behalf. What can you do with rules? With auto-triage rules, you can proactively filter out false positives, snooze alerts until patch release, and – as rules apply to both future and current alerts – manage existing alerts in bulk. What behaviors can Dependabot perform? For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. Our first public beta release covers ignore and snooze-until-patch functionality with repository-level rules. We will follow-up soon with support for managing rules at the organization-level. Both are managed via the auto-dismiss alert resolution, which provides visibility into automated decisions, integrates with existing reporting systems and workflows, and ensures that alerts can be reintroduced if alert metadata changes. What alert criteria are supported by custom rules? Custom rules can target alerts based on multiple criteria, including the below attributes as of today. Attribute Description severity Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical. scope Scope of the dependency: development (devDependency) or runtime (production). package-name Packages, listed by package name. cwe CWEs, listed by CWE ID. ecosystem Ecosystems, listed by ecosystem name. manifest Manifest files, listed by manifest path. Who can use this feature? GitHub-curated presets–such as auto-dismissal of false positives–are free for everyone and on all repositories. Custom auto-triage rules are available for free on all public repositories, and available as a feature of GitHub Advanced Security for private repositories. What’s next for Dependabot? In addition to gathering your feedback during the public beta, we’re working to support additional alert metadata and enforcement options to expand the capabilities of custom rules. We’re also working on new configurability options for Dependabot security updates to give you more control over remediation flows. Keep an eye on the GitHub Changelog for more! In the meantime, try out […]

September 25, 2023

Announcing general availability of GitHub Advanced Security for Azure DevOps

GitHub Security

We live in a world fully consumed by software. According to the IDC, around 750 million applications will be shipped globally by 2025, meaning the feat of securing the world’s software is growing at an unprecedented rate at a time when digital trust has never been more important. At GitHub, we’re committed to empowering developers to not only create software, but ship secure products. GitHub Advanced Security (GHAS) was built to minimize context switching, reduce tooling, and allow you to rapidly find and fix vulnerabilities at the speed of innovation. Our application security testing solutions are natively embedded in the developer workflow and empowers DevSecOps teams to prioritize innovation and enhance developer productivity without sacrificing security. But what does this look like in practice? Code scanning, our native SAST solution, surfaces the right alerts at the right time. When a security alert is triggered, it’s shown incrementally in the pull request. This is different from more traditional SAST tools, which may provide a long list of alerts to sort through when a scan is complete, lacking specific context. With this approach, users engage with almost 80% engagement of alerts surfaced by code scanning, leading to a 50% real-time fix rate in. This is 3.8X more effective than third-party alerts, where the engagement rate is around 16% and the fix rate is around 13%. Today, with the general availability of GitHub Advanced Security for Azure DevOps, we are bringing GHAS’s native security features to the Azure DevOps workflow, meaning Azure DevOps users can benefit from the same advantages seen by GitHub Enterprise users. To get started today, any Azure DevOps Project Collection Administrator (PCA) can enable GitHub Advanced Security protections through the Azure DevOps configuration settings. Rapidly deploy and scale your security program With general availability, we’ve added new functionality to help you quickly enable GitHub Advanced Security to cover your organizations repositories. You can now choose to enable GHAS at the organization or project level, as well as on individual repositories. This should allow you to quickly deploy GHAS, when you want it, where you want it. When you enable GitHub Advanced Security for Azure DevOps, you’ll receive a prompt that will alert you that this is a billable event and give you an estimate of the number of committers. You can also now choose for Advanced Security to be automatically enabled for any future repositories you and your teams create. View all your alerts in a single pane of glass A key part of any successful application security program is a way to view all your alerts, across your organization, in a single pane of glass. This ensures you and your team have maximum visibility into your application security posture. We’ve taken this necessary feature, and built on it with our partnership with Microsoft Defender for Cloud (MDC). You can now not only view all Advanced Security alerts across your Azure repositories within MDC, but can also view alerts from GitHub as well. This functionality is available in the free tier of MDC, ensuring any team can take advantage of this powerful integration. Getting started with GitHub Advanced Security for Azure DevOps If you’re interested in getting started with GitHub Advanced Security for Azure DevOps, please see our documentation. Need more information? We will also be hosting a webinar […]

September 25, 2023

Passkeys are generally available

GitHub Security

Passkeys are a new form of sign-in and phishing resistant credential that make it easier to protect your GitHub account by reducing use of passwords and other, more easily phishable authentication methods. Since the launch of passkeys in beta in July, tens of thousands of developers have adopted them. Now, all users on GitHub.com can use passkeys to protect their account. This continues our commitment to securing all contributors with 2FA by the end of 2023 and strengthening security across the platform—without compromising user experience. Read on to learn about how to enable passkeys on your GitHub account. And, for those of you also building authentication experiences, we share what we’ve learned about how to roll out and make passkeys easy to use to help you integrate this powerful new credential method more quickly in your service. Get started with passkeys To register one or more passkeys on your account, head to your account security settings and click “Add a passkey.” If you already have security keys set up, you might see an “Upgrade” option next to those, if they are usable as passkeys. For more details about upgrading security keys to passkeys, read the passkeys docs. What we’ve learned building support for passkeys Passkeys are a relatively new credential type, and we’ve learned a lot about how to make them easy to use for large communities. Here we’ll share some of what we learned, and how we responded to that feedback—to help other authentication teams looking to adopt passkeys into their product. Not every platform is passkey ready, but they can still be supported We found that Linux and Firefox users struggled to use passkeys, as those platforms don’t yet have strong support for passkeys. As a result, we decided to enable cross-device registration of passkeys. That means, you can register a passkey on your phone while you’re using your desktop. The passkey lives in the phone, but users can connect it to their desktop and set-up and authenticate through the desktop’s browser. This enables Linux and Firefox users to set up passkeys. At a technical level, this meant ignoring the results of the IsUserVerifyingPlatformAuthenticator API (IsUVPAA) call, and instead just relying on the presence of the webAuthN APIs. This meant that both hardware keys (which don’t cause the IsUVPAA check to return true) and cross-device usage could still be accessed even when the underlying combination of OS and browser didn’t result in IsUVPAA returning true. Make it easy to upgrade compatible security keys There are a lot of security keys already registered on GitHub.com, many of them hardware keys. We had predicted that most hardware key owners wouldn’t want to upgrade to a passkey, due to threat models and lack of sync support. But a lot of users opted to upgrade a compatible security key to a passkey. So, we invested in making it easier to do so. In the account security settings, a new “upgrade” arrow next to compatible security keys enables immediate upgrade. Note that not every compatible security key will have this button next to it, as we only started checking for compatibility in late February this year. We also learned that some browser, OS, and security key combinations don’t support the re-registration flow that we use for upgrades, and will error if GitHub attempts […]

September 25, 2023

The GitHub Security Lab’s journey to disclosing 500 CVEs in open source projects

GitHub Security

When I stepped onto the scale this morning, I remembered that there are some numbers that feel awkward to celebrate, while perhaps some others are worth celebrating! Recently, the GitHub Security Lab passed the milestone of 500 CVEs disclosed to open source projects. What’s a CVE? In short, it’s the record of a security vulnerability, under the CVE program, intended to inform impacted users. So, finding more vulnerabilities in open source shouldn’t be good news, right? Even as developer communities are getting better at keeping themselves secure, security issues may still slip through their defenses. This means that there will always be a need for security researchers, like the Security Lab, to discover and help fix them. If you’re not familiar with the Security Lab, we’re a team of security experts who work with the broader open source community to help fix security issues in their projects, with the goal of improving the overall security posture of open source. Our core activity is to audit open source projects, not only the ones hosted on GitHub–and help their maintainers fix the vulnerabilities we find, for free. This research is foundational for our other activities, such as education, improvement of our open source static analysis rules, and tooling. And now we are celebrating more than 500 CVEs disclosed. ???? How did we get here? The history of the Security Lab dates back to Semmle, the company that created CodeQL, and which was later acquired by GitHub. 2017 was a pivotal year, as we realized how powerful our product could be for finding security vulnerabilities. Unlike many other static analysis tools, CodeQL efficiently codifies insecure patterns and responds urgently to new security threats at scale. To showcase this capability, Semmle created a small security research team who used CodeQL to search for vulnerabilities in open source projects, and a web portal named LGTM.com where all open source projects could run CodeQL for free and be alerted of potential security flaws directly within their pull requests. This approach grew into an important company objective: find and fix vulnerabilities at scale in open source. This was a way of giving back to the open source community, just like any software company should. In September 2019, GitHub acquired Semmle, providing an ideal home for advancing the goal of improving open source security at scale. This led to the creation of the Security Lab, with a larger team and new initiatives, including curating the GitHub Advisory Database. The GitHub Advisory Database provides developers with the most accurate information about known security issues in their open source dependencies. GitHub also incorporated CodeQL as a foundation of code scanning and a core pillar of GitHub Advanced Security (GHAS), keeping it free for open source. Code scanning reached parity with LGTM.com in 2022. We have also expanded beyond CodeQL and now use a variety of tools in our audit activities, such as fuzzing. But CodeQL remains one of the most effective tools in our toolbox, because it enables us to conduct variant analysis at scale, and allows us to share our knowledge of insecure patterns with the community, in the form of executable CodeQL queries. The secret? Our maintainers-first approach Not all reports get a CVE. CVE records are useful for informing downstream consumers, so when there is no downstream […]

September 22, 2023

Will ChatGPT Replace Human Software Developers? Probably Not

Noutați, Software

Since the release of ChatGPT, there has been a great deal of hype around generative AI and how companies can leverage it to cut costs and democratize software and application development. Naturally, with discussions of cost-cutting and democratization come whispers about what will happen to software developers. This is a real and valid concern, but software developers’ skills, expertise and creativity are still very much needed. While generative AI and AI code generation tools like ChatGPT have shown some promise and potential benefits, they are still in their infancy—like many other innovative technological advancements. We also don’t know what scenarios they may present down the road or their true abilities when the technology matures. For instance, how will it integrate with other technologies? We don’t know what will happen when a ChatGPT-generated line of code breaks or needs to be changed. We don’t know if it can provide a novel solution to a unique problem or what security threats it will present. Given these unknowns, technology executives should think twice about replacing experienced and creative technology talent, such as software developers, with AI code generators. Will ChatGPT create novel code to solve a unique problem never encountered before? Probably not. A Tale as Old as Time (Or at Least a Decade) The technology industry has been searching for and developing new ways to make certain software development tasks much easier and more streamlined for years. One example of this is low-code/no-code. The notion of simplifying application development and replacing software developers with laypeople (citizen developers) has been around for more than a decade now, as low-code and no-code solutions have grown more popular. These solutions have promised that companies don’t need technical talent to get their software and app projects off the ground. However, if you look at the impact of these solutions today, their use can result in large amounts of technical debt and almost always require the skill of experienced software developers. The reason? Building complex software and applications is extremely difficult; it’s an art. Low-code and no-code solutions have their rightful place and can make things easier if a company is looking to launch a simple app or static web page. These solutions can increase the pace of development and time-to-market and enable everyday people without any development skills to facilitate them. However, they are not actually a complete solution and often overlook aspects of development that a human software developer would typically address. Without a skilled expert involved, low-code/no-code platforms often can’t solve a unique problem a company has. So, how does this relate to AI code generators like ChatGPT? Here’s how. A Similar Situation—With One Key Difference When thinking about their place in the development process, AI code generators are not that different from low-code or no-code solutions. The thinking is that they will also enable non-technical individuals to create software and applications with ease. Yet, there is one key difference—they promise expertise, too. But is the expertise coming from the AI code generator or the person piloting it? The answer is simple; it is not from the code generator. There have been examples of companies and individuals that have tried using ChatGPT to build code, and they have appeared to be successful. However, without the input of the individuals using it, it never would […]

September 22, 2023

Google De-Recruits 100s of Recruiters ¦ ARM Valued at $45½B in IPO

Noutați, Software

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters. This week: Google fires hundreds of recruiters, and ARM gets a sky-high valuation. 1. Layoffs for the recruiters themselves First up this week: Google’s hiring has slowed to such an extent that it has far too many in-house recruiters. Boo hoo? Analysis: Don’t shed a tear at task shedding I get it. Many reading this care little for the typical recruiter. All too often they seem like pointless brokers—adding no value to the process yet receiving a huge bonuses. But this news is the latest indication that DevOps jobs are harder to come by. Louise Matsakis has the scoop: Google lays off hundreds on recruiting team “Hard decision”Google is laying off hundreds of people across its global recruiting team as hiring at the tech giant continues to slow. … Workers who were laid off began learning their roles had been eliminated earlier today, according to posts on social media.…Google began reducing the speed of its hiring last year, after adding tens of thousands of workers in 2020 and 2021. … Google spokesperson Courtenay Mencini said, … “In order to continue our important work to ensure we operate efficiently, we’ve made the hard decision to reduce the size of our recruiting team.” Bring in the RecruitBot 4000. galaxytachyon explains: How likely is it that this is because of AI taking over the jobs? Sift through resumes, contact candidates, schedule some interviews, connect the hiring manager to the candidate, even getting some extra information from the candidate via email or phone calls are all things an LLM can efficiently do. They may actually do it even better than a regular human, since they might “know” more about the role and the technical requirements than an average [recruiter]. AI recruiters—and AI developers, too. Here’s Qbertino: I don’t expect those jobs to return. … After 23 years in IT I’m looking into a … career switch myself. Our industry is fully industrialized, custom coding is by now only for mostly totally broken legacy **** that will be replaced by SOA subscriptions within the next few years and what’s still left to code will be mostly done by AI quite soon I suspect.…Time to move on. It was an awesome ride but we’ve now finally built the bots that will replace us. Nice. This will spell more wealth for everyone in the long run even if we are out of cushy jobs with obscene salaries. When Google catches a cold, do other DevOps shops sneeze? Not in gijames1225’s experience: It’s weird being at a midsize company that has only accelerated hiring for engineers while the big players all go through these layoff cycles. The cynic in me sees them as token displays of fiscal responsibility being made for shareholders and a weird performativity of not wanting to be outdone by other tech giants. Another bit of me wonders about general productivity at these places if they can layoff so many people and nothing really appears to change (from a consumer perspective). All of which makes this Anonymous Coward wonder: I wonder what happens now to those who have threatened to quit or were reluctant to come in to physical offices. Meanwhile, u/saracenraider has questions: Do […]

September 22, 2023

CloudBees CEO: State of Software Development is a Disaster

Noutați, Software

CloudBees CEO Anuj Kapur told attendees at a DevOps World event today that with developers spending only 30% of their time writing code the current state of software development in enterprise IT organizations is a disaster. After more than 14 years of effort, the promise of DevOps—in terms of being able to accelerate the rate at which applications are being deployed—remains largely academic, said Kapur. In fact, the effort to shift more responsibility for application security further left toward developers has only increased the amount of cognitive load and reduced the amount of time available to write code, he noted. However, with the rise of generative artificial intelligence (AI), an inflection point that will dramatically increase the velocity at which applications are being built and deployed has arrived, said Kapur. The challenge will be achieving that goal without increasing the cognitive load on developers. That cognitive overload results in 70% of developers’ time not being productive within organizations that often hire thousands of developers, he noted. Despite all the DevOps issues that need to be addressed, AI advances promise improvement. The overall DevOps market is still relatively young, given the current level of adoption, said Kapur. “We continue to believe the market is early,” he said. Today, CloudBees took the wraps off the first major update to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform to have been made in the past several years. At the same time, the company also unveiled a DevSecOps platform based on Kubernetes that is optimized for building and deploying cloud-native applications based on portable Tekton pipelines. That latter platform provides the foundation through which CloudBees will, in the months ahead, apply generative AI to software engineering to, for example, create unit tests on the fly and automate rollbacks. In addition, DevSecOps capabilities will be extended all the way out to the integrated development environments (IDE) to reduce the cognitive load of developers. The overall goal is to reduce the number of manual processes that create bottlenecks that make it challenging to manage DevOps at scale. Criticism of the level of developer productivity enabled by DevOps compared to other development approaches needs to be tempered, said Tapabrata Pal, vice president of architecture for Fidelity Investments, because it still represents a significant advance. There is still clearly too much toil, but the issues that impede the pace at which developers can effectively write code tend to be more cultural than technical, he added. Organizations are not inclined to automatically trust the code created by developers, so consequently, there is still a lot of friction in the DevOps process, noted Pal. In theory, advances in AI should reduce that friction, but it’s still early days in terms of the large language models (LLMs) that drive generative AI platforms and their ability to create reliable code, he added. That should improve as LLMs are specifically trained using high-quality code, but in the meantime, the pace at which substandard code might be generated could overwhelm DevOps processes until AI is applied there as well, said Pal. Thomas Haver, master software engineer for M&T Bank, added that while assisted AI technologies will have a major impact, it’s not reasonable to expect large organizations to absorb them overnight. Patience will be required to ensure advances are made in ways that […]

Abonează-te la noutăți