devopsy.kinsta.cloud

Author: Mike Vizard

  • IBM Unveils Simulation Tool for Attacking SCM Platforms

    IBM Unveils Simulation Tool for Attacking SCM Platforms

    At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

    Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

    The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

    IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

    It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

    Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

    Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

    It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

  • Orgs Struggle to Get App Modernization Right

    Orgs Struggle to Get App Modernization Right

    A survey published today found 93% of IT leader respondents admitted that application modernization efforts are either extremely or somewhat challenging.

    The survey, which polled 150 IT leaders at organizations with at least 1,000 employees, was conducted by Asperitas, an IT services provider. The survey found the primary issues respondents identified were identifying the right tools and technologies (30%) followed by finding staff with the right experience (20%), choosing the right external partner (18%), getting users trained on new systems (17%) and securing the support of management (11%).

    More than three-quarters of respondents (78%) said the top priority for organizations taking on application modernization should be “getting it right.”

    The definition of application modernization is, like many things, in the eye of the beholder. One-third of respondents defined modernization as the use of cloud-based infrastructure while 32% said it was moving legacy systems to the cloud. Another 22% defined it as using cloud-based tools.

    More than half of respondents (54%) said employing microservices meant that they were modernizing, while 59% said the use of any cloud-native services indicates as much.

    Scott Wheeler, practice lead at Asperitas, said that while there are a lot of definitions of application modernization, it’s clear that the lift-and-shift era of moving applications to the cloud is coming to an end. Organizations are instead preferring to build and deploy applications using a wide range of cloud-native platforms and platform-as-a-service (PaaS) environments they don’t have to manage.

    The challenge is many of these applications are being built and deployed on multiple clouds. More than a quarter (27%) said the biggest multi-cloud challenge was securing applications, followed closely by integration with on-premises systems and other cloud platforms (26%). Another 20% identified ensuring portability between platforms as the biggest challenge.

    A total of 80% also noted upskilling of internal staff and making improvements to antiquated processes were extremely important to application modernization. In fact, one of the major issues that organizations still need to address is the degree to which “bad DevOps” practices are being applied to modern application environments, said Wheeler. Much of that issue stems from the simple fact that many IT teams still don’t know how to effectively manage cloud computing platforms, he added.

    Well over a third (36%) said that a key application modernization best practice was giving yourself ample time to complete the project while an equal percentage identified avoiding shortcuts, distractions and/or partners that over-promise. Another 34% said the most important lesson was choosing the best tool for the job, while nearly a quarter (24%) identified waiting too long to modernize a system that’s clearly in need of modernization.

    A full 100% of respondents said application modernization was very or somewhat important to their business, with 45% reporting the applications they had chosen to modernize were critical. A little more than a quarter (28%) also noted modernization has enabled them to innovate faster and scale more rapidly, while 25% said it could improve end user productivity and 11% said it might make their company more attractive to employees and customers.

    Regardless of the motivation for modernizing applications, just about every organization is engaged in these efforts to varying degrees. The issue doesn’t seem to be the willingness to start these projects as much as it is making sure they are completed quickly enough to be relevant to the business.

  • GitHub Adds Tools to Simplify Management of Software Development

    GitHub Adds Tools to Simplify Management of Software Development

    GitHub has made generally available Projects powered by GitHub Issues, a set of tools for managing application development projects based on a spreadsheet interface.

    Mario Rodriguez, vice president of product management at GitHub, said these tools enable DevOps teams to more easily filter, sort and group issues and pull requests. That capability makes it possible to, for example, configure and track cycle velocity and current work status and create visualizations using cumulative flow diagrams.

    Over the course of the rest of this year, Rodriguez said GitHub also plans to add additional capabilities including custom triggers, conditionals and action logic along with a mobile edition of Projects powered by GitHub Issues.

    The overall goal is to provide DevOps teams with a set of project management tools that enable organizations to plan where they code, said Rodriguez. In many cases, that approach eliminates the need to deploy a separate set of project management applications, he added.

    As more organizations become dependent on software to drive digital business processes, it’s become apparent that managing all the ongoing application development projects has become a significant challenge. GitHub has been developing Projects powered by GitHub Issues to provide organizations with a set of tools that can be accessed not just by DevOps teams but also by application owners and business leaders to track the status of various projects, said Rodriguez.

    Most organizations have not reached the point where revenue growth is completely dependent on the rate at which software is developed and deployed, he noted. However, as DevOps teams more regularly engage other departments in the business, Projects powered by GitHub Issues can provide anyone with access to a spreadsheet-like application that is simple to use, said Rodriguez.

    In general, GitHub is committed to improving developer experiences at a time when organizations are competing for the best talent available, added Rodriguez. If salary and benefits are equal, the decision to work for one company versus another comes down to the quality of the application development experience, he noted.

    As the provider of the most widely-used code repository, GitHub has been extending the reach and capabilities of its platform to address a range of DevOps workflow issues. The issue that DevOps teams need to address is how to anchor those workflows to a code repository versus the continuous integration/continuous delivery (CI/CD) platforms they employ to build and deploy applications.

    Regardless of approach, there’s no doubt that DevOps teams can now construct more scalable workflows. That’s critical, because the number of concurrent application development initiatives that organizations are managing simultaneously has increased substantially in recent years. The underlying platforms used to manage those projects need to be extensible to prevent workflows from becoming overly rigid, said Rodriguez.

    It’s not clear to what degree business leaders appreciate the value of DevOps workflows, but as business processes continue to evolve, the ability to effectively compete could rest on the agility of an application development team.

  • Armory Extends Scope of Spinnaker CD Distribution

    Armory Extends Scope of Spinnaker CD Distribution

    Armory today updated both the self-hosted and managed editions of its distribution of the open source Spinnaker continuous delivery (CD) platform. The updates support concurrent pipelines and provide tighter integration with open source Terraform infrastructure-as-code (IaC) to better enforce policies.

    Previously, the two platforms were known as Armory Enterprise and Armory Enterprise Managed. They are now being rechristened; Armory Continuous Deployment Self-Hosted becomes Armory Continuous Deployment Managed in part to provide more differentiation from a CD cloud service the company rolled out last month that is not based on Spinnaker.

    Adam Frank, vice president of product for Armory, said other capabilities added to the platform include additional testing tools for contributions to the Spinnaker platform as well as enhanced plug-ins and remediation capabilities for Common Vulnerabilities and Exposures (CVEs) that might impact the Spinnaker platform.

    Despite launching a declarative CD-as-a-service platform that is not based on Spinnaker, Armory remains committed to supporting organizations that prefer to continue to rely on the open source platform, said Frank.

    The number of organizations that routinely make use of a dedicated CD platform is still relatively small. While organizations have been employing continuous integration (CI) within a CI/CD platform, making use of the CD element of those platforms has proven challenging. Each platform used to run applications has been unique, so automating delivery has been problematic. CI platforms, in some cases, have been extended using custom scripts to automate application delivery, but those efforts don’t typically scale across an extended enterprise. Many organizations that attempted to extend the open source Jenkins CI/CD platform, for example, are now looking to more loosely couple CI and CD processes to make DevOps workflows less brittle, noted Frank.

    Armory is making a case for a distinct CD platform at a time when more organizations are starting to build microservices-based applications on Kubernetes clusters that expose a standard set of application programming interfaces (APIs) regardless of what infrastructure they are deployed on. In many cases, those organizations now need to manage multiple pipelines in parallel as application environments become more complex rather than relying on a single pipeline, noted Frank.

    There’s no doubt that as the pace of application development continues to accelerate, the need to automate CD will become a more pressing issue. DevOps teams are releasing a larger number of smaller updates to applications and there’s also a need to be able to easily roll back those updates in case an unexpected issue is encountered, said Frank.

    It’s not clear yet how many organizations will be adopting dedicated CD platforms, but as application development continues to evolve many DevOps teams will, at the very least, be revisiting their existing processes. At the same time, there are also many organizations that are just beginning their DevOps journey. Most of those organizations are not committed to one CI/CD approach versus another.

    Regardless of approach, however, the expectation in the era of digital business transformation is organizations will be able to deliver software updates in a timely manner. The only way to achieve that goal, however, will be to have some type of CD capability that reliably operates at the scale required by organizations that need to operate like a true software company.

  • Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks has added support for GitHub Actions, GitLab Runners, CircleCI and Argo Workflows to Checkov, an open source tool that scans programmatically provisioned infrastructure for misconfigurations.

    Guy Eisenkot, senior director of product at Bridgecrew by Prisma Cloud at Palo Alto Networks, said the goal is to make it easier to secure configurations created using infrastructure-as-code (IaC) tools such as Terraform.

    Those additions are now available as part of a Checkov library of policies, including graph-based checks, that provide a context-aware way of identifying risks within infrastructure and application code within a DevSecOps workflow using a tool that enables IT teams to manage policy-as-code, he noted.

    Misconfigurations of cloud infrastructure have become a major issue. Typically, that infrastructure is programmatically provisioned by developers that have little to no cybersecurity expertise. As a result, cybercriminals are now more aggressively scanning for misconfigurations that they can exploit to, for example, exfiltrate data or illicitly access services via application programming interfaces (APIs). Checkov makes it easier to identify those potential security issues within the context of a DevOps workflow before cloud infrastructure is provisioned, noted Eisenkot.

    There is a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. The Biden administration last year even went so far as to issue an executive order requiring federal agencies to review the security of their software supply chains. The challenge is that most organizations have yet to implement a truly developer-centric approach to ensuring application security, said Eisenkot.

    In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications today are clearly problematic. A chronic shortage of cybersecurity staff further aggravates the issue, because most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

    As more organizations are also starting to embrace DevSecOps best practices, the overall state of cybersecurity should improve. The challenge is that no matter how much time and effort is made to educate developers, there will always be mistakes a cybercriminal can exploit. Policy-as-code tools like Chekhov make it much less likely those mistakes will carry over into a production environment.

    In the meantime, organizations need to work on work on bridging the long-standing divide between application development and cybersecurity teams. Historically, cybersecurity teams would aggregate vulnerabilities they discovered in spreadsheets that developers would then be asked to remediate. The issue is not only the lack of time to address those vulnerabilities but also the lack of context provided. Many of those vulnerabilities often turn out to not be applicable to the way an application is deployed. Over time, application developers start to ignore many of those requests in favor of focusing their efforts on writing additional code. Of course, the more code that is written the greater the number of vulnerabilities that need to theoretically be remediated until a vicious cycle is created.

    Of course, it’s only a matter of time before one vulnerability winds up being a critical exploit and becomes the exception to that rule.

  • Continuous Delivery Advances Come at Cost of Testing

    Continuous Delivery Advances Come at Cost of Testing

    A survey of 820 application development professionals conducted by Applitools, a provider of an application testing platform, found well over a third of respondents (38%) working for organizations that now deploy daily changes to production environments.

    The challenge is that application testing is not able to keep pace with that rate of continuous deployment (CD). The survey found organizations are seeing test suites covering less than 50% of applications.

    Applitools COO Moshe Milman said a major reason test coverage is so low is that more than 40% of respondents said their continuous integration (CI) test suites can take more than an hour to run, which often resulted in tests either being postponed or possibly not run at all, he noted.

    Most organizations are also still relying on manual testing processes that can’t keep pace with the accelerated rate of application deployment and subsequent updates, added Milman. More than half of organizations (55%) automated less than half of their testing, according to the survey. More than two-thirds of respondents (67%) are embracing test automation to improve their test coverage, the survey found.

    In general, the percentage of organizations that are now employing CD processes to accelerate the pace at which applications are deployed is steadily increasing, said Milman. Manual testing processes, however, slow down the rate at which organizations deploy code. Many organizations routinely make trade-offs between application quality and a need to deploy code faster. Inevitably, there will be issues that can be traced back to decisions to not adequately test code prior to deployment, noted Milman.

    Overall, the survey found 90% of respondents building and deploying web applications, followed by 52% that were building and deploying mobile applications. Only 30% are building desktop applications. Testing of the applications, however, tends to vary widely. Nearly two-thirds of respondents (65%) said they tested applications on an end-to-end basis, with 55% testing integration followed by unit testing (53%) and application programming interface (API) testing (51%).

    However, only 26% tested application performance, followed by 13% that tested security and 12% that tested load, the survey found.

    Part of the issue, of course, is that it’s not always clear who is responsible for application testing. In theory, developers are accepting more responsibility for application testing as they take more responsibility for managing applications on an end-to-end basis. In practice, developers are often rushing to make application development deadlines. It’s not uncommon for developers to skip or limit testing in the name of productivity. Many of them have also embraced agile development methodologies that, at least theoretically, allow them to address any issues that might arise via the next application update.

    The issue that arises is that end users have become less tolerant of experimentation. If an application doesn’t initially work as expected, it’s exceedingly difficult to regain user confidence. Many will simply evaluate another similar application. The irony, of course, is that in the race to deliver code faster, application experience winds up being sacrificed because of the lack of time to properly test an application before deploying it.

  • JFrog Aligns With AWS to Improve Cloud Application Security

    JFrog Aligns With AWS to Improve Cloud Application Security

    At the AWS re:Inforce event this week, JFrog announced it integrated its JFrog Xray software composition analysis tool with AWS Security Hub, a cloud security posture management (CSPM) service that alerts IT teams whenever a security issue is detected.

    In addition, JFrog also announced it is participating in a preview of an AWS Marketplace Vendor Insights tool. AWS created Marketplace Vendor Insights to provide cybersecurity and compliance risk assessments of the third-party software made available on the AWS marketplace.

    Steve Bohac, partner marketing manager for JFrog, said the integration of JFrog Xray with AWS Security Hub will streamline the flow of cybersecurity alerts an IT team receives by centralizing the delivery via AWS Security Hub. AWS this week similarly moved to integrate the Amazon GuardDuty Malware Protection service with AWS Security Hub.

    Collectively, security services accessed via AWS Security Hub are intended to make it simpler for IT teams that have deployed application workloads on the AWS cloud to embrace DevSecOps best practices. JFrog Xray, for example, is designed to be deployed using the AWS Lambda serverless computing framework, noted Bohac.

    The arrival of these services comes at a time when the focus on cloud security, as part of a larger effort to better secure software supply chains, is rising in the wake of a series of high-profile application breaches. In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications are often problematic in that mistakes are frequently made. Developers routinely use open source tools like Terraform to provision cloud infrastructure and accelerate application development. Most of those developers have limited cybersecurity expertise so, inevitably, there are misconfigurations that cybercriminals have become more adept at finding and exploiting.

    The ongoing chronic shortage of cybersecurity professionals means most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

    Fortunately, more organizations are also starting to embrace DevSecOps best practices to make software supply chains more secure. The challenge is that no matter how much time and effort is made to educate developers, there will always be a development team that makes a mistake. Tools such as JFrog Xray make it feasible to discover those issues before an application is deployed.

    It’s not clear how long it might be before DevSecOps has a meaningful impact on cloud application security. The number of applications already deployed on cloud platforms is already innumerable. In theory, at least, as each of those applications is reviewed and updated, they should become more secure as DevSecOps best practices are more widely employed. However, it may be years before the overall security of cloud applications materially improves.

    Eventually, the next generation of cloud applications should be substantially more secure than their predecessors. The hope is, in the meantime, any vulnerable cloud applications that have security flaws won’t be exploited before IT teams can bring to bear the resources required to fix them. In effect, it is a race against time.

  • Iterative Adds Registry to GitOps Portfolio for ML Models

    Iterative Adds Registry to GitOps Portfolio for ML Models

    Iterative added a registry for machine learning models to its portfolio of Git-based tools for infusing artificial intelligence into applications.

    Iterative CEO Dmitry Petrov said the Iterative Studio Model Registry is intended to make it easier for application development teams to track which models are being used as the number of applications infused with AI capabilities continues to grow.

    The Iterative Studio Model Registry, accessible via a graphical interface, command line interface or application programming interface (API), makes it simpler to explore models, including history, versions and stages, via a central dashboard. Teams can also identify the experiment that produced the model and track how, when and by whom a model version was created.

    The Data Versioning Control (DVC) platform created by Iterative exposed a Git-like interface to enable organizations to track multiple versions of data sets, models and pipelines across a machine learning operations (MLOps) workflow. That approach enables those models to be stored in a Git repository alongside other software artifacts versus requiring organizations to deploy a separate platform just to store ML models.

    Providers of platforms used by data science teams have been making a case for separate repositories for tracking the artifacts used to construct an AI model. Iterative contends it is more efficient to employ Git repositories where other types of software artifacts are already being stored because, after all, an ML model is just another type of software artifact.

    That approach also makes it simpler for DevOps and data science teams to collaborate because the DevOps team will have more visibility into what AI models will eventually need to be incorporated into an application, noted Petrov.

    The challenge organizations face is the cultural divide between data science and application development teams. Data science teams today typically have defined their own workflow processes using a wide range of graphical tools. However, as it becomes obvious that almost every application is going to be infused with machine learning and deep learning algorithms to some degree, the need to bridge the current divide between DevOps and data science teams will become more acute.

    In fact, DevOps teams should assume that many more AI models are not only on the way but that those models will need to be continuously updated. Each AI model is constructed based on a set of assumptions; however, as more data becomes available, AI models are subject to drift that results in less accuracy over time. Organizations may even determine that an entire AI model needs to be replaced because the business conditions on which assumptions were made are no longer valid. One way or another, the updating and tuning of AI models are likely to soon become just another continuous process being managed via a DevOps workflow.

    No IT organization can, of course, manage what it can’t track. Registries have become an essential component of a DevOps workflow as the volume of types of artifacts that make up application environments has increased. It remains to be seen to what degree ML models become just another software artifact but one way or another someone in the IT organization needs to know what model is being employed in which application for what purpose.

  • RapidAPI Adds Tool to Make Building APIs Simpler

    RapidAPI Adds Tool to Make Building APIs Simpler

    RapidAPI today added a free RapidAPI Studio offering to its portfolio that makes it easier for developers to build, consume, manage and monetize application programming interfaces (APIs).

    Wade Wegner, senior vice president and head of product at RapidAPI, said RapidAPI Studio, available in beta, makes it simpler for developers to move between design and development, testing and management without losing context.

    It is also designed to be slipstreamed into developer workflows by either being accessed via a browser, as a desktop application, a macOS-native application or as an extension to the VS Code tools provided by Microsoft, added Wegner.

    That approach also makes it easier for teams of developers to collaboratively work on API projects, he noted.

    APIs are foundational to every modern application development initiative. Each microservice included in a modern application has its own API. As a result, the number of APIs—internal and external—that organizations are building and exposing has increased exponentially, especially as the number of digital business transformation initiatives continues to expand. While the bulk of APIs employed today are internally facing, the number of external-facing APIs being employed tends to rise sharply as more business processes become digitized.

    Less clear is who within the organization is responsible for managing those APIs after they have been deployed. In some cases, developers assume responsibility for them along with every other component of an application. Developers, however, tend to move on to other projects; DevOps and cybersecurity teams are being tasked with managing, securing and updating APIs. This is part of a larger effort to better secure software supply chains in the wake of a series of high-profile breaches.

    Unfortunately, documentation of those APIs has been somewhat lax within many organizations. In many cases, organizations are not even sure how many APIs have been deployed. Many organizations also discover, to their chagrin, that so-called zombie APIs previously abandoned by developers can still be exploited by cybercriminals to exfiltrate data.

    At the same time, the management of APIs is becoming more complex. Along with existing REST APIs and legacy web services based on XML, organizations are now deploying GraphQL APIs. The result is a mix of API schemas that require different levels of expertise to manage and secure.

    It’s not clear how the increased focus on securing software supply chains might impact API management. However, it’s apparent that cybercriminals are becoming more adept at discovering insecure APIs through which they can exfiltrate data. The challenge organizations face is that it’s not feasible to secure those APIs without first having a framework in place for managing them.
    One way or another, an API management crisis will soon come to a head as it becomes even simpler to build and deploy APIs. The only thing that remains to be seen is to what degree organizations will get ahead of that issue before it spins out of control altogether.

  • CircleCI Integrates CI/CD Platform With GitLab

    CircleCI Integrates CI/CD Platform With GitLab

    CircleCI today announced it has integrated its continuous integration/continuous delivery (CI/CD) platform with a rival software-as-a-service (SaaS) offering from GitLab.

    DevOps teams can now, for example, trigger pipelines in CircleCI from GitLab forked merge requests in addition to merging requests and making commits for specific branches. Other capabilities include the ability to access testing capabilities on the CircleCI platform and integrate permissions to ensure security.

    CircleCI CEO Jim Rose said the company routinely integrates its CI/CD platform with other offerings because organizations typically have multiple teams using different version control platforms at different times. The goal is to give those teams access to capabilities and best practices regardless of which specific platform they are using.

    In general, Rose said organizations are trying to strike a balance between the standardization of DevOps platforms and the need to enable development teams to innovate by adding new tools. Standardization tends to create more opportunities to automate more tasks in ways that reduce costs. However, developers will eventually rebel against any effort to limit the choice of tools they use to improve productivity, noted Rose. Too many senior IT leaders are quick to assume that a plethora of tools is an indication of a problem rather than the result of ongoing experimentation, he added.

    In the wake of the global economic downturn, many organizations are also revisiting their existing DevOps workflows to try to increase overall efficiency by automating more tasks. Those organizations realize they can’t afford to continue throwing labor at manual DevOps tasks, Rose added.

    The challenge, of course, is that building and deploying modern software is becoming more complex. Organizations are embracing microservices to make applications more resilient as they realize how dependent they are on software. The issue is that as the number of microservices continues to expand, it becomes apparent that legacy manual processes will not scale, said Rose. As a result, the impetus to automate DevOps processes becomes that much greater, he added. Less clear is to what degree organizations that have already embraced DevOps platforms might be willing to swap out their current CI/CD platform to achieve that goal.

    In the meantime, more organizations are embracing DevOps to manage software development projects that drive a wide range of digital business transformation initiatives. The applications driving those processes typically need to be continuously updated as business requirements change. That becomes much easier to achieve when using processes optimized around continuous development and deployment.

    Regardless of which underlying CI/CD platform organizations choose, they should assume that, eventually, some level of integration between those platforms will be necessary. After all, in the event of an acquisition, for example, it’s not likely both companies will have standardized on the same DevOps platform. Given the amount of time required to migrate from one DevOps platform to another the amount of time required for interoperability is inevitably going to be measured in months if not years.