devopsy.kinsta.cloud

Tag: application security

  • DevSecOps: Changing AppSec for the Midmarket

    DevSecOps: Changing AppSec for the Midmarket

    The midmarket space has always been prime for innovation and opportunity. In the DevSecOps space, that is no different.

    If you look at this report or others about DevSecOps markets, two things stand out:

    1. The market is expected to explode to $14 billion by 2026 from today’s nominal $2 billion.
    2. The biggest driver of the increase is the rise of security adoption by midmarket enterprises.

    Software is eating the world, as everything is becoming digitized. In response, midmarket companies are rapidly cranking up web and mobile apps to better compete and serve their customers. Along with the increase comes a dependency on apps for critical business functions and a need to secure them from attacks, which explains the surge in security demand.

    Current AppSec Offerings Are Not Geared for the Midmarket  

    AppSec Expertise Required

    Most incumbent AppSec products were built at least a decade ago when only large enterprises cared about AppSec. Naturally, they were molded for the characteristics of those enterprises. They are unnecessarily deep and monstrously complex and require a team of AppSec experts to begin operations. Midmarket companies don’t have the skills, resources or willingness to hire a team of AppSec experts, especially given their short supply.

    Extraordinarily Expensive

    Incumbent AppSec products are dreadfully expensive for midmarket companies. Annual prices reach millions of dollars and it’s difficult to determine ROI, making decisions murky for budget-conscious midmarket companies. They want to produce and deliver secure apps and certainly want to mitigate risk, but they also have a lower ceiling they can afford to pay.

    A New AppSec Approach for the Midmarket

    Being Cloud-native Requires SaaS AppSec

    Midmarket companies are quicker to adopt a cloud-native approach. Unlike large enterprises, they don’t have the baggage of legacy tech and can move to the cloud more easily. Being cloud-native saves a lot of money and comes naturally to the midmarket—when it comes to AppSec, they are likely to require that products be cloud-native and SaaS. Most security incumbents started on-premises, and although some now have a parallel SaaS offering, they are clunky and not designed inherently for cloud-native architectures.

    Rise of DevOps and CI/CD Automation

    As cloud adoption increases, automation of deployment to the cloud becomes a key factor, resulting in the meteoric rise of DevOps. DevOps uses many tools to automate cloud integration and cloud deployment, with CI/CD tools consistently at the center. AppSec must be part of this automation process, preferably in the CI/CD. The manual waterfall approach cannot work with the new speed and volume of application development. If scanning is not automated in the CI/CD, scans simply don’t get run. Therefore, because the automation workflow starts with DevOps, AppSec needs to be DevOps-first.

    Traditional AppSec scanners were not built for DevOps. Sure, some have caught up and added DevOps to their marketing material. Several have even added some integrations, but their core product remains much the same and it’s not DevOps-friendly.

    One significant offshoot of DevOps-first AppSec for the midmarket is that the tool cannot require AppSec expertise, simply because most DevOps don’t have significant AppSec expertise. Requiring that knowledge to get the security automation workflow started is a non-starter.

    Open to Open Source Scanners … With Management

    Midmarket companies are typically willing to use open source primarily because it is free. Unlike large enterprises with their tendency to complicate anything, midmarket companies have fairly standard requirements that can usually be met with open source. It is no different when it comes to application security scanners, and midmarket enterprises are fans of these tools. Often the scanning prowess of these open source scanners is better than their commercial counterparts, as they are tailored and specialized to specific languages and architectures. They also cover all scan types (SAST, DAST, SCA, etc.) and a combination of them can provide an efficient and affordable level of security.

    This midmarket love affair with open source scanners comes to a screeching halt when it becomes apparent that it is grossly unmanageable. There are so many available open source scanners that it takes time to decide which are relevant for your organization, application and development status. They are also notoriously difficult to set up, upgrade and maintain. Each of them does things differently. The output or reporting formats are not normalized across scanners. Without an aggregation layer to consistently cross-reference, normalize and present a consistent view of the security risk, consuming the output is nearly impossible. This often results in midmarket companies choosing to select only one type of scan.

    Imagine a tool that adds a common SaaS orchestration layer that crosses all these scanners and scan types, using their superior scanning prowess, but removing the management headache. Midmarket companies would improve their security posture with an investment they can afford. This sort of “Open Source + SaaS” model is not new. Applying the model to application security changes the game for midmarket companies.

    One Tool for all Scanning

    The multiple types of application security scans make application security complex. SAST scanners scan the source code for vulnerabilities, DAST scanners scan running applications from the outside in, SCA/OSS scanners scan third-party libraries included in your application, container scanners scan containers, API scanners scan exposed APIs, Secrets scanners scan for open passwords in the source code, and so on. Mentioning all these distinct scanners can make heads spin for those inexperienced with AppSec. This complexity is worsened for midmarket companies. For most, it is nearly impossible to keep up with the new pace of application development with unaffordable, piecemeal scanners from multiple vendors or the multiple open-source scanners needed to address each area of vulnerability.

    Security is only as good as the weakest link. Even if you do an exemplary job with one type of scanning but leave out other types you leave gaping holes in your security and risk. What midmarket companies need is one tool that tackles application security comprehensively by automating and orchestrating the use of all types of scans while abstracting the user from the underlying complexities.

  • Runtime Security and Incident Response with Loris Degioanni

    Runtime Security and Incident Response with Loris Degioanni

    By adopting DevOps, Kubernetes and containers you can accelerate innovation and deliver a better experience for customers and employees. While Kubernetes adoption simplifies application deployment, security needs to adapt and be cloud-first, open and frictionless as a new set of complexities may surface.

    Check out this interview with Sysdig Founder and CTO Loris Degioanni to find out how you can manage the health of your applications and learn more about runtime security and incident response.

    Loris is a security expert and an open source veteran, and he’s also one of the keynote speakers presenting at this year’s DevOps Experience Virtual Summit. During his presentation, Loris will share his perspective on where security is going and practical advice for managing security risk in a Kubernetes and DevOps world.

    For more insights and tips on Kubernetes security, attend Loris’s keynote session at DevOps Experience 2020 on Oct. 22. To check out the full agenda or to register for free, visit the DevOps Experience website.

  • Survey Surfaces Lots of DevSecOps Friction

    Survey Surfaces Lots of DevSecOps Friction

    A survey of 560 application security professionals and software developers in North America and Western Europe conducted by WhiteSource, a provider of tools for securing open source software, finds there’s a long way to go before most organizations can claim to have fully implemented best DevSecOps practices.

    Only 20% of respondents said their organization had a mature set of DevSecOps practices in place, while 62% said they were improving. Only 18% described their organization’s approach to DevSecOp as being “immature.”

    There is considerable disagreement concerning how long those efforts have been underway. While 60% of security professionals said they have had an application security program in place for at least a year, just over a third of developers (37%) said they are aware of an application security program running for longer than a year inside their organization.

    Regardless of the length of the program, nearly three-quarters of all respondents (73%) said they feel forced to compromise on security.

    Among application security professionals the top DevSecOps challenge identified was vulnerability prioritization (41%), followed by lack of application security skills (35%), budget (34%), lack of cooperation between developers and security teams (31%) and scanning performance (31%). Less than a third (31%) have a formal process in place to prioritize vulnerabilities.

    There’s also considerable disagreement over whether an application security champion gets designated. Many application security professionals said they have one (60%), while only 40% of developers agreed. The survey also finds well over one-third of developers said their organizations (37%) don’t provide any secure code training. A mere 22% of developers said their organizations provide training regularly with another 20% reporting they have tools that allow for “ongoing independent training.” In contrast, only 27% of application security professionals said their organization does not offer secure code training.

    Lilach Aviad, director of product marketing at WhiteSource, said the survey makes it apparent there are still lots of gaps when it comes to DevSecOps. Most organizations have embraced the concept but are still a long way from unifying workflows to better prioritize which vulnerabilities to address first.

    Priorities are even fundamentally different when it comes to what features are most important in an application security tool. Application security professionals prized integration (48%) most of all, followed by accuracy and ease of use ties at 39%. Developers, in contrast, leaned toward accuracy (25%), followed more closely by integration (22%) and ease of use (21%).

    Overall, the survey found the most widely employed application security tools are penetration testing, web application firewalls and application programming interface (API) gateways. The acquisition of these tools is most often justified to achieve either vertical industry regulations (25%) or industry standards (22%).

    In general, Aviad noted when it comes to security there is still a lot of resentment among developers. Too often security tools have been selected by application security professionals with little regard to how those tools might fit within the context of a larger DevOps workflow, he said.

    Obviously, it’s going to take time and effort for most organizations to merge workflows and culture. The good news is that process has begun in a lot of cases. Less clear is exactly how long it will take to complete.

  • Synopsys Report Shows DevSecOps Progress

    Synopsys Report Shows DevSecOps Progress

    A report based on analysis of the software security initiatives of 130 organizations conducted by Synopsys, a provider of static application security testing (SAST) and software composition analysis tools, suggests progress in terms of DevSecOps adoption is being made but there is still a long journey ahead.

    According to the survey results, 121 organizations now ensure host and network security basics are in place, with 73 organizations also monitoring application input.

    However, only 39 organizations said they define secure deployment parameters and configurations, followed by 36 that said they were ensuring cloud security basics and 33 that said they were protecting code integrity. Only 32 had embraced application containers, while 22 employ orchestration for containers and virtualized environments, according to the Synopsys report.

    Using code protection (13), attaching bills of material to application inventory (12) and using application behavior monitoring and diagnostics (7) were even farther down the list.

    Michael Ware, senior director of technology at Synopsys, said the results of the report are an encouraging sign as more software security teams increasingly report into a technology group or CTO rather than an IT security team or chief information security officer (CISO). As the responsibility for application security continues to shift left, IT teams are being reorganized accordingly, he noted.

    More IT organizations are also embedding security reviews within their continuous integration/continuous delivery (CI/CD) platforms as they replace high-friction, out-of-band security tasks with ones that are automatically triggered by events in the CI/CD pipeline, added Ware. That approach also enables organizations to overcome a chronic shortage of cybersecurity personnel that has now become a longstanding issue for most organizations, he noted.

    Longer-term, security will become deeper ingrained in the entire mindset of not just IT teams but also entire organizations, noted Ware. As part of an effort to make the entire organization more resilient to change, organizations are making a more concerted effort to address security issues at all levels of the organization.

    Less clear at the moment is to what degree DevSecOps will be achieved by automating tasks rather than melding workflows. DevOps and cybersecurity teams have distinctly different cultures. As cybersecurity tasks shift left, many DevOps teams will seek to ruthlessly automate those tasks in much the same way they have automated other IT management tasks. In fact, there may come a day when security issues are addressed as a subset of the overall quality assurance process, Ware noted.

    In the meantime, it’s clear much more needs to be done before applications can be considered fundamentally secure. Security issues that stemming from relying on tools to automate the configuration of cloud infrastructure are rampant. DevOps teams clearly need to take more responsibility for security, but cybersecurity teams still need to be able to verify the right policies are being employed. As long as humans write code, there will always be plenty of opportunity for error. The DevSecOps challenge now is to eliminate as many opportunities for that human error to occur as possible.

  • DeepFactor Unifies Performance and Security Monitoring for Developers

    DeepFactor Unifies Performance and Security Monitoring for Developers

    DeepFactor today launched what it describes as the first continuous monitoring platform designed specifically for pre-production environments.

    Company CEO Kiran Kamity said the DeepFactor Pre-Production Monitoring platform combines security, performance and behavior monitoring in one offering. Based on a “Deep Passive Monitoring” capability that requires developers to add a file to a container image to instrument an application, the platform feeds the telemetry data collected via that file to an Application Runtime Intelligence engine. That engine surfaces potential security and performance issues as well as risky and unexpected behavior changes between versions of applications, he said.

    Scans of application environments are launched via a DeepFactor portal. Each scan is then compared to a set of configurable rules that are developed and maintained by the DeepFactor research team to identify indicators of application misbehavior. The engine also learns the application environment, which over time enables DeepFactor to generate alerts based on threshold triggers, known bad behaviors, anomaly detection and other attributes.

    The DeepFactor Pre-Production Monitoring platform also comes with pre-packaged integrations for widely employed DevOps tools including Jira, Jenkins, Slack and GitHub.

    In addition to the commercial platform, DevOps teams can also make use of a DeepFactor Standard Edition, which is free for non-commercial open source projects with no user limitations.

    In an ideal world, developers would address issues, including security, long before an application is deployed to a production environment. The issue is that developers are asked to navigate too many tools to achieve that goal. The DeepFactor Pre-Production Monitoring platform will make it easier for developers to surface insights in a frictionless way, said Kamity.

    Most organizations that embrace best DevOps practices embrace observability as a core tenet. The challenge they face is making it easy for developers to instrument applications as they are built and then making sense of all the telemetry data collected. That’s especially critical as developers attempt to strike a balance between remediating security issues and optimizing performance to better ensure the overall user experience. Existing developer tools are optimized for performance; asking developers to switch tools to address potential cybersecurity issues is a task that can be delayed to the point where it is essentially forgotten or simply ignored.

    It’s not clear to what degree DevOps teams might have the budget dollars required to deploy their own monitoring tools versus relying on the existing monitoring tools provided deployed by an IT operations team. However, it does usually take a significant amount of time to deploy and update the agent software that legacy IT monitoring platforms require. DeepFactor is making the case for capturing telemetry data using a comparatively lightweight container that can be added to either a monolithic or microservices-based application.

    Of course, if an application is already instrumented in a pre-production environment it might make sense to use the same monitoring platform to observe applications in a production environment. However, convincing IT operations teams to swap out their existing monitoring tools for something that makes the lives of developers easier might be a tall order.

  • Okta Offers PASETO as Alternative to JSON Tokens

    Okta Offers PASETO as Alternative to JSON Tokens

    Okta today launched an open source library for using Platform-Agnostic Security Tokens (PASETO) as an alternative to JSON Web Tokens (JWT) to authenticate end users.

    Randall Degges, head of evangelism for Okta, said PASETO is quickly emerging as an easier, more secure implementation of the JWT specification. PASETO is a draft specification created by Scott Arciszewski that reduces the scope of the Javascript Object Signing and Encryption (JOSE) family of specifications in a way that makes it easier for developers to embrace tokens to secure application access.

    Okta is trying to make it easy for developers to employ PASETO using a library written in Java, dubbed JPASETO, that has half the lines of code JWT token written in Java and is supported by a vendor, he said.

    While JWT tokens have been widely adopted, they are easy to misconfigure, which Degges noted has resulted in the recent discovery of many JWT vulnerabilities. Part of the fault for those vulnerabilities lies with the JWT specification itself, he added; JWTs support a wide range of cryptographic algorithms, including an option that employs no cryptography at all.

    In contrast, Degges said PASETOs are more cryptographically resilient and far easier to employ. The PASETO specification defines two types of tokens: local and public. Local tokens are always symmetrically encrypted with a shared secret key, which means no one can view the contents of a local PASETO unless they have the correct secret key. Public tokens are readable by anyone and are validated with a public key. There is no “none” option; there can’t be a security token that is not encrypted, he said.

    All PASETO formats are designed to be tamper-proof. The entire message is authenticated, so validation will fail if anything in the token changes, added Degges.

    That approach ensures higher levels of application security while at the same time aiding in the adoption of best DevSecOps practices using Okta’s JPASETO library, which can be incorporated easily into the application development process, he noted.

    In recent years software tokens such as JWT have gained traction as a way to implement two-factor authentication in place of creating a session in the server and returning a cookie. When a user successfully logs in using their credentials, a JSON Web Token is returned and must be saved locally.

    Software tokens, however, can still be vulnerable to attacks that either duplicate the underlying cryptographic software or phishing attacks that trick end users into giving up a password. There is no such thing as perfect security; however, software tokens provide a critical layer of security that should be employed much more widely.

    It’s not clear to what degree PASETO will further that goal. Many organizations may even mandate the use of either JWT or PASETO as part of their overall approach to DevSecOps. Regardless of approach, it’s clear that continuing to rely on sessions and cookies to authenticate end users is an antiquated approach to authentication that is not only more difficult to implement and manage but also ultimately less secure.

  • RunSafe Allies With JFrog to Secure Applications

    RunSafe Allies With JFrog to Secure Applications

    RunSafe Security, a provider of Alkemist tools that prevent memory exploits, has partnered with JFrog to create a plug-in for the Artifactory repository manager platform.

    Alkemist employs a combination of runtime application self-protection (RASP) and moving target defense (MTD) methods to neutralize memory corruption exploits such involving, for example, a memory overflow.

    Based on a research project for the Advanced Research Projects Agency of the Department of Defense (DARPA), the integration with Artifactory will make it easier to harden binaries and containers against memory corruption attacks before applications are deployed in a production environment, said RunSafe CEO Joe Saunders.

    RASP describes a class of application security tools that detect attacks in real-time as an application is running. MTD refers to a strategy that relies on changing the attack surface regularly for applications to make it more difficult for cybercriminals to target them.

    Cyberattacks that employ memory exploits attempt to either replace executables with malicious code or overwrite data in a way that changes application behavior. When aimed at operating systems, these attacks commandeer entire systems. They have also been used to launch self-replicating Worm attacks that both cripple systems and insert malware to steal data, corrupting files or installing a back door that enables remote access.

    Saunders said the Alkemist plugin will enable developers to defend applications from these types of attacks without slowing down the pace of application development. Friction is removed from the DevOps process because as code moves through the DevOps workflow, Alkemist automatically hardens it to prevent memory exploits, he said.

    With the growing popularity of containers, Saunders noted that as cybercriminals begin to target them the need to protect containerized applications from memory exploits using best DevSecOps processes will become even more pronounced than it is today.

    While there is clearly a lot of interest in DevSecOps, most developers still don’t have access to the tools needed to better secure applications. As more cybersecurity plug-ins become available for repositories such as Artifactory, the easier it will become to embrace best DevSecOps practices.

    JFrog, for its part, has been making a case for focusing DevOps teams on managing binaries rather than source code. The alliance with RunSafe extends that strategy into the realm of application security.

    It may be a while before DevSecOps practices are widely employed. However, increasingly the issue is becoming less about the tools that might be available. Rather, the cultural challenges associated with implementing cybersecurity gates within a DevOps pipeline is now the major challenge. DevOps teams will need to reconstruct existing DevOps workflows to incorporate cybersecurity gates before an application is deployed. Once that’s accomplished, monitoring applications for anomalies will then need to be incorporated into observability platforms.

    It’s not clear what role cybersecurity professionals will play in this new world of DevSecOps. The one thing that everyone can agree on, however, is the less involved cybersecurity professionals are in the application development and deployment process, the easier it should become to deploy applications that are truly secure.

  • Traceable Secures Apps Using Distributed Tracing

    Traceable Secures Apps Using Distributed Tracing

    Traceable this week announced it is making available under an early access program a namesake platform that combines distributed tracing and machine learning algorithms to better secure applications.

    Fresh of raising $20 million in funding, Traceable CEO Jyoti Bansal said the goal is to leverage distributed traces generated via open source Hypertrace agent software to capture streaming data to which machine learning algorithms can be applied to better secure microservices.

    Bansal, who is also the founder and former CEO of AppDynamics, said this approach leverages software engineering techniques and principles to address application security issues both before and after an application is deployed.

    As part of this effort, Traceable has developed TraceAI, a machine learning engine that has been trained to identify application security issues.

    Once those issues are discovered, developers will be able to apply policies to remediate vulnerabilities using Hypertrace agent software, he said.

    In effect, Traceable is applying many of the principles of application performance management (APM) platforms to securing applications. However, rather than simply aggregating and analyzing data, Traceable has added a streaming engine to collect massive amounts of cybersecurity data in real-time that is analyzed by machine learning algorithms to determine, for example, when and how data might be exfiltrated via an application programming interface (API).

    As the number of microservices that are deployed in enterprise IT environments increases, the number of API endpoints that can be compromised does as well. By adding open source Hypertrace agent software to microservices, Bansal said it becomes possible to leverage distributed tracing to better understand the context in which how business logic embedded within a microservice is being compromised. That context also serves to enable development teams to remediate that issue by either updating or replacing a microservice.

    While the rise of best DevSecOps practices has increased collaboration among developers and cybersecurity teams, Bansal said application security remains largely a software engineering challenge. Application development teams need to find a way to instrument agents to address application security issues within their code instead of relying on overlays deployed by network engineers, he said.

    Most cybersecurity professionals would nod their heads in agreement with that principle. However, it may take cybersecurity teams some time to get used to the idea that they might not need to be as involved with application security as they are today. In fact, the amount of time spent looking for the root cause of any vulnerability is likely to be substantially reduced.

    In the meantime, it’s apparent a primordial soup of agent software, distributed traces, machine learning algorithms and streaming data engines is coming together in a way that will transform application security. It may be a little while longer before the catalyst that converts all those elements into a widely employed platform arrives. However, it appears it’s now more a question of when rather than if there will be a major advance in application security that could take DevSecOps processes to a much higher level.

  • CNCF Elevates SPIFFE Spec to Secure App Services

    CNCF Elevates SPIFFE Spec to Secure App Services

    The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) announced that the open source Secure Production Identity Framework For Everyone (SPIFFE) specification and the SPIFFE Runtime Environment (SPIRE) have become incubation-level hosted projects.

    Andrew Harding, SPIRE maintainer and a principal software engineer at Hewlett Packard Enterprise (HPE), said the elevation of a potential standard to authenticate software services using cryptographic identities that are platform-agnostic could go a long way toward advancing the adoption of best DevSecOps practices.

    At the core of SPIFFE specification are short-lived cryptographic identity documents known as SVIDs that are invoked via an application programming interface (API). Workloads employ an SVID when authenticating to other workloads by establishing a TLS connection or by signing and verifying a JSON web token (JWT).

    Previously a sandbox level project, the SPIFFE specification is designed to reduce reliance on hard-coded secrets to authenticate application services, Harding said. Instead, developers will be able to more easily invoke multi-factor authentication to issue and verify identities for any type of application service. Each service is given its own identity, he noted.

    Amazon, Bloomberg, Google, HPE, Pinterest, Square, TransferWise and Uber are all contributors to SPIFFE. Since joining the CNCF last year contributors to SPIRE have added support for Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Kubernetes and bare-metal servers.

    SPIFFE and SPIRE are designed to work across both monolithic and microservices-based applications. The latter are not likely to completely replace the former anytime soon, so IT organizations need a consistent approach to authentication regardless of how an application is built, noted Harding. SPIFFE and SPIRE together enable an IT organization to implement a zero-trust architecture spanning multiple applications, he said.

    Ultimately, Harding said the goal is to enable better application security without compromising flexibility. As an added benefit, SPIFFE and SPIRE don’t require developers to share application secrets to enable interoperability between services running on different platforms. That’s because SPIRE doesn’t generate SPIFFE identities that can be used to authenticate to other systems nor does it store existing keys such as a database password on behalf of a workload. Each SVID generated is unique to the service use case.

    As the number of services and platforms being employed continues to increase, it’s not practical to continue to rely on approaches to authentication that rely on hard coding. The level of dependency that exists between services requires a more frictionless approach to authentication.

    It may be a very long time before reliance on tokens such as passwords disappear. However, it’s clear specifications such as SPIFFE, in the long run, will transform application security. The challenge now is not only getting developers to appreciate a new approach but also convincing skeptical cybersecurity teams that long have relied on some form of hard or soft token to secure applications. Given the number of times those tokens are misplaced or lost, there are more than a few IT help desk professionals wishing tokens would become obsolete sooner than later.

  • Appian Infuses Low-Code Platform With AI

    Appian Infuses Low-Code Platform With AI

    Appian this week released an update to its low-code application development and deployment platform that employs artificial intelligence (AI) to recommend best next steps, including how to address cybersecurity issues.

    In addition, the latest version of Appian also makes it easier to incorporate robotic process automation (RPA) modules to automate rote tasks in addition to adding support for Google Cloud Document AI, which makes extracting documents for use within an application that employs RPA easier.

    Malcom Ross, vice president of product strategy for Appian, said the machine learning algorithms embedded with the Appian cloud platform make it possible to embrace best DevSecOps practices to accelerate the development of secure applications. With the rise of automated machine learning (autoML) it’s also becoming easier to automate the process of applying machine learning algorithms to application development and deployment, he said.

    While low-code platforms go a long way toward simplifying application-building, Ross said not enough attention is being paid to the deployment process. The goal is not necessarily to roll out more applications faster but to ensure whatever applications are deployed achieve a level of quality that eliminates the need to address cybersecurity issues post-deployment.

    Appian achieves that goal by running automated tests for an application, which now also include Appian Plug-ins to detect potential mismatches in plug-in versions or plug-ins that are missing.

    Ross said that when it comes to AI there always will be some trepidation. However, there are many manual tasks that many developers would just as soon see automated using AI. As AI becomes more widely relied on to drive consumer application experiences, the more acceptance there will be among IT teams to automate internal processes, he noted, adding cybersecurity is one area in which most developers will appreciate whatever help AI can provide.

    AI is not likely to replace the need for a DevOps team or cybersecurity professionals anytime soon. However, at a time when many organizations are massive amounts of economic pressure, it’s clear AI has a significant role to play in reducing the total cost of IT. Despite advances in IT automation, the cost of labor remains one of the most expensive elements of any IT budget. As such, IT organizations have a keen interest in making sure DevOps teams and cybersecurity teams are not wasting time on tasks that might be better handled by a machine.

    Obviously, the way AI systems and IT teams will interact with one another is still being defined. However, the one thing that is certain is platforms such as Appian will be making more recommendations about what needs to be done when. It may take some time for IT professionals to have confidence in those AI recommendations; however, in terms of mistakes that are routinely made it’s also apparent IT teams will soon be running out of excuses.