devopsy.kinsta.cloud

Author: Mike Vizard

  • Codenotary Launches Cloud Service to Generate SBOMs

    Codenotary Launches Cloud Service to Generate SBOMs

    Codenotary has launched a Codenotary Cloud platform that can automatically generate a software bill of materials (SBOM) and make it easier to discover what components have been included in an application.

    Moshe Bar, Codenotary CEO, said that capability can also play a key role in identifying which components in an application might contain, for example, the Log4jShell vulnerabilities that were recently discovered in Java applications.

    That capability can reduce the time required to remove insecure artifacts by as much as 80% simply because organizations are not dependent on scanning tools to search for vulnerable components, added Bar.

    Codenotary Cloud is based on an immutable open source immudb database that cryptographically attaches an identity to each software artifact. In the wake of a series of high-profile breaches, there’s now a lot more focus on the integrity of software supply chains. In fact, the Biden administration recently issued an executive order requiring all federal agencies to, among other things, make sure an SBOM is available for all the software they use.

    Codenotary claimed Codenotary Cloud can scale to millions of integrity verifications per second across source code, builds, repositories, Docker container images and Kubernetes deployments in a way that doesn’t require DevOps teams to upload data to a centralized platform, noted Bar. That makes it possible to notarize and verify the provenance of all the code being employed, he added.

    Codenotary Cloud can also be fully integrated with most vulnerability scanners and popular cloud-native continuous integration/continuous delivery (CI/CD) systems running on any cloud or on-premises host via a managed service. Pricing starts at $5,500 for a workgroup of 10 developers.

    It’s not clear to what degree the Biden administration’s executive order will improve overall software security. There have been multiple vulnerability issues over the years that have not resulted in any material change in how organizations manage their application development processes. However, the executive order issued by the Biden administration, coupled with a recent summit on the state of open source software security, means more senior business and IT executives are at least aware of growing concerns.

    The one thing that is certain is there will be more zero-day vulnerabilities discovered. Developers today routinely reuse open source software and free components maintained by a small number of volunteer programmers. Like any other developer, the amount of security expertise those individuals have is limited. Many organizations reuse that code without contributing anything meaningful back to the project—either in terms of financing or vulnerability identification and remediation support. Contributors to these projects freely donate their time and expertise to build these components. Many of those contributors feel the onus for securing the software they created is on the organizations that decide to deploy that software.

    Regardless of who is responsible for security, it’s apparent cybersecurity teams are going to be reviewing application development processes. Theoretically, that should benefit all concerned and lead to DevSecOps best practices being more widely adopted.

  • WhiteSource Tightens Code Scanning Tool Integration with Azure DevOps

    WhiteSource Tightens Code Scanning Tool Integration with Azure DevOps

    WhiteSource has added the Microsoft Azure DevOps platform to the list of continuous integration/continuous delivery (CI/CD) platforms its open source vulnerability scanning tools natively supports.

    Susan St. Clair, director of product management for WhiteSource, said while developers are always encouraged to scan for vulnerabilities, it’s more effective if organizations implement scanning by default every time there is a merge request. That approach reduces friction because organizations become much less dependent on developers to scan for vulnerabilities within the context of a larger DevSecOps workflow, she added.

    WhiteSource also provides a merge confidence feature that uses crowdsourced data to show how likely it is that an open source component can be updated without breaking the build. Merge confidence includes data on upgrade age, adoption and compatibility to create a confidence score.

    The WhiteSource integrations make it possible for DevOps teams to detect all open source components being used and automatically enforce security policies directly from their repository. DevOps teams are provided with vulnerability and misconfiguration alerts and license violations along with detailed remediation guidance, including suggested fixes and prioritization advice, within an existing workflow versus being required to switch to a tool that has a separate user interface (UI) they need to learn.

    Should a merge request introduce a new error, the developer is given immediate feedback to resolve any newly introduced vulnerabilities before the request is completed. That approach to separating feature branches and mainline branches prevents interruptions to workflows. The enterprise edition of the WhiteSource tool also automatically generates pull requests in the repository to update vulnerable open source components to the lowest non-vulnerable version.

    WhiteSource also supports code repositories such as GitHub, GitHub Packages, JFrog, Bitbucket and GitLab. The Azure DevOps platform is gaining traction as more application development projects are being managed via the cloud following the onset of the COVID-19 pandemic, noted St. Clair.

    As more organizations begin to embrace DevSecOps workflows each of them will need to decide how far left they want to shift responsibility for application security. In theory, each developer is now being held more accountable for every one of their applications that gets deployed in a production environment. In practice, most developers lack the expertise required to ensure applications are secure.

    There are, of course, more concerns being raised about the security of software supply chains that include open source software in the wake of the recent disclosure of zero-day vulnerabilities in the widely-used Log4j logging tool. Many of the maintainers of smaller open source projects lack the resources required to ensure there are no inadvertent vulnerabilities that could be exploited by cybercriminals. More challenging still, many developers may have used an older version of that software that has known vulnerabilities.

    It’s not clear how open source software will ultimately be made more secure. In the meantime, however, it’s clear the onus for ensuring the security of that software is on the DevOps teams that employ it.

  • Linux Foundation Survey Sees Rise in SBOM Use

    Linux Foundation Survey Sees Rise in SBOM Use

    A global survey of 412 organizations published today by the Linux Foundation found nearly half of respondents (47%) producing or consuming software bills of material (SBOMs), and more than three-quarters said they expected to produce or consume them in 2022.

    SBOMs have become a bigger area of focus in the wake of a series of high-profile software supply chain-related breaches. The breaches involved application components compromised by malware that had been surreptitiously inserted during the application development life cycle. The Biden administration has gone so far as to issue an executive order requiring all agencies to provide SBOMs for all the commercial and custom software they use, but as of yet a deadline for compliance with that order hasn’t been set.

    In general, the Linux Foundation survey found that a large percentage of respondents (82%) are already familiar with the term SBOM. Respondents cited various benefits of having an SBOM, including making it easier for developers to understand dependencies across components in an application (51%), making it easier to monitor components for vulnerabilities (49%) and making it easier to manage license compliance (44%).

    However, the survey also makes it clear there is much SBOM work to be done. A full 62% of respondents, for example, are looking for better industry consensus on how to integrate the production/consumption of SBOMs into their DevOps practices. Respondents also cited a need for consensus on the integration of SBOMs into their risk and compliance processes (58%).

    More than half (53%) also said there is a need for better industry consensus concerning how SBOMs will evolve and improve.

    The survey also makes it apparent that organizations are more aware of the role SBOMs play in securing supply chains. A full 80% of organizations are aware of the White House’s executive order on improving cybersecurity, with more than three quarters (76%) considering making changes as a direct consequence of the order. Overall, the survey found the top consideration organizations focus on when evaluating open source software is security.

    Stephen Hendrick, vice president of research at the Linux Foundation, said 2022 is likely to be remembered as the year of the SBOM. There are several standards for building SBOMs, including an open source software package data exchange (SPDX) specification backed by The Linux Foundation and the Joint Development Foundation that is now recognized as the ISO/IEC 5962:2021 international standard. There is also CycloneDX, a lightweight SBOM standard based on an open source project that originated via the Open Web Application Security Project (OWASP) community and a software identification (SWID) standard for tags that some organizations use to create SBOMs.

    SBOMs are, essentially, a tool for listing the components that make up an application and are used inconsistently. However, when a critical vulnerability is discovered, they can sharply reduce the amount of time required to discover all the software components that need to be remediated. The challenge is, with the rise of containers, it has become much simpler to rip and replace software components in a way that may not always be reflected in the SBOM. Hendrick said in time, advances in technologies such as machine learning algorithms should make it easier to instantly reflect those changes in an SBOM.

    Regardless of approach, it’s apparent DevOps teams, like it or not, are about to be held more accountable for the provenance of every component employed across their entire application portfolio.

  • CircleCI Adds Free Unlimited Access Tier to CI/CD Service

    CircleCI Adds Free Unlimited Access Tier to CI/CD Service

    CircleCI has added a free unlimited access tier to its continuous integration/continuous delivery (CI/CD) platform.

    Jim Rose, CircleCI CEO, said in contrast to other ‘freemium’ offerings, CircleCI’s free tier provides developers and DevOps teams with frictionless access to all the premium capabilities of the platform. Those capabilities include up to 6,000 build minutes per month, unlimited users, the ability to fine-tune pipelines using caching, concurrency, test splitting, security tools and health metrics.

    CircleCI claims more than 200,000 teams now employ its CI/CD platform. The freemium tier is intended to make it easier for a DevOps team to take advantage of a CI/CD platform as they begin an application development project, noted Rose. As that project evolves and matures, many of those teams will eventually require commercial support and other services provided by CircleCI, he added.

    The free tier of the CircleCI cloud service comes as many organizations attempt to accelerate the rate at which they can build and deploy applications. Digital business transformation initiatives, in particular, have become a much higher priority in the wake of the COVID-19 pandemic. A free tier of a CI/CD service is likely to encourage more experimentation simply because it reduces the level of overhead associated with setting up an application development environment.

    As the number of applications being developed continues to steadily increase, competition among CI/CD platform providers is becoming more intense as the number of organizations adopting DevOps best practices to accelerate application development increases. At the same time, more DevOps teams than ever are relying on cloud services to host CI/CD platforms in the wake of the COVID-19 pandemic.

    It’s still not clear whether DevOps teams will opt to rely on a proprietary platform versus an open source platform. While an open source platform prevents organizations from vendor lock-in, the ease of use of a cloud service may lessen those concerns as the cost of switching from one cloud service to another declines.

    One way or another, usage of CI/CD platforms will increase sharply in 2022. It’s not uncommon for different DevOps teams within the same organization to employ different CI/CD platforms despite efforts to encourage standardization. In the name of productivity, DevOps teams tend to exercise a fair amount of autonomy within many organizations.

    The biggest challenge, of course, will not necessarily be building applications but deploying them. Despite the availability of CI/CD platforms, the processes that most organizations rely on to deploy an application are still largely manual. In the age of the cloud, however, it should become easier to automate application delivery thanks to the APIs cloud service providers expose. In fact, 2022 may be the year that DevOps teams finally master CD. Providers of CI/CD platforms, of course, have a vested interest in making sure the full promise of an integrated CI/CD platform finally becomes an everyday DevOps reality.

  • Survey Predicts Massive Migration to the Cloud

    Survey Predicts Massive Migration to the Cloud

    A global survey of 1,600 enterprise IT decision-makers found more than half are working for organizations that plan to eliminate the use of data centers over the next two years.

    The survey was conducted by Aryaka, a provider of a secure access service edge (SASE) platform, and found a quarter of the respondents have closed 25% to 50% of their office sites; 75% of respondents said at least a quarter of their employees will remain remote permanently post-pandemic. Just under a third (32%) expect at least half of their workforce would be permanently remote.

    Despite the apparent accelerated shift to the cloud, the report found a full three-quarters of respondents (75%) are projecting at least a 10% growth in IT spending, with a quarter expecting IT budgets to grow 25% or more. Nevertheless, more than a third (36%) report they have IT cost concerns.

    David Ginsburg, vice president of product and solutions for Aryaka, said the shift to the cloud in the wake of the COVID-19 pandemic is being driven mainly by digital business transformation initiatives that require applications be quickly built and managed by IT teams that are working from home themselves. With the pandemic entering the third year, a hybrid workforce that regularly shifts between home and the office is now permanent, he noted.

    Consequently, with more people working from home, nearly two-thirds of respondents (64%) said they will shift toward a SASE-based approach over the course of the coming year to provide secure access to cloud applications over a software-defined wide area network (SD-WAN). Over two-thirds of those respondents said they will opt for a managed SASE offering rather than build and maintain these platforms themselves.

    SASE was originally coined by Gartner to describe a cloud-delivered service that brought together networking and security offerings. Those offerings should include a firewall-as-a-service (FWaaS), secure web gateway (SWG), cloud access security broker (CASB) and zero-trust network access (ZTNA). In effect, it’s a secure software-defined wide-area network (SD-WAN). As organizations adopt SASE-based platforms and services, just under a third of respondents (61%) are recognizing that dynamic bandwidth reallocation will be a very important requirement as workers shift between the office and home.

    The transition to SASE involves setting a strategy (35%), phasing out of legacy virtual private networks (32%) and consolidating cloud security with zero-trust (29%). Top desired capabilities include SWG (47%), SD-WAN (36%) and FWaaS (28%). A full 41% reported that responsibility for networking and security decisions have now been consolidated into a single team. However, only slightly more than a third (34%) said security is a major priority.

    The implications of a shift to the cloud at this rate and level of scale are likely to have a profound impact on DevOps teams. While cloud infrastructure is designed to scale on demand, accessing applications across an SD-WAN can have a significant impact on application performance. The survey, however, finds only 29% of respondents are concerned about whether applications will perform properly. Nevertheless, well over two-thirds (69%) said there will be an increased focus on observability and control, while 42% noted identifying slow performance for remote and mobile users will be a key issue and 37% expected slow performance at the branch office to also be an issue. Lackluster application performance is a time sink, according to 42% of respondents.

    Naturally, many IT teams will add new tools and platforms to deploy and manage cloud applications. The Aryaka survey found that only slightly more than a quarter of respondents are concerned about the newness of the technology they might employ.

    The coming year is shaping up to be incredibly disruptive to the IT landscape. The challenge is making sure balance is maintained between cost, flexibility and application performance.

  • Harness CD Platform Now Available via Source-Available License

    Harness CD Platform Now Available via Source-Available License

    Harness today announced a free community edition of its continuous delivery (CD) platform is now available under a source-available license rather than a more traditional open source license.

    Scott Sanchez, chief marketing officer for Harness, said the goal is to make CD as accessible to developers and DevOps teams as their current CI platform. Harness already makes an open source edition of its continuous integration (CI) platform available.

    The Harness CD platform is available under a Polyform Shield license that provides free access to the platform, including the right to use, modify and distribute it but not launch a competitive offering. A source-available license is an alternative to an open source license that allows an organization to potentially create a fork of the Harness CD that could, for example, be delivered as a cloud service. That specific issue has led to scenarios where vendors that create an open source project find themselves competing for revenue against a cloud service provider that is not necessarily as committed to contributing and maintaining the primary open source project. At this juncture, it’s not clear how many other vendors that make software available under an open source license might take a similar tack.

    While most organizations that embraced DevOps have been able to successfully implement a set of CI best practices, the number of organizations that have implemented CD is not nearly as high. One reason for that is automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”

    However, as the number of digital business transformation initiatives continues to steadily increase, the need to regularly update application experiences is going to require more organizations to implement a set of CD best practices. A source-available license should help increase the number of DevOps teams that can access and experiment with a CD platform, noted Sanchez. The challenge, of course, is that many of those applications are now based on microservices with components widely distributed across an IT environment.

    Historically, CI and CD have been synonymous when viewed within the context of a CI/CD platform. It’s not clear to what degree DevOps teams will look to better leverage the CI/CD platforms they already have in place rather than deploying a dedicated CD platform for IT operations teams and letting developers choose whatever CI platform they prefer. In general, a recent survey conducted by the Continuous Delivery Foundation found that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree.

    Regardless of approach, the coming year is shaping up to be one where many more organizations take DevOps initiatives to the next level. Arguably, as more organizations realize how dependent they are on software to differentiate themselves from rivals, the ability to deliver new application experiences has become critical. At the core of those efforts is a set of DevOps best practices that will ultimately determine just how competitive those organizations will be.

  • Testlio Adds Fused Testing to Automate Testing Platform

    Testlio Adds Fused Testing to Automate Testing Platform

    Testlio announced today it is adding fused testing capability to its application testing platform; Testlio is used by IT organizations to manage application testing teams consisting of internal employees and external contractors vetted by Testlio.

    Fused testing describes the combination of automated and manual testing IT organizations use to improve overall productivity. Fused testing strikes a balance between tests that can be automated and those that still need to be performed by a human.

    To achieve that goal, Testlio has partnered with Applitools, BrowserStack, Headspin, Mabl and Sauce Labs. Failure signals and session artifacts from these tools can be pushed to the Testlio platform to streamline the triage of test results. Testlio is making six device slots and 100 hours per month of automated testing processing time available at no additional cost.

    Finally, Testlio has set up an automated testing center of excellence (CoE) as part of an expansion of its professional consulting services it provides to help organizations implement testing best practices.

    Testlio CEO Steve Semelsberger said those integrations will make it simpler to augment human testers and increase the rate at which applications can be tested as many organizations are accelerating the rate at which those applications are being built and deployed.

    As organizations seek to implement continuous testing within the context of a DevOps workflow it’s apparent there will need to be more reliance on automation to keep pace with application development, he added.

    Through its platform, Testlio provides organizations with access to more than 10,000 freelance application testers on demand. That network of testing professionals can create, run, optimize and diagnose automated tests using Appium and Selenium frameworks written in programming languages such as Python, Java and Node.js. Only 3% of the freelance application testers that apply to join the Testlio network have been accepted, noted Semelsberger.

    The degree to which organizations prefer to rely on internal employees versus contractors to test applications will naturally vary. However, it’s difficult to predict what volume of tests will need to be performed—and when they should be performed—to preserve application development timetables. Contractors provide IT organizations with a degree of testing flexibility that is becoming an absolute requirement given the current challenges of hiring and retaining professional application testers, said Semelsberger.

    Application testing is, of course, difficult to apply uniformly no matter how many testers are available. In addition to providing access to experienced freelance testers, Testlio also provides a platform for managing the overall testing process. The challenge is then aligning those testing tasks with the various application development projects the organization has launched.

    Regardless of the approach to testing, the need for it has never been more critical. As organizations embrace a wide range of digital business transformation initiatives, a much higher percentage of the applications are now externally facing. The tolerance for suboptimal application experiences among customers and partners is much lower than that of internal employees. As such, first impressions, like it or not, are going to determine the success and failure of most of those application initiatives.

  • White House Meeting Puts Spotlight on OSS Sustainability

    White House Meeting Puts Spotlight on OSS Sustainability

    A recent meeting between IT industry leaders and White House officials highlighted open source software sustainability concerns as high-profile breaches and zero-day attacks have many organizations reviewing their software supply chains.

    The White House published a statement describing, among other things, how participants had a “substantive and constructive” discussion on how to make a difference in the security of open source software while continuing to effectively engage and support the open source community.

    Meeting participants included Deputy National Security Advisor for Cyber and Emerging Technology Anne Neuberger, National Cyber Director Chris Inglis, and officials from the Office of the National Cyber Director, Office of Science and Technology Policy, the Department of Defense, the Department of Commerce, the Department of Energy, the Department of Homeland Security, the Cybersecurity and Infrastructure Security Agency (CISA), the National Institute of Standards and Technology and the National Science Foundation. Akamai, Amazon, Apache Software Foundation, Apple, Cloudflare, Facebook/Meta, GitHub, Google, IBM, the Linux Foundation, the Open Source Security Foundation, Microsoft, Oracle, Red Hat and VMware all sent representatives.

    The White House reported that the discussion focused on preventing security defects and vulnerabilities in code and open source packages, improving the process for finding defects and fixing them and shortening the response time for distributing and implementing fixes.

    There were few specific recommendations, but the White House is clearly bringing more pressure to bear after the disclosure of the zero-day Log4j vulnerability in Java applications wreaked havoc in enterprise IT environments and government agencies. That vulnerability made it clear just how dependent organizations are on open source software projects and brought to attention the fact that many are 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 of open source software to drop everything and create a patch on-demand to address a zero-day vulnerability.

    The federal government, however, has made it clear via executive order that it expects IT vendors and large enterprises that depend on open source software to do more to secure it. In the meantime, IT teams will need to evaluate their dependence on open source software; especially if, from a security perspective, that software isn’t sustainable simply because there are not enough contributors with the necessary expertise.

    Naturally, this is a complex issue. In many cases, organizations are relying on open source components without even realizing it. Those components have been embedded within an application by an independent software vendor (ISV) that typically doesn’t disclose how that application was constructed. When a zero-day vulnerability is disclosed, cybersecurity teams can spend weeks looking for all the ways the instances of an application they either built themselves or licensed are impacted.

    “There’s no way to really know,” said Mitch Ashley, principal for Techstrong Research, an arm of Techstrong Group, the parent company that publishes DevOps.com. “A vulnerability can be anywhere.”

    It’s not abundantly clear how critical an issue the sustainability of open source software security is just yet. Relative to the amount of open source software currently employed, the number of security issues that have been encountered is comparatively small, noted Ashley.

    “The innovation benefits enabled by open source software far outweigh the risks,” he said.

    It may be a while before the open source community comes to terms with rising software supply chain concerns. However, it’s clear that many more members of the IT community are about to be held accountable for it.

  • GrammaTech Adds SBOM Analysis Capability to CodeSentry

    GrammaTech Adds SBOM Analysis Capability to CodeSentry

    GrammaTech today updated its CodeSentry code inspection platform to include the ability to create a software bill of materials (SBOM) by analyzing application binaries.

    Walter Capitani, director of technical product management for GrammaTech, said version 3.0 of CodeSentry leverages the algorithms the company uses for binary software composition analysis to enable organizations to better address software supply chain concerns in the wake of a series of high-profile vulnerabilities.

    The tool can be applied to both commercial software and open source components via integration with Risk Based Security’s VulnDB database, created to track security issues.

    GrammaTech

    There is more focus than ever on creating SBOMs in the wake of the Biden administration’s recent executive order that will require federal agencies to only use software that comes with an SBOM. However, most organizations are not provided with access to the source code used within the applications they employ. GrammaTech enables organizations to address that issue by analyzing the binary code within an application to generate an SBOM.

    That report not only identifies all the components in an application, it also lists all known vulnerabilities associated with the version of the components being employed, said Capitani. CodeSentry will also list other common software products and the versions that may be impacted by the same vulnerabilities, along with versions of the software that have remediated the issue or versions of a component that have not been impacted by those vulnerabilities.

    Almost all software applications include third-party and open source components that create blind spots within software supply chains. In fact, that issue is what makes remediating zero-day application vulnerabilities so challenging; especially when they are discovered in, for example, a log management tool like Log4j that is widely used in Java applications.

    GrammaTech is making a case for a binary software composition analysis (SCA) tool that enables DevOps teams to address vulnerability issues prior to an application being deployed in a production environment. At the same time, however, security and compliance teams can now use the same tool to determine the level of risk an organization might be incurring once an application is deployed in production. That latter capability is especially critical because zero-day vulnerabilities are often not discovered until long after an application is deployed in a production environment, noted Capitani.

    Regardless of approach, the need to better secure software supply chains is now a major IT issue that should ultimately encourage more organizations to adopt DevSecOps best practices to better secure applications. The challenge, of course, is not just espousing the need for those practices but also providing developers with tools they will actually use to implement those practices. The success or failure of those efforts comes down to not just the efficacy of the tool but also how well it fits within the overall developer experience. After all, the greatest tool in the world will still languish if it’s too difficult for the average developer to employ.

  • Continuous Delivery Challenge Looms Large in 2022

    Continuous Delivery Challenge Looms Large in 2022

    As 2022 kicks off, it’s becoming apparent that the major DevOps challenge organizations will face is mastering best practices that enable continuous delivery.

    A global survey of more than 19,000 software development professionals conducted by the Continuous Delivery (CD) Foundation found 44% of respondents use either continuous integration or deployment. However, less than one in five (18%) use both practices to automate the entire software delivery life cycle. Continuous integration is currently the most popular DevOps-related activity (32%) followed by continuous deployment at 29%, the survey found.

    The survey also found that only 14% of respondents said, on average, that they can go from code checked-in to successfully running that code in production in one day. Just 10% said they routinely deploy code to production each day. Nearly a third of respondents said they still manually approve code deployments to production.

    Tracy Miranda, executive director for the CD Foundation, said it’s clear there is a need for a better understanding of continuous delivery as a distinct DevOps discipline that stands apart from continuous integration processes. While the two DevOps practices are complementary, she noted that continuous delivery requires a level of engineering expertise that many developers either lack or are simply not interested in gaining.

    In fact, the survey found more than a quarter of respondents (26%) are not involved in DevOps-related activities at all. At the same time, however, the survey revealed that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree. Nearly 60% of enterprise developers that participated in the survey employ a continuous integration/continuous delivery (CI/CD) platform, as opposed to 48% of developers working in small businesses and 42% of contractors. However, it’s clear from the survey results that much of that activity is focused on continuous integration rather than continuous delivery.

    The survey revealed, for example, that less than a quarter of respondents (23%) are involved in infrastructure provisioning and management at all. That compares to nearly a third (32%) that are involved in application and infrastructure monitoring. Only 20% are involved in creating automated tests, Collectively, the survey results make it clear there is still a long way to go in terms of shifting responsibility for DevOps practices further left toward developers.

    One reason continuous delivery is so challenging is that automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”

    However, with more attention focused on the integrity of software supply chains in the wake of a series of high-profile breaches, Miranda noted that automating software delivery will play a major role in achieving automation goals by reducing the need to rely on manual processes that are more easily compromised.

    At the same time, more organizations are starting to embrace Kubernetes clusters—this can simplify automation of software delivery across a set of platforms that all share a common application programming interface (API), she noted.

    The growing complexity of application development projects, coupled with increased reliance on software to drive digital business transformation initiatives, will also accelerate the adoption of continuous delivery best practices, added Miranda.

    One way or another, application deployment in 2022 is shaping up to be a lot more automated than it was in previous years. The only thing left to be determined now is the degree to which that goal can be achieved.