devopsy.kinsta.cloud

Category: Features

  • Copado Streamlines Custom Salesforce App Testing

    Copado Streamlines Custom Salesforce App Testing

    Copado today added a testing tool to its platform for managing DevOps workflows in Salesforce application environments that automatically creates scripts based on manual tests being conducted.

    Announced at the TrailblazerDX conference hosted by Salesforce, Copado Explorer enables DevOps teams to integrate those scripts into testing processes that can be repeated as required.

    David Brooks, senior vice president and lead evangelist for Copado, said the goal is to make it simpler for DevOps teams to add those tests to the regression tests that are incorporated into pipelines created using the Copado continuous integration/continuous delivery (CI/CD) platform.

    In addition, markup and annotation tools enhance collaboration by allowing non-technical subject matter experts to provide detailed feedback and insights to quality assurance and development teams as part of an effort to streamline communications between product owners, testers and developers. Testers without a technical background can use that capability to contribute to the creation and deployment of effective automated tests. That capability makes it possible to shift testing further left to incorporate the business teams that better understand how an application should function, said Brooks.

    The challenge is far too many organizations still overlook the importance of testing, noted Brooks. There is a tendency when using low-code tools to assume that not as much testing is required because the tools that generate code create a false sense of instant quality despite flaws that might not manifest themselves until an application is deployed, noted Brooks.

    Rather than constantly updating applications, more testing should improve the quality of the applications being built sooner. That’s critical because most organizations don’t have the time and resources needed to continuously iterate applications until they eventually arrive at what the business requires, said Brooks.

    It’s still early days so far as the level of DevOps maturity that organizations using the Salesforce platform to build and deploy custom applications have thus far attained, noted Brooks. However, just about every organization that licenses the software-as-a-service (SaaS) platform from Salesforce customizes those applications to better align them with their internal business processes, he added.

    Each organization will naturally need to determine to what degree they are prepared to deploy customer applications, but it’s clear it’s becoming simpler to build them. Late last year, Copado, for example, added generative artificial intelligence (AI) tools to make it easier to manage the DevOps workflows used to build these applications, which means the speed at which these apps are built and deployed is about to exponentially increase.

    Salesforce, of course, is only one of many SaaS platforms that organizations rely on to build and deploy custom applications. However, as one of the most dominant platforms, the pace at which custom applications are being built continues to increase, with a larger percentage of these applications being built by professional developers familiar with DevOps best practices.

    Eventually, those DevOps workflows will be extended to every kind of developer, but for now, most organizations building applications are looking for more consistent outcomes regardless of what type of tool is used to build them.

  • Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare today launched a Magic Cloud Networking platform that makes it simpler to programmatically manage multiple cloud networking environments using Terraform code.

    Based on a platform the Cloudflare gained when it acquired the core technology from Nefeli Networks late last year, the Magic Cloud Networking platform presents IT teams with a console through which they can use the existing Cloudflare One secure access service edge (SASE) platform to securely manage multiple cloud networks. The Cloudflare global network spans more than 310 cities in over 120 countries and interconnects with more than 13,000 networks worldwide.

    Annika Garbers, director of product for Cloudflare, said this addition to the Cloudflare portfolio promises to make it simpler to integrate network operations (NetOps) with DevOps workflows in a way that makes it simpler to enforce zero-trust IT policies.

    The degree to which NetOps and DevOps are integrated tends to vary widely from one organization to the next. It’s still not uncommon for DevOps teams to be able to provision a virtual machine in seconds or minutes but then be forced to wait days for a NetOps team to provide then network access. Arguably, those kinds of delays defeat the purpose of investing in DevOps in the first place.

    That’s becoming a more problematic issue as organizations start to deploy workloads across multiple clouds, each with its own construct for managing software-defined networking infrastructure. The Magic Cloud Networking platform provides DevOps teams with a higher level of abstraction for programmatically managing those networks using Terraform code that is already widely used to manage infrastructure-as-code, noted Garbers.

    That approach eliminates the need to rely on cumbersome virtual routers that IT teams don’t want to manage. In fact, more IT teams than ever just want to be able to access network services versus having to build, deploy and manage physical routers and switches, said Garbers. In the age of the cloud, the physical network underlay is typically managed by the cloud service provider, so all that’s required is a way to programmatically unify the management of multiple cloud networks that can be invoked via lower-level application programming interfaces (APIs).

    The one thing that is certain is that as networking services become more programmable, the pace at which applications can be deployed is only going to accelerate. Each organization will need to determine which teams are best suited to manage any given layer of the networking stack. Still, regardless of approach it’s clear networks are finally catching up to rest of the IT infrastructure that is already being managed using code. The challenge, as always, is making just as easy for network administrators that lack programming skills to manage those networks as easily as a DevOps team that already has extensive experience using code to manage the rest of the infrastructure used to provide IT services.

    Of course, there will still be plenty of routers and switches to manage in on-premises IT environments but it’s only a matter of time before they become part of a larger DevOps workflow.

  • Cycode Acquires Bearer to Extend ASPM Platform

    Cycode Acquires Bearer to Extend ASPM Platform

    Cycode today announced it had acquired Bearer, a provider of a set of tools for static application security testing (SAST), discovering application programming interfaces (APIs) and identifying sensitive data.

    The provider of an application security posture management platform (ASPM) plans to integrate the Bearer tools into its core platform to enable DevSecOps teams to further consolidate tooling.

    Cycode CEO Lior Levy said the acquisition of Bearer gives Cycode access to a set of tools that take advantage of generative artificial intelligence (AI) to surface suggestions that enable DevSecOps teams to more easily secure modern applications based on, for example, a microservices-based architecture.

    Bearer achieves that goal by continuously scanning for application security issues as developers are writing code, he added. Overall, Bearer claims its approach to scanning is 31% faster than rival tools while simultaneously leveraging tools such as Bearer Assist, currently in beta, to provide more context concerning the level of risk to the business any issue discovered actually represents.

    Those capabilities will be infused into the Risk Intelligence Graph (RIG) that Cycode developed for its ASPM platform.

    Cycode earlier this year added generative AI capabilities to its platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments. The company uses the generative AI platform created by OpenAI to provide a natural language interface for RIG. As part of that effort, Cycode is making available an executive dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

    The company is at the forefront of developing ASPM platforms that continuously ingest data to identify and assess application security risks. Those platforms also provide a foundation for consolidating many of the tools that DevSecOps teams currently rely on to secure applications before they are deployed in production environments.

    It’s not clear how quickly organizations are embracing DevSecOps best practices, but given the number of vulnerabilities that continue to be discovered, there is still much work to be done. The challenge is that legacy tools that lack AI capabilities were not designed to enable organizations to practically shift more responsibility left toward application development teams that typically don’t have a lot of cybersecurity expertise, noted Levy. AI makes it possible to now provide those teams with the context required to address application security issues as they write code versus just before applications are deployed, he added.

    In theory at least, the applications deployed today should be significantly more secure than previous generations of applications. In effect, IT environments are steadily becoming more secure. Less apparent, however, is the rate at which modern applications are being deployed to replace legacy applications that are, all too often, rife with known vulnerabilities that cybercriminals can easily exploit. Given the rate at which vulnerabilities can be discovered and patched in those legacy applications, it may take the better part of the rest of this decade to address those issues once and for all.

  • StarCoder2 LLMs Designed Specifically to Generate Code Arrive

    StarCoder2 LLMs Designed Specifically to Generate Code Arrive

    ServiceNow, Hugging Face and NVIDIA have once again combined their efforts to advance a generative artificial intelligence (AI) platform that has been specifically trained to generate higher quality code than rival approaches based on general-purpose large language models (LLMs) such as ChatGPT.

    StarCoder2 is a family of LLMs created by the BigCode community led by ServiceNow. Three iterations are starting now with a 3 billion‑parameter model trained by ServiceNow; a 7 billion‑parameter model was trained by Hugging Face, while NVIDIA built a 15 billion‑parameter model.

    The 3 billion‑parameter model is capable of matching the performance of the original StarCoder 15 billion‑parameter model.

    Nicolas Chapados, vice president of research for ServiceNow, said as AI research continues to advance, each successive wave of LLMs becomes more efficient. Each organization, depending on the use case and total cost, can then opt to deploy StarCoder LLMs either on a local machine or in the cloud. The more parameters an LLM has, the more infrastructure resources are needed to run any inference engine based on it.

    The StarCoder2 LLMs were trained using 619 programming languages and can be extended to, for example, provide summarizations of code. The foundation of StarCoder2 is a new code dataset called The Stack v2 that is more than seven times larger than version 1 of the dataset. In addition, additional training has enabled the model to understand low‑resource programming languages such as COBOL, mathematics and program source code discussions. Organizations can also fine‑tune models with industry or organization‑specific data using open source tools such as the NVIDIA NeMo platform or Hugging Face transform reinforcement learning (TRL) techniques. StarCoder2 was built using data under license from the digital commons of Software Heritage hosted by Inria.

    The overall goal is to provide development teams with LLMs that, in addition to being less likely to hallucinate, also generates code with much fewer vulnerabilities because the code generated is based on exampled vetted by the BigCode community, said Chapados.

    It’s not clear right now how much of the code finding its way into production environments is being generated by machines versus humans. However, as LLMs continue to advance, the percentage created by machines will undoubtedly increase. The challenge DevOps teams now face is determining how to apply AI to pipelines that will increase in number as codebases not only proliferate but also become inevitably larger.

    In the meantime, DevOps teams would be well-advised to become familiar with what type of LLM is being used to train the generative AI platforms being used to create code. The more general purpose an LLM is, the more likely it is to generate suboptimal code that DevOps teams are only going to need to eventually replace, especially if that code is consuming expensive infrastructure resources inefficiently.

    There is, of course, as far as generative AI is concerned, no going back at this point. The issue now is determining how to keep track of the provenance of all the code being generated to determine how best to fix it whenever needed.

  • Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    A survey of 2,037 IT and security professionals conducted by the Cloud Security Alliance (CSA) on behalf of Dazz, a provider of a platform for mapping cloud computing environments, finds well over a third of respondents (38%) estimated that 21-40% of their code contains vulnerabilities, while 19% estimated 41-60% of their code contains vulnerabilities. Another 13% estimated they have vulnerabilities in 61-80% of their code.

    As a result, organizations on average have 55.5 security vulnerabilities each day in their remediation queue, with typically at least one being deemed critical, the survey finds. Overall, the average number of vulnerabilities that could be addressed is 1,025 per month, but organizations typically only address 270 within a month.

    In general, there are four phases to a remediation with each phase, on average, requiring between three to six hours so it easy to see how some organizations with limited resources can reach a point where they never catch up. The report noted that more than half of the vulnerabilities that have been remediated reoccur within a month, often because the root cause was never adequately addressed.

    Hillary Baron, senior technical director for research for CSA, said the high number of vulnerabilities that need to be regularly addressed suggested that progress in adopting DevSecOps best practices remains limited. While not every vulnerability is equally critical, it’s clear application development and cybersecurity teams are not yet proactively addressing application security issues, she noted.

    In fact, the survey found that less than a third (30%) of respondents reported there is a good working relationship between the application development teams that typically provision cloud computing environments and the cybersecurity teams that usually are held accountable for maintaining cloud security. Just under half of respondents (49%) said their vulnerability remediation teams comprised four to six members. Most respondents (60%) found it somewhat difficult to identify code owners, with an additional 24% facing moderate difficulty and 5% that found it highly challenging.

    Dazz CTO Tomer Schwartz said the more dynamic application development becomes, the bigger the DevSecOps challenge. Most organizations lacked the visibility required to proactively correlate their DevSecOps practices, he added. For example, more than three-quarters (77%) of respondents said they lacked full transparency into their cloud computing environments, and 6% had no visibility at all.

    In total, the survey finds organizations typically employ a variety of scanning and detection tools to safeguard their cloud environments, with 32% using five to six tools while another 29% report using three to four tools.

    More than three-quarters of respondents (76%) also noted that one in 10 of the alerts these tools generate is a false positive.

    Just under 75% of respondents also noted security teams spend more than 20% of their time performing manual tasks when addressing vulnerabilities, even though 83% reported using at least some automation in their remediation process. A full 61% also noted their organization is using three to six different detection tools, with nearly half (45%) considering increasing their security budgets in 2024, so it’s likely that many will be adding additional tools. In total, 22% dedicated less than 20% of their budget to cloud security, compared to 31% that allocated 21-40% of their budget and 27% that invest 41-60% of their budget to securing cloud environments.

    Unfortunately, less than a quarter (24%) said they feel very prepared for the cybersecurity threats their organization faces. Much of that uncertainty stems from knowing just how many vulnerabilities there really are in production environments and that they are being attacked with greater frequency each day.

  • Logz.io Leverages AI to Identify Anomalies in Real-Time

    Logz.io Leverages AI to Identify Anomalies in Real-Time

    Logz.io this week revealed it has added a real-time anomaly detection capability to its observability platform that makes it simpler to correlate the impact IT events will have on business processes.

    This capability is based on artificial intelligence (AI) models trained using historical data collected via the Logz.io Open 360 platform.

    Logz.io CTO Asaf Yigal said this addition to the Open 360 platform enables DevOps teams to employ machine learning algorithms to identify anomalies in mission-critical processes that warrant further investigation. Armed with insights that go beyond simple IT infrastructure consumption metrics, it becomes possible to significantly reduce mean time to resolution, he added.

    Logz.io has been embedding AI models within its platform since last year. Still, this latest capability will enable organizations to further bridge a divide between IT and the business that has long plagued many organizations, noted Yigal.

    The ultimate goal is to make it simpler for DevOps teams to instantly identify any anomalous application behavior that represents a risk to the business, including cybersecurity events, he added.

    The AI capabilities that Logz.io has been steadily adding to its observability platforms are largely transparent to DevOps teams, said Yigal. Instead, Logz.io is embedding multiple types of AI models into its platform that can be invoked in much the same way any other capability is provided, he added. DevOps teams are not necessarily going to need to build their own models to take advantage of AI to observe application behavior at scale, noted Yigal.

    The goal is to surface those capabilities consistently at a level of cost organizations can afford, added Yigal.

    It’s not likely AI will replace the need for DevOps teams any time soon, said Yigal. After all, there is a reason AI models are referred to as co-pilots versus an automatic pilot, he noted.

    It’s not clear to what degree organizations today can correlate the impact an IT event is going to have on the business. But as organizations continue to realize how dependent they are on applications to drive digital processes, the need to bridge the historic divide between IT and the rest of the business has become more urgent. In fact, many of the product and brand champions that organizations now rely on to manage a business unit often have a background in DevOps.

    Of course, business professionals that are steeped in IT are still relatively rare but as advances in AI continue to make it simpler to understand how complex application environments function the number of users of an observability platform will naturally expand beyond IT. The challenge is presenting each stakeholder with a view into the IT environment that meets their specific requirements.

    It may take a yet before the divide between IT and the rest of the business is permanently bridged but with each passing year it gets narrower. The challenge and the opportunity now is making sure everyone on both sides of that divide understands the art of the possible today that only a few short years ago would have seemed impossible to achieve.