devopsy.kinsta.cloud

Category: IT as Code

  • Red Hat Adds Managed Ansible Service on Azure

    Red Hat Adds Managed Ansible Service on Azure

    Red Hat today announced general availability of a managed instance of the Red Hat Ansible Automation Platform on the Microsoft Azure cloud.

    Announced at the Red Hat Summit 2022 event, this offering makes it possible to deploy the control plane for Ansible on the Microsoft Azure cloud as an alternative to existing support for Amazon Web Services (AWS) or an on-premises IT environment.

    In addition, in version 2.2 of the Ansible Automation platform, Red Hat is previewing support for content signing technology that automatically validates content to improve overall security.

    Thomas Anderson, vice president of Ansible for Red Hat, said this managed service enables IT teams to take advantage of integrated Microsoft billing in addition to the latest features and content provided for the platform and other capabilities that have been added to optimize Microsoft Azure environments.

    The open source Ansible platform has been gaining traction as an automation framework that enables IT teams to declaratively automate tasks. It requires less programming expertise than rival automation frameworks, which Anderson said is the primary reason so many third-party vendors have adopted Ansible to automate a range of IT tasks.

    The challenge many organizations encounter today is managing multiple islands of automation across multiple clouds and on-premises IT environments. Ansible presents IT teams with the ability to begin unifying all those islands under a single framework, said Anderson.

    It’s not clear to what degree DevOps teams that have embraced rival automation frameworks might be willing to replace them with Ansible. However, as more IT teams embrace automation to make up for shortages of IT personnel, it’s apparent that Ansible is being used across a wide range of IT disciplines spanning everything from DevOps to network management.

    Regardless of the approach, the need to automate as many tasks as possible is becoming critical as IT environments grow increasingly more complex. Many of the scripts that IT teams created on their own simply don’t scale. More challenging still, they are not often documented, so every time the IT professional that created that script leaves the organization it becomes difficult to maintain that scripting code.

    In the longer term, of course, automation frameworks will be increasingly infused with machine learning algorithms capable of learning the unique nuances of individual IT environments. It’s not likely those algorithms will replace the need for IT professionals any time soon. However, rather than resisting automation, more IT professionals have concluded that the tasks required are simply too challenging to manually perform. Many will conclude they simply prefer to work for organizations that have a consistent approach to IT automation that makes it feasible for them to manage a wide range of IT tasks.

    One way or another, IT automation is becoming a standard capability that now goes well beyond the scope of a few isolated DevOps workflows. The issue is finding a way for IT professionals with varying skill levels to collaborate across a common framework that is both easily accessible and highly extensible.

  • Does GraphQL Introduce New Security Risks?

    Does GraphQL Introduce New Security Risks?

    The GraphQL query language is an excellent tool for increasing the ease of data sharing. The premise is that you request the fields you need in a single bundled request, avoiding multiple network calls. Due to its usability, GraphQL is a growing area of development. Yet, as with any new technology, it comes with caveats.

    REST APIs function as a request-and-response paradigm in which the receiver accesses one resource at a time. On the other hand, GraphQL exposes many fields at once, requiring additional rate-limiting and time-outs to avoid nefarious queries. Additionally, the ability to traverse the entire schema could be abused by attackers to expose intricate data linkages. There are also some usability features with GraphQL that could be abused if misconfigured.

    GraphQL is a friendly alternative to REST. But how do we handle the security implications of GraphQL? I recently chatted with Mike Benjamin, vice president of security research, Fastly, to dive deeper into the security repercussions of adopting GraphQL. Below, we’ll consider the unique insecurities associated with GraphQL and suggest specific steps to limit the impact of these risks.

    Four GraphQL Security Vulnerabilities

    1. Introspection

    GraphQL provides built-in documentation that tells developers what the fields are, providing a schema of everything you can query. You’ve essentially given the entire dataset schema to a developer, meaning they can perform introspection to capture attack surface information. Hackers will most commonly look for injection or mutation capabilities that they can exploit, explained Benjamin. Or, they might seek to leverage the interlinkages between data to map a way through to classified information.

    To mitigate this problem, Benjamin cautioned against over-exposing all documentation publicly. Instead, he suggested using a restrictive security model for external viewers. “Provide appropriate user documentation in a different method,” he says. This may end up looking more like the standard REST API view of documentation.

    2. Field Suggestions

    Another usability benefit in GraphQL could also be a potential security concern—field suggestions. Field suggestions occur when you don’t enter the correct field name or enter a partial input and the system returns a hint. You might type in 0 or user, and the system makes a suggestion to fill out the rest of the field.

    This user interaction improves the developer experience, but, unfortunately, it could be abused by a hacker, said Benjamin. Thus, he recommended disabling hints after initial development. Or, if you decide to keep it in, he recommended placing a limit on its use. For example, if you try this more than five times in a second, the system could flag it as a bot.

    Right now, this attack vector is pretty limited, but Benjamin anticipated that, over time, hackers could automate this introspection with mass scanners to divulge more information.

    3. Denial-of-Service-Oriented Attacks

    Without the proper guardrails, all web APIs are prone to denial-of-service (DoS) attacks. Such an attack may pummel a service with a million queries per second to shut it off completely. In the case of GraphQL, these queries can dive very deep in a nested data relationship. A social network, for example, might expose friends of users, friends of users’ friends and so on.

    Or, hackers might utilize GraphQL’s bulk query ability to perform reconnaissance, brute-forcing the enumeration of data to query hundreds of user IDs to see which are valid. If you’re allowing unlimited data retrieval bundled within a single request, you could be inviting hundreds of bundled queries that could expose large swaths of the underlying database in one fell swoop.

    To counter these actions, Benjamin recommended limiting the testing depth. This could involve placing limits on how long a query can run, which would cause a time-out for requests that require suspiciously high degrees of processing. Another option is to limit how deep the bundling can get, said Benjamin. For example, perhaps the system restricts going three levels deep into a graph database, as that could expose millions of interconnected endpoints.

    4. Lack of Object-Level Authorization

    Another vulnerability that GraphQL endpoints may be prone to is a lack of object-level authorization, which hackers could leverage to get at a datapoint through its edges, said Benjamin. Since the idea is that you can access any data from one all-encompassing endpoint, authorization rules are often too abstracted away from the actual data. Queries may be able to access nested data or query relationships between data, too, which may unintentionally divulge information.

    Benjamin recommended placing authorization closer to your objects or data to rectify this issue. Use authorization-level controls that align permissions structure and roles with users. “Everyone needs a common authorization model,” said Benjamin.

    Future Evolution: GraphQL Security Matures

    As I’ve written before, the greatest strength of GraphQL is also its greatest weakness. Using GraphQL with default settings is a security trade-off in favor of usability. But according to Benjamin, we’re seeing more GraphQL servers disabling some introspection features, which he sees as a very positive move and a sign of maturity of the base configuration.

    GraphQL might suffer from similar threats that all APIs are vulnerable to, such as XSS, injection, DDoS attacks and broken authorization. However, Benjamin stressed that the added complexity of GraphQL makes it a unique case. “The most important thing for folks to consider is that GraphQL is more complicated than a REST endpoint—much more complicated,” said Benjamin. “GraphQL is unique in that it has linkages of data which contributes to complexity. It takes a little more time to think about how that’s confirmed, how it’s presented and how it would be attacked.”

    In other words, with great power comes great responsibility.

    Although exploits in public GraphQL APIs are still rare, we should stay vigilant. Benjamin encouraged developers to continue reading about, understanding and thinking about these attack vectors when designing their interfaces, as these risks will become more prominent as GraphQL usage grows and hackers become more familiar with these specific frailties.

  • OpenSSF Adds Open Source Package Analysis Tool Prototype

    OpenSSF Adds Open Source Package Analysis Tool Prototype

    The Open Source Security Foundation (OpenSSF) has made available a prototype of a package analysis tool that has already identified more than 200 malicious packages uploaded to PyPI and npm software components.

    Caleb Brown, an OpenSSF maintainer of the project, said the goal is to understand the behavior and capabilities of packages available on open source repositories. It also tracks how packages behave over time to make it easier to identify when previously safe software began to act in a suspicious manner.

    Most of the malicious packages detected are employing dependency confusion and typosquatting techniques, Brown said. They usually contain a simple script that runs during installation and provides a few details about the host to an external command-and-control system. Most of these packages are not exfiltrating meaningful data except the name of the machine or a username, but they make no attempt to disguise their behavior. The issue is that any one of these packages could have done far more damage, noted Brown.

    Future goals for the project include detecting differences in package behavior over time; automating the processing of the package analysis results; storing the packages themselves as they are processed for long-term analysis and improving the reliability of the pipeline. As such, the OpenSSF is looking for application developers and cybersecurity researchers to contribute to the project. The expectation is that many providers of application security tools will incorporate the package analysis tool within their offerings rather than requiring each vendor to create their own version of the same tool, said Brown.

    The OpenSSF has launched a series of initiatives to improve the overall state of open source security. Most recently, it added an Alpha-Omega Project to automate security testing processes for open source software using a $5 million initial investment provided by Microsoft and Google. The core challenge is that many organizations are dependent on open source software projects created and maintained by just a handful of volunteer maintainers and contributors. The individuals that created those projects don’t always have a lot of cybersecurity expertise. In fact, many of them would argue that the onus for securing open source software is on the organizations that use what amounts to free software. It’s not the responsibility of the contributors and maintainers to, for example, drop everything and immediately create a patch to address a zero-day vulnerability.

    It’s not clear how easily open source software could be compromised by cybercriminals that insert malware into downstream applications that rely on that code. However, in the wake of a series of high-profile breaches, it’s safe to assume that more cybercriminals than ever are trying to compromise open source software projects. While some organizations may opt to limit their dependency on open source code that has not been properly vetted, there is no way to entirely avoid using open source code. The challenge is finding a more efficient way to ensure the integrity of that code for all concerned.

  • Checkmarx Report Highlights Need for AppSec Collaboration

    Checkmarx Report Highlights Need for AppSec Collaboration

    A research report published by Checkmarx finds the same basic malicious software developed using multiple programming languages as cyberattackers industrialize their malware development processes.

    Checkmarx, a provider of code scanning tools, shared examples of malicious packages written in multiple programming languages. These example packages share the same indicators of compromise that have gone undetected for years. A “junkeldat” PyPI package for Python applications, for example, that has been compromised also shows up in a Ruby version of the package.

    Tzachi Zornstain, head of supply chain security for Checkmarx, said much like any other development team that uses multiple programming languages, it appears cybercriminals are also sharing techniques. These examples highlight the need for development teams to share security intelligence even if they build applications using different programming languages, he added. There is a tendency for development teams using one programming language to ignore application security issues that appear to only impact applications written in another programming language, noted Zornstain.

    The fact that the packages remained undetected for such a long period of time is due—at least in part—to the lack of information sharing in the ecosystem, said Zornstain.

    Cyberattackers are, of course, trying to take advantage of the implicit trust many development teams have in open source projects. However, now that more cybercriminals are making a concerted effort to compromise downstream software components, it’s imperative that every component be vetted, said Zornstain. In fact, organizations should not use any code provided by strangers, he advises.

    The core issue is that many open source projects are maintained by a small number of programmers contributing their time and effort to building components that others are free to use. Many of them argue that the onus for making sure software is secure is on the organizations that decide to deploy that software. Nor is it their responsibility to keep track of cybercrimimals distributing malicious versions of their software.

    Unfortunately, many IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may be only a matter of time before these long-simmering open source software security concerns boil over into a larger crisis.

    One way or another, DevSecOps best practices will need to be applied to application development at a deeper level. Organizations can’t assume that the software components they are relying on have been scanned for vulnerabilities by someone else. It’s simply too easy for a development team to make a mistake. The need for higher levels of security may lengthen the development process, but the alternative—malware infestations wreaking havoc—is far less desirable.

  • Stytch Launches New, Flexibility-First SDK

    Stytch Launches New, Flexibility-First SDK

    Passwordless solutions have been a trend for a while now, improving user experience (UX) while reducing exposure to common attack vectors. Now, Stytch’s new JavaScript SDK aims to make password-free authentication a bit easier by increasing customization and flexibility while offering fully baked authentication out of the box.

    Julianna Lamb, Stytch CTO, said the solution provides dual benefits by doing the heavy lifting of implementation while providing the flexibility to create a powerfully branded UX from the customer’s first sign-on experience. The Stytch JavaScript SDK can offer an all-in-one experience that handles the entire user auth journey with a pre-built frontend component. But it can also give teams complete control over designing a sophisticated and tailored authentication journey. In an era where tech companies chase the ultimate customer experience as their holy grail, this should appeal to teams wanting to improve a customer’s first impression of their brand, Lamb said.

    Multiple Options for a Smarter Front Door

    Like many authentication tools, Stytch’s product suite originally offered two options: One was a standard widget to handle frontend components while backend APIs provided logins. The other option provided direct API integration, in which the developers built their frontend, handled tasks like session management and setting cookies on the frontend and used the API to do things like send a one-time passcode or email a magic link.

    “But we found people really want flexibility when it comes to any solution they’re using,” Lamb said. “They also don’t want to do the heavy lifting when it comes to things like session management. Those things can be complex to reason through and having those out of the box is really compelling.”

    The new SDK decouples drop-in UIs from helper functions, giving teams multiple options. They can place Stytch’s UI components anywhere they want in the product, sculpting the authentication flow to their specifications. As a headless SDK, it can be embedded client-side in the application to handle all the calls to the API, do the authentication, create a session and check its validity. The result: Less backend code to write and less logic to implement.

    Customizable UI flows mean that teams can fully own the UX experience and build a UI that is customized exactly how they want it to look—and they can do this without having to build an internal API to route authentication requests from client to server. Teams looking for ways to make a brand impact right out of the gate can capitalize on this ability by creating a unique user experience.

    “Authentication is the front door to your application,” Lamb said. “Sign-up is the first impression the user has of your app—and the ability to customize it with your brand look and feel so the UI fits your aesthetic is super-critical.”

    Frictionless Flexibility in Identity Verification

    Because teams may have different authentication needs within one product, the SDK can be used in tandem with the core Stytch API to meet shifting needs. Teams could generate embedded magic links via the API while providing Google OAuth and Google One-Tap sign-in options via the SDK.

    The solution also reduces friction by making it easier to not only authenticate users but verify them on return visits to continue the same session. By loading the SDK on the frontend, teams can automatically connect Stytch’s sessions product to the browser cookie, feeding user session data directly into the cookie.

    The Stytch team is currently building out more SDK functionality and frontend components, Lamb said. Given the ongoing evolution of simple authentication tools that meet complex requirements, it will be interesting to see where innovative authentication goes next.

     

  • Synopsys Sets Course After Agreeing to Acquire WhiteHat Security

    Synopsys Sets Course After Agreeing to Acquire WhiteHat Security

    Synopsys, Inc. plans to add dynamic application security testing (DAST) tools to its software-as-a-service (SaaS) platform in the wake of agreeing to acquire WhiteHat Security from NTT Security Corp. for approximately $330 million in cash.

    Jason Schmitt, general manager of the Software Integrity Group at Synopsys, said the DAST tools developed by WhiteHat will complement the existing static, interactive and software composition analysis tools that Synopsys currently provides.

    The goal is to provide an end-to-end application security platform, including consulting, to help organizations better secure software supply chains, he added. NTT Security Corporation previously acquired WhiteHat Security in 2019 to extend the reach of the services it provides. Since then, SaaS platforms for testing application security have become more widely available.

    The acquisition comes at a time when many organizations are trying to determine how far left to shift responsibility for application security toward developers. While developers have a role to play, Schmitt said that shifting responsibility for applications completely left is a fallacy. DevOps teams will need to rely more on platforms that provide guardrails that enable developers to build secure applications in a way that doesn’t create a lot of additional friction, he said.

    Unfortunately, cyberattacks against applications are increasing in complexity and volume. That makes it a challenge for both application developers, DevOps teams and security professionals to keep track of how threats to applications are evolving, said Schmitt. As more companies rely on software to drive digital business initiatives, Schmitt said the business risks those organizations will face are only going to increase. In an era where developers far outnumber security professionals, he added that the only way to rise to that challenge is to rely more on SaaS platforms that enable organizations to implement DevSecOps best practices within their existing application development workflows, he noted.

    Today, the challenge is that much of an organization’s security budget is allocated to networks and endpoints rather than applications, added Schmitt. It’s not clear to what degree that spending needs to shift toward application security or if a larger portion of the application development budget needs to be allocated to security. One way or another, however, it’s apparent that overall spending on application security needs to increase to combat the increasingly frequent attacks.

    In the meantime, the historical divide that has existed between developers and cybersecurity teams should narrow as more security tools are made accessible to developers and DevOps teams alike. Otherwise, security professionals will continue to point out security issues that might affect an application running in a production environment and developers will continue to ignore issues they don’t see as relevant or that they don’t have time to patch. Not surprisingly, most vulnerabilities in applications running in production environments remain unpatched; the only way forward is to rely on automation to eliminate them before the application is ever deployed.

  • Pulumi Extends Infrastructure-as-Code Reach

    Pulumi Extends Infrastructure-as-Code Reach

    At its online PulumiUP conference, Pulumi announced it will make its Pulumi CrossCode translation technology available to third parties and DevOps teams. The technology was developed to integrate a wide range of programming languages with its infrastructure-as-code (IaC) platform.

    The company also announced it has added support for YAML—widely used to configure Kubernetes environments—as well as any variant of Java. It already supports .NET, Node.js, Go and Python programming languages.

    Finally, Pulumi also added packages for Oracle Cloud, Databricks and EventStore that simplify deployments on those platforms. The company already provides similar integrations for Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Kubernetes, Auth0, CloudFlare, Confluent Cloud, Datadog, DigitalOcean, Docker, GitHub, Kong, MinIO, MongoDB Atlas, PagerDuty, Snowflake, Spot by NetApp and SumoLogic. There are also now components that provide support for container applications, Kubernetes clusters and serverless applications along with an AWS Cloud Development Kit (CDK).

    Pulumi has been making a case for an IaC approach that enables developers to use programming languages they already know to provision infrastructure as an alternative to having to deploy and master tools such as Terraform.

    The Pulumi CrossCode translation technology the company developed is now being made available to any organization that wants to add support for another programming language. It converts any infrastructure-as-code format, including Terraform, CloudFormation, Azure Resource Manager and Kubernetes configuration, to any programming languages supported by Pulumi.

    Pulumi CEO Joe Duffy said the goal is to extend the overall reach of the translation technology the company created to simplify provisioning any type of infrastructure.

    While many developers use tools such as Terraform, the need to limit misconfigurations is driving many larger enterprises to revisit their approach to IaC to improve software supply chain security, noted Duffy. Today, Pulumi claims more than 2,400 organizations have adopted platforms that enable developers to provision infrastructure and apply guardrail policies to reduce errors. That approach prevents developers from making configuration mistakes that can lead to exfiltration of data via, for example, a port that has been accidentally left open, he added.

    Too many developers assume that their cloud service provider is securing both the underlying platform and how it is configured only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned without some ability to apply policies that enforce rules for provisioning that infrastructure within the context of a larger DevSecOps workflow.

    Ultimately, the goal is to employ automation to resolve these issues once and for all as more organizations adopt DevSecOps best practices. In the meantime, the challenge is doing so in a way the average developer will accept and embrace. Otherwise, they will continue to find ways to work around security teams in the name of productivity, regardless of how insecure the underlying IT environment might become.

  • vFunction Tool Uses AI to Help Convert Monolithic Java Apps

    vFunction Tool Uses AI to Help Convert Monolithic Java Apps

    vFunction today added the ability to employ artificial intelligence (AI) to automatically assess the level of effort required to convert a monolithic Java application into a set of microservices.

    Bob Quillin, chief ecosystem officer for vFunction, said the goal is to make it simpler for IT teams to more effectively employ the company’s vFunction Application Transformation Engine by using a vFunction Assessment Hub that assesses the level of technical debt involved.

    Legacy monolithic Java applications tend to have a lot of technical debt and dependencies that make them a challenge to convert into microservices, he noted. Most simpler Java applications have either already been converted or are in process, Quillin added.

    The vFunction Assessment Hub enables IT teams to better predict the outcome of refactoring a Java application to better prioritize which Java application should be converted first based on, for example, the level of scalability that can be achieved, said Quillin. Current assessment approaches involve a lot of manual effort and which typically requires organizations to hire external contractors to perform, he added.

    An AI-based approach reduces the total cost of creating a business case and constructing a roadmap for modernizing existing Java applications, said Quillin. The vFunction Assessment Hub measures application complexity based on code modularity and dependency entanglements and then assesses the level of risk changes might have on the stability of the application based on the depth and length of the dependency chains. It then surfaces benchmarks for debt, risk and complexity in addition to identifying aging frameworks that could create security risks and licensing issues.

    Thus far most organizations have been content to lift and shift Java applications into the cloud without modernizing them. The application simply now runs on infrastructure that is managed by an external cloud service provider. That approach does little to improve the scalability of a monolithic Java application, noted Quillin. The goal should be to convert that Java application into a set of microservices that run natively in the cloud, he added.

    The vFunction Assessment Hub is already being used within a Java Refactoring Service for the Azure cloud provided by Microsoft that is based on agent software to analyze code and the vFunction Application Transformation Engine.

    In general, organizations are embracing microservices to build applications that are both more scable and resilient. In the event a microservice becomes unavailable, requests for services are rerouted to another microservice to make sure the application degrades gracefully, rather than simply crashing altogether. The challenge, of course, is that the dependencies that can exist between hundreds of microservices can be more challenging to manage over time than those of the monolithic application being replaced.

    It’s not likely that microservices-based applications will entirely replace monolithic applications any time soon, but the bulk of new applications are being built on top of a microservices-based framework. As such, many DevOps teams are now managing a broad mix of monolithic and microservices-based applications across IT environments that become increasingly more complex to manage with each passing day.

  • CloudBolt Adds Modular Automation Framework to Tame Hybrid Clouds

    CloudBolt Adds Modular Automation Framework to Tame Hybrid Clouds

    CloudBolt Software this week added a framework consisting of eight modules that collectively make it simpler to automate, optimize and govern hybrid cloud computing environments.

    Jeff Kukowski, CloudBolt CEO, said the goal is to provide IT teams with a more modular approach to managing multiple clouds that they can employ as they gain additional expertise.

    The modules provided by CloudBolt address everything from providing a repository, dubbed Automation Exchange, through which reusable automation content can be shared to implementing governance policies and tracking cloud spending.

    Other modules address testing and assurance, integration, automated discovery and machine learning algorithms that can be used to automate processes.

    While most organizations employ multiple clouds alongside on-premises IT environments, the management of IT across an extended enterprise is far from unified. A recent survey published by CloudBolt found a full 88% of respondents needed a “manager of managers” that would enable them to unify the various silos that have multiplied across their IT environment. CloudBolt Software is making a case for an IT framework that provides a layer of abstraction through which the management of multiple clouds and on-premises IT environments can be unified.

    It’s not clear whether organizations are deliberately employing multiple clouds or if, because of simple inertia, they have found themselves managing multiple cloud platforms because of decisions made by various application development teams. Some IT organizations employ multiple clouds because they are concerned about either becoming locked in to a specific cloud computing service; others are concerned an outage on one platform might take all their applications offline. Others simply take advantage of services that are better provided by one cloud service provider than another. It’s also not uncommon for one organization to acquire another that relied on a completely different platform to deploy applications.

    Regardless of how IT organizations found themselves managing multiple clouds, the total cost of IT rises as each new platform is added to an IT environment. Just as challenging is the fact that each new platform exposes some type of automation framework. Before too long, IT teams find themselves having to navigate multiple islands of automation implemented across a highly distributed computing environment. In many cases, those automation instances are reinventing the same process that has already been automated on another platform using a completely different toolset.

    It is more a question of time and the degree to which IT organizations will eventually consolidate management of disparate IT environments under some type of unified control plane that enables true hybrid cloud computing. Once that capability is achieved, IT teams should find it simpler to migrate workloads from one platform to another.

    In the meantime, most organizations will be managing multiple IT environments for the foreseeable future. The only thing that is unclear is the volume of workloads that might be running on one of those platforms at any given time. The challenge—and the opportunity—is to regain control over computing environments increasingly more distributed.

  • BMC Integrates DevOps Mainframe Portfolio With Git

    BMC Integrates DevOps Mainframe Portfolio With Git

    BMC has expanded its efforts to bring DevOps best practices to the development of mainframe applications by integrating the BMC Compuware ISPW continuous integration/continuous delivery (CI/CD) platform with Git repositories.

    In addition, the company tightened integration between BMC Compuware ISPW and BMC AMI Ops platform and integrated BMC Compuware Topaz Workbench for building applications with code scanning tools from Vercacode.

    Finally, there is also now a BMC Enterprise Connector for Illumio that provides a bi-directional interface between the zero-trust segmentation platform from Illumio and the mainframe. In addition, the BMC AMI Command Center for Security system can now also surface malicious performance activity to accelerate incident response.

    John McKenny, senior vice president and general manager for intelligent Z optimization and transformation at BMC, said the overall goal is to make the mainframe just another platform where IT teams can apply DevOps best practices to build applications faster. That’s more critical than ever because mainframes are often at the core of digital business transformation initiatives and require integration with a wide range of distributed computing platforms. A recent survey published by BMC found two-thirds of respondents (66%) are investing in new technologies such as AIOps and artificial intelligence/machine learning (AI/ML), DevOps and integrations.

    That approach enables organizations to leverage existing mainframes in a way that minimizes technical debt rather than duplicating functionality, added McKenny.

    When it comes to DevOps in mainframe environments, the biggest challenge these days has more to do with culture than the maturity of the tools being provided, he said. Many of the IT teams building mainframe applications still rely on waterfall processes mainly because of simple inertia and a general fear of change, McKenny noted.

    There is, however, a new generation of IT professionals that have embraced modern development practices across all platforms to accelerate the rate at which applications are built and deployed, said McKenny. That shift is leading to the wider adoption of DevOps best practices within both mainframe and distributed computing environments, he added. In fact, as a result, enterprise IT has never been more hybrid, he noted.

    IBM continues to invest in mainframes, so the platform should remain relevant well through this decade and into the next. Though it’s been nearly 60 years since the venerable platform was introduced, it continues to host mission-critical applications for a broad range of enterprise IT organizations. Most recently, IBM added an IBM z16 edition of the mainframe that adds a dedicated on-chip AI accelerator in addition to quantum-safe cryptography. It’s not clear how quickly organizations that have mainframes will upgrade, but that level of investment suggests IBM is still investing heavily in mainframe research and development.

    Regardless of how—or even who—builds applications for the mainframe, tools such as Git repositories will be more widely used if for no other reason than to more easily share code. Now, the issue is improving the overall level of DevOps maturity within mainframe environments to keep up with the rapid pace at which applications are being built and updated across the rest of the enterprise.