devopsy.kinsta.cloud

Category: IT as Code

Survey Sees AI Playing Larger Role in Test Automation

A survey of 1,028 senior IT professionals and application developers in the United Kingdom, U.S., Germany and Singapore finds nearly half (47%) still use manual testing for mobile applications. More than a third (38%) noted that their organization could save between half and three-quarters (51-75%) of funding allocated to testing per year by fully automating mobile application testing.

Conducted by the market research firm Censuswide on behalf of Tricentis, a provider of a test automation platform, the survey also found that just under half of respondents (49%) reported their organization is already applying artificial intelligence (AI) to application testing. Another 21% plan to apply AI in the next six months. Almost three-quarters (74%) said their organization’s general sentiment toward AI in mobile software development testing is positive.

Respondents also expected AI to improve mobile application quality (37%), increase productivity (36%) enhance end-user experience (34%) and to reduce the number of vulnerabilities and/or bugs (32%) in their applications.

Mav Turner, chief product and strategy officer at Tricentis, said that rather than continuing to rely on expensive testing services, more organizations are looking to reduce costs by automating a wider range of testing workflows within the context of a DevOps workflow. In fact, the survey finds just under a third of respondents (32%) expect their organizations will invest more than $1 million to further automate testing.

As modernization of testing processes continues, the return on investment in mobile application development will only continue to improve, noted Turner.

The survey identifies the primary benefits of investing in test automation, which are increased productivity (32%), increased revenue (31%), increased user retention (28%) and increased compatibility across devices (28%).

The primary obstacles organizations encounter as they strive to achieve that goal are competing priorities (28%), lack of technology and talent (25%), time (25%) and cost (24%), the survey finds.

A full 87% said the quality of mobile applications is critical to their business, with 90% noting that poor mobile application quality costs their business as much as $2.49 million in lost revenue per year. However, just over a quarter (27%) said they believe their organization’s current mobile application development and testing strategy exceeds expectations.

As part of efforts to automate testing, it’s not clear just how far responsibility for testing is shifting left toward developers, but there is no doubt many more are being exposed to the results earlier in the software development life cycle. The goal is to provide continuous testing capabilities without overly disrupting code writing. It’s also becoming simpler for developers to leverage generative AI tools to provide summaries of tests along with recommendations to improve code. The end result should be higher-quality applications that require less troubleshooting once deployed in a production environment.

In the meantime, as organizations continue to become more dependent on mobile applications to drive a wide range of digital transformation initiatives, the cost of testing will continue to pale in comparison to the potential amount of lost revenue that might occur when end users either don’t invoke a specific feature or capability or, more commonly, simply abandon the application altogether.

March 29, 2024
Time to Extend DevOps Visibility to the Network Edge

Performance issues regularly confound DevOps teams after an application is deployed, despite the number of tests run before deployment. Upon further investigation, the issue that is most frequently overlooked is the distributed nature of the application itself. End users accessing applications from multiple locations are never going to have the same level of internet service, so software that may be running perfectly well in locations that are major urban technology hubs, such as New York, San Francisco or London, is not necessarily going to provide the same experience in farther-flung regions, especially rural areas that are halfway around the world.

All internet services are not created equal. Intermittent network latency issues can have a profound impact on application performance simply because of the laws of physics. The farther away an end user is from the data center where the application is hosted, the more likely it becomes network latency will adversely affect application performance.

Unfortunately, most DevOps teams lack any visibility beyond the data center environment where the application is running. Naturally, the first step toward gaining that level of insight starts at the edge of the network.

Internet Stack Visibility

There is a wide range of services that make up an internet stack, each of which can adversely impact the performance of distributed applications. Everything from virtual private networks (VPNs) and content delivery networks (CDNs) to domain name system (DNS) servers and switches adds latency that, depending on how network traffic is being routed, can have a major impact on application performance. Any one of these services might be experiencing an outage or, more challenging to detect, intermittent degradations that unpredictably impact application performance. Whether it’s a software-as-a-service (SaaS) application being accessed in the cloud or an internet-of-things (IoT) platform running at the network edge, pinpointing which internet service might be the root cause of an issue requires the ability to closely monitor and observe that traffic.

Without any visibility into the internet stack, surfacing the insights needed in a way that provides the context required to optimize and troubleshoot a specific application becomes an impossible challenge. All the time and effort spent building an application can come to naught simply because no one understood the impact network latency would have on the application before it was deployed. Even after an application is deployed, any change to the way network traffic is being routed can have major consequences. Without any means of understanding what changes may have occurred, it might be weeks or months before an organization realizes it may need to log a service request or switch service providers.

Any truly comprehensive approach to observability clearly needs to include an analysis of the internet services upon which organizations crucially depend to ensure a consistent application experience is delivered and maintained. Depending on how the IT team is structured, those insights can be fed into an observability platform that the organization has adopted or correlated using an internet performance monitoring (IPM) platform.

DevOps Needs NetOps

Regardless of the approach, it’s never been more crucial for network operations (NetOps) and DevOps teams to be able to align their approaches to monitoring distributed computing environments. More latency-sensitive applications are being deployed than ever. In an ideal world, DevOps teams working closely with NetOps should be able to programmatically provision and alter networking services as needed. Not every internet service can be adjusted via an application programming interface (API), but most NetOps teams have access to consoles that enable them to upgrade to different service levels when needed. At the very least, a service provider will work with them to make any changes required.

Of course, it becomes more challenging to negotiate if the NetOps team doesn’t know which element of the Internet stack needs to be upgraded. A service provider that typically doesn’t have any visibility into the application might spend weeks trying to determine which element of the Internet stack they manage is at fault. IT teams that have their own means of monitoring a set of internet services are going to be able to work with their service providers to resolve those issues much faster.

Summary

Savvy IT teams are all too aware of how prone internet services are to outages and brownouts, so as a rule, they tend to make sure network traffic can be rerouted from one service to another. That approach also provides the added benefit of maintaining some pricing leverage as they negotiate fees for the services provided.

It’s also worth remembering providers of networking services that know a customer is locked in may not have as much incentive to make sure networking services are running at peak efficiency. The only way an IT team is ever going to know what level of service is being delivered at any given time is, of course, to generate an IPM report that precisely details what services were actually available at what level of performance. Otherwise, they are wholly dependent on the report a service provider presents alongside their monthly bill.

Just as critically, the reports generated by an IPM platform also surface insights that, when shown to application developers, create a potential opportunity to optimize their code. Without that level of analysis, every developer will assume the network services are either broken or poorly managed. The challenge and the opportunity now is to provide internet performance intelligence in a way that every stakeholder cannot just act on but, just as critically, implicitly trust.

March 22, 2024
Edge Computing Requires DevOps at Scale

The rise of edge computing is about to drive a long-overdue convergence of DevOps, data engineering, security, networking, operational technology (OT) and machine learning operations (MLOps) best practices, which will ultimately make IT teams more responsive than ever to the needs of the business.

Historically, each of these IT disciplines has tended to work in isolation, with deliberate handoffs being made between the various teams employed to provision and maintain various services. The challenge is that as more applications are deployed at the network edge, the need for IT teams to work hand-in-glove is crucial. Applications not only need to be deployed across a much more distributed computing environment, but they also need to be regularly updated and patched.

At the same time, increasing amounts of data are being processed and analyzed at the point where it is collected and consumed. More stateful applications running at the network edge are passing aggregated analytics data back to applications running in the cloud or on-premises IT environment. That shift requires a fundamentally different approach to how storage is managed across multiple edge computing environments and the various federated backend systems spanning the enterprise.

Organizations will typically need to store files locally on edge computing platforms while also storing copies of those files in the cloud using an S3-compatible storage service that provides access to inexpensive object-based storage to enable everything from data protection to driving artificial intelligence (AI) applications. That multi-protocol capability creates an opportunity to not just build new stateful distributed applications but also modernize existing applications regardless of what protocols are being used to store data.

Most edge computing platforms today are managed by OT teams that report directly to the leaders of specific business units. However, as more of these platforms are connected to networks, the greater the imperative to centrally manage them as part of any effort to lower the total cost of IT. After all, the most expensive element of IT remains the cost of the labor still required to manage it.

Naturally, sharing data in near real-time across a distributed computing environment puts more pressure on network operations (NetOps) teams. Instead of updating applications in batch mode once a day, data continuously streaming from thousands of edge computing platforms needs to be synchronized with multiple applications to surface the latest, most accurate insights.

More challenging still is that much of that data is being used to train AI models that ultimately require the associated inference engine created to be deployed at the edge. To process terabytes of data, the underlying platform required to support those inference engines also will need to be measured in terabytes. Over time, AI models tend to drift or, in the case of generative AI, outright hallucinate, over time. Data scientists will need to work closely with DevOps teams to replace those AI models because, unlike a traditional application, they can’t be updated via a patch. The entire AI model needs to be replaced with one that is not just more reliable but also—and just as importantly—safer.

Finally, the need to secure edge computing platform is nothing short of critical. Cybercriminals tend to view these platforms as gateways to the rest of the enterprise. Each new edge computing platform deployed extends the size of the attack surface that needs to be defended. Unless cybersecurity teams are deeply involved in building and deploying edge computing applications and platforms, it’s only a question of when, rather than if, a breach will occur.

It may be a while before these various IT fiefdoms converge, but at this point, it is all but inevitable. In fact, it will soon be difficult to distinguish between edge computing and the rest of the IT environment as event-driven applications spanning multiple platforms become more the norm than the exception.

DevOps teams, as part of their relentless commitment to automation, should naturally be at the forefront of these efforts. Rather than confining DevOps principles to how applications are built and deployed, the time has clearly come to automate IT workflows on an end-to-end basis. The only way to programmatically manage edge computing at scale is to also apply DevOps principles at scale. Also known as platform engineering, that approach enables organizations to manage distributed IT environments at scale without requiring organizations to hire a small army of IT teams to manage it all. There will always be a need for specialized expertise, but as IT continues to evolve the siloes that slow down the pace of innovation will need to come down.

Not every member of an IT organization needs to know how to expertly manage every task, but they should be familiar with the inherent dependencies that exist between applications, networking, storage and cybersecurity to advance the goals of businesses that have never been more dependent on IT.

Each organization needs to determine the pace of convergence that best suits its needs, but the faster it occurs, the greater the return on the investment in edge computing will become. The challenge and the opportunity, as always, will be managing yet another major IT transition, where the issues that need to be resolved are as much cultural as they are technical.

March 22, 2024
Controlling Cloud Costs With Efficient Ramp Plans

A mix of rapid migrations to the cloud and complexity over usage and costs has companies desperately trying to reduce waste and gain control over their spending. Making matters worse is a volatile economy that has decision-makers on edge, considering cost-cutting measures and placing a priority on locking down revenue.

Without a formal FinOps or cost optimization strategy in place, it’s easy for companies to see cloud expenses snowball out of control. In fact, analysts from Gartner report that organizations that do not employ cloud cost optimization can overspend by up to 70%. That said, ramp plans are becoming a vital tool for containing cloud resources.

Still, while this strategy can show how to effectively grow your environment and increase workloads, the way a ramp plan is carried out is key to its success. The following looks at what companies should do to succeed with ramp planning accompanied by some strategic advice for handling unique needs that may arise.

Ramping Up

A ramp plan, at its most rudimentary level, is data tracking toward how your organization consumes cloud resources versus what it commits to with a cloud service provider (CSP) or reseller. By committing to spend a set dollar amount, you can get healthy discounts or other incentives. As an example, a 50% increase in consumption by the end of the year might earn a 10% discount from a CSP on compute workloads. But there is risk: A company is still obligated to pay that figure, even if it uses far fewer resources than it committed to.

Still, just as you don’t want to spend money needlessly, CSPs—even high-volume hyperscalers like Amazon AWS and Google GCP—would rather see customers get what they need and grow their footprint. For some organizations, the answer is bringing in a partner to help forecast spend. Questions regarding what is needed, past usage, anticipated growth, potential for acquisitions and more need to be answered. You also have to examine such things as product and service offerings. For instance, a subscription app you offer could catch fire and bring in customers—but you’ll need to plan accordingly so the resources will be in place to meet this demand.

Compiling and projecting this all isn’t easy, but this type of data is needed so you can develop a ramp plan and budget effectively. In the past, this process required time-consuming manual research, a host of spreadsheets and sophisticated algorithms. However, technology has been developed to automate, drive and scale this process. For some businesses, the ideal is to find a partner with this capability in-house and a depth of expertise to use it correctly.

Processes and Partners

Ideally, a ramp plan should be developed before a commitment is made. It should be reviewed on at least a quarterly basis with the C-suite and appropriate technical executives and then revised as necessary. On the whole, CSPs like to sign customers to contracts extending more than a year, with three-year terms being typical.

Working with a third-party partner, reseller or directly with a hyperscaler comes down to personal preference. Big companies, much like hyperscalers, tend to have a lot of bureaucratic processes and requirements. So, if you want a tactical agreement with AWS, you may have to buy tactical support. You may get a good financial incentive in exchange, but the cost of enterprise-level support could offset that.

Partners and resellers of cloud services, on the other hand, help hyperscalers scale their businesses, so they often have special arrangements that lower support costs. The development of ramp plans is usually less when going through a third party versus registering with a CSP. These services are often designed for smaller companies that larger CSPs don’t have time to handle. Third parties tend to provide tailored services more in tune with customer needs, including more flexible usage, optimization and security. These partners tend to negotiate more effectively than customers themselves because they better understand the ecosystem and which levers to pull.

Measuring Success

It’s not easy to measure and track the success of a ramp plan. Beyond understanding and meeting your commitment—and getting the most from cloud spend—the best measure is profitability. Are you just eating costs or acquiring new customers? Is your efficiency boosting or lowering your margins? It’s even possible to apply unit economics to assess if you’re making money on the resources being used.

Making a commitment and ramp planning should involve more than financial incentives. Maybe there’s some other strategic aspect you want to achieve? From service-level agreements to support, a lot of things can be woven into a commercial contract. Benefits can come in various forms, but when they’re added together, you can take success in the cloud to a whole new level.

March 14, 2024
The IaC Weight on DevOps’ Shoulders
It’s often challenging for established tech companies to adopt modern DevOps practices around infrastructure-as-code (IaC). It’s not so much in adopting the syntax, but rather the DevOps culture that IaC is part of for engineering organizations.

Organizations often struggle to transition from traditional operations models to collaborative DevOps culture, which is a byproduct of transitioning infrastructure operations to code.

In many cases, legacy tendencies persist, while IaC duties stay siloed within ops-centric DevOps teams—which is the exact opposite of the benefits of leveraging powerful technology like infrastructure-as-code. What this ultimately creates is bottlenecks in development velocity and product iteration.

With all this in mind, it begs the question: What changes can enable a smoother IaC journey?

The Pitfalls of IaC Silos

Having DevOps teams shoulder the entire IaC burden is the exact anti-pattern we’re looking to avoid when truly transitioning to DevOps culture in our organizations. What many organizations start to experience is these familiar pain points that start to emerge:

1.) Knowledge Gaps Widen

Developers—by nature of their day job as software engineers—often lack access, visibility and context into infrastructure changes. Yet, with more and more infrastructure requirements shifting left, they are left (pun intended) with insufficient capabilities to manage these growing needs.

This is compounded when they are faced with minimal cloud permissions. Limited permissions make it difficult to experiment and familiarize themselves with cloud tools and capabilities the way they would with code and its parts of the stack.

Meanwhile, DevOps teams—as the exact mirror image and the nature of their role in the organization—don’t grasp application needs and objectives. This often results in a widening chasm of broken communication and collaboration around IaC initiatives.

2.) Collaboration Suffers

A common tool that exacerbates the problem is a ticketing and support platform. Developers, as their modus operandi, lacking a shared understanding of the domain, will often resort to opening tickets to achieve their goals. This creates a culture of inefficient cross-team communication via ticketing systems.

This doesn’t mean the ticketing platforms are the problem, it just results in inefficient communication methods, as developers don’t always know what questions to ask.

What this does mean is that DevOps engineers operate largely on instinct, being mostly in the dark on the real application requirements that can’t all be communicated in a simple Jira ticket. This results in final solutions that rarely satisfy needs on the first attempt and take longer to deliver.

3.) Releases Slow to a Crawl

DevOps teams hold the responsibility for conducting and orchestrating release engineering, on top of provisioning environments, maintenance, monitoring and other tasks that fall in the DevOps engineering domain.

This is why DevOps tasks can become a bottleneck, as they not only dictate deployment timing (due to important considerations of uptime and client disruption, among others) but are also tasked with juggling infrastructure changes across many and multiple environments.

This causes unpredictable delays in provisioning dev environments and other developer-oriented tasks that frustrate developers and stall production updates, and delivery velocity.

The Obstacles of Change

Recognizing these inefficiencies and shifting these responsibilities left became the popular way for DevOps leaders to distribute IaC duties. This allowed developers to gain sufficient autonomy to choose the solutions for their needs, while DevOps teams provided guidance and oversight for how to practically achieve these solutions.

However, like all things shift left, this comes with its own set of unique challenges. Adopting the DevOps paradigm faces fundamental obstacles that add further complications and complexity to these cultural transitions, including:
- Uncontrolled sprawl
- Ballooning costs
- Security concerns
On the one hand, distributing the IaC load lessens the burden on the DevOps teams, but the downside is that it becomes difficult to understand which resources are actually in use and which have been temporarily created for testing purposes.

With many owners creating resources on demand, once they are no longer needed, these leftovers create confusion around dependencies and make cloud platforms disorganized and difficult to maintain.

Just like enabling more hands to touch IaC creates greater sprawl and disorder, more users with less governance invite careless sprawl in terms of costs as well. This often results in duplicate and unused resources accumulating, wasting budgets that are currently tight, and every penny counts. With a lack of automation and oversight, environments grow messy and expensive.

The sprawl issues can also impact security, as expanding permissions raises valid security concerns that are intensified when clouds become disorganized and difficult to maintain.

Well-intentioned developers may misconfigure resources or expose sensitive systems, and without proper methods to manage drift or misconfiguration, this can pose real risks to organizations and systems. Another important aspect that also increases with less oversight is intentional insider risk.

From Silos to Shared Responsibility

OK, that must have been really disheartening—and you’re probably thinking you should run for the hills before attempting any transitions to shared responsibility.

But wait—don’t panic yet. It is possible for teams to redistribute IaC responsibility while avoiding these pitfalls.

Below are some key factors to help you make the transition smoother in the short and the long term:
- Automate everything—If DevOps practices have taught us anything, it is that manual cloud environment maintenance doesn’t scale. Automation has been the backbone of much of the evolution we have undergone when it comes to infrastructure operations, and this has been powered by the programmability and everything-as-code mindset—from IaC to policy-as-code (PaC). This automation-based optimization makes it possible to reduce neglected resources through regular and automated analysis and response. What you get is cost savings and the prevention of runaway sprawl.
- Empower through governance—Remember when we spoke about automation and governance? Well, programmatic policy enforcement is a good way to constrain unwanted resource proliferation without manual intervention. Governance comes in to handle auto-remediation of misconfigurations or other anti-patterns that do not align with automated policies, which simplifies environment management at scale. Importantly, governance, if done right, can be a tool to empower teams, break silos and encourage autonomy. Having the right guardrails in place is how you instill confidence and provide helpful direction.
- RBAC for the win—Role-based access control (RBAC) limits permissions to appropriate needs, establishing important guardrails that can help prevent some of the issues we spoke about above, including sprawl and security concerns.
RBAC will enable developers to gain the necessary freedom while minimizing security risk. Minimum required access encourages responsibility and constraint.

Now that you have a solid grasp of the principles, it’s time to put them into action!

Fortunately, there are numerous solutions at your disposal. You can jump in and build them yourself using capable tools like Jenkins or Atlantis.

Alternatively, for a more comprehensive approach, there are excellent commercial IaC management tools on the market. These can assist you in reaching your objectives swiftly and with greater efficiency.

An Evolutionary Vision for IaC and DevOps

As technology complexity increases, no single team can handle infrastructure alone. Dev and Ops must unite abilities to shepherd modern systems and the underlying code powering them. This requires closing knowledge gaps through collaboration and communication

With a thoughtful process, IaC automation, governance guardrails and the right access policies, tech leaders can guide this cultural transition smoothly without exposing the organization to unnecessary risk and spending.

When done right, Shared IaC responsibility will boost velocity, agility, and autonomy—the trifecta of crucial traits that quantify and qualify elite engineering teams and differentiate companies in a competitive landscape.

Interested in learning more about env0 to manage your IaC at scale and confidently?

Stop by Booth L12 at KubeCon EU to speak with an expert or see a demo!

To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.
March 13, 2024
Leveraging eBPF for DevSecOps
eBPF is a revolutionary technology originating from the Linux kernel. It is used to safely and efficiently extend the kernel’s capabilities without requiring changing the kernel source code or loading kernel modules/extensions.

Today, eBPF is used extensively to:
- Provide high-performance networking and security in modern data centers and cloud-native environments
- Extract fine-grained security observability data at low overhead
- Provide insights for performance troubleshooting
- Provide preventive application and container runtime security enforcement
eBPF-Enriched Context

eBPF is the base data layer that is needed in runtime cloud security. eBPF gives you information at a high level on Layers 3, 4 and 7, allowing you to see all network communication and correlate it with processes and specific applications that are communicating on those ports.

To fully leverage eBPF, you need to pair this raw data with additional cloud infrastructure context to gain a full understanding of which resources and services are in use.

For example, by leveraging eBPF, you can determine if you have 10 different applications all communicating on port 443, whereas a traditional network monitoring tool would tell you that you have a certain amount of traffic on this port but wouldn’t be able to segment this traffic and show how much of that traffic is coming from each individual application.

Knowing which communication is coming from an individual application increases visibility. It allows you to see what your applications are doing in real-time and identify signs of compromise or decreased performance.

Increasing Observability With eBPF

eBPF provides users with intrinsic, comprehensive insight into communication flows across the entire system. The applications for enhancing security observability with eBPF are vast, ranging from enabling highly detailed process visibility to facilitating end-to-end observation of processes and flows.

When dealing with Layer 4 to Layer 7 traffic involving multiple protocols, eBPF emerges as an optimal solution. Through eBPF, TLS traffic traversing pods, nodes and cloud platforms can now be uniformly instrumented across layers.

In other words, with eBPF, you can observe your application and your node and gain a vast amount of raw data, which, with the right tools, you can correlate to understand your entire network topology.

Beyond eBPF Raw Data to Context and Correlation: Layer 7 and Beyond

Specifically for observability, you can use eBPF to apply filters directly in the kernel, which reduces the overhead and allows you to ingest significantly more raw data. eBPF’s architecture allows you to do all of this, observe network traffic and Layers 3, 4 and 7 without compromising your security or performance.

With eBPF, you are able to understand the execution events, system call events and all of the network ingress and egress. But it’s not always enough.

You will need to correlate it with Cloud APIs, Kubernetes identities, pods and namespaces to understand the actual identities and relationships between the individual workloads, all the way down to the application layer. By doing so, you are able to understand application-level identity and use this context to understand your application behavior as well as your most critical risks and threats.

Leveraging eBPF for Threat Detection and Response

Security and networking observability are inherently interconnected. eBPF helps you to gain insights such as abrupt shifts in behaviors, spikes in activity within specific processes indicating potential exploitation or attacks, service-to-service communication trends and more. These projects enable users to examine network transactions, identifying the pods, processes and system calls involved.

With eBPF, you can see OS-level runtime threats. eBPF gives you the ability to listen to system calls but also to go one step further and block or terminate any process, PID (process identifier), system call or network packet. This allows for a more granular approach to automated threat detection and response without damaging your system or hurting your infrastructure.

You can also use eBPF to implement prevention rules, meaning you can instruct eBPF to automatically block any malicious processes or pre-designated system calls or network packets, going beyond traditional uses of eBPF for monitoring and security, to become a more proactive, preventative tool for securing your infrastructure and applications.

Real-World Benefits of eBPF

eBPF presents a number of real-world benefits, going beyond traditional monitoring, observability and security to help with overall alert noise reduction and improved forensic analysis.

How eBPF Contributes to Noise Reduction

By itself, eBPF does not reduce noise. In fact, it increases because of the influx of raw data from every system call. However, with the right tools, you can leverage this raw data and correlate it with additional context to understand your infrastructure and application behavior. This effectively reduces the alert noise that you would otherwise receive because you can view more detailed insights into resource behavior.

By filtering and aggregating this data, you receive more insights about applications, overall giving you less noise because you’re focusing on what actually matters.

By having this eBPF raw data at runtime, you can apply intelligent filters to filter through the most important data and use it accordingly, resulting in better prioritization, more focused efforts and increased operational efficiency.

Forensic Analysis

Another important real-world use case for eBPF is conducting forensic analysis. By leveraging eBPF’s raw runtime data and applying intelligent filters, you can quickly pinpoint problem origins and conduct forensic analysis at the application level.

By leveraging eBPF’s raw data from Layer 7, you gain a granular understanding of applications and the process-level communication within an application, allowing you to foresee the potential blast radius if an application were compromised in terms of who it could interact with and what damage could occur.

Conclusion

In summary, eBPF is a powerful technology that can be effectively leveraged for monitoring, observability and security purposes. However, when eBPF’s raw data is combined with context from cloud APIs, it can be leveraged even further with intelligent filters to provide unparalleled cloud infrastructure and application context, allowing you to understand application-layer identity, provide real-time security, pinpoint problem origins and stop threats with surgical, active response.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.
March 11, 2024
appCD Launches Platform to Securely Provision Cloud Infrastructure

appCD this week launched a namesake platform that analyzes an application about to be deployed to automatically generate the code needed to provision the IT infrastructure required.

Fresh from raising $6 million in seed funding, appCD CEO Sachin Aggarwal said that approach makes it possible to consistently create secure code for provisioning IT infrastructure versus requiring developers with little to no cybersecurity to manually write it.

Instead, appCD reviews Python or Java code to understand intent, identifies dependencies and then infers application programming interface (API), service configuration, ingress/egress and other environment variables. Terraform code or Helm charts are then automatically generated based on the static analysis of the code that has been reinforced using artificial intelligence (AI) learning techniques.

That approach also makes it simpler for platform engineering teams to centrally manage the provisioning of IT infrastructure using a set of pre-defined policies that are automatically implemented each time an application is deployed to ensure security by default, he added.

DevOps teams can also use appCD to visualize the deployment environment before and after an application is deployed, said Aggarwal.

While infrastructure-as-code (IaC) tools have accelerated the rate at which cloud infrastructure can be provisioned, they are also often the root cause of the security issues that plague cloud computing environments. Developers often misconfigure cloud infrastructure by, for example, inadvertently leaving ports open. The appCD platform reduces the potential such mistakes will be made, noted Aggarwal.

That capability also eliminates the need to attach cybersecurity specialists to a DevOps team because issues are automatically resolved by the guardrails enforced by appCD, he added.

In theory, at least, there may soon come a day when AI routinely improves the quality of the code being used to both build and deploy applications. The more the code used to train a large language model (LLM) is vetted, the more reliable the output becomes. In the meantime, platforms such as appCD are combining static analysis with AI reinforcement learning to achieve that same goal in a use case that is specific to generating code to provision IT infrastructure.

Each DevOps team will naturally need to determine the best path forward, but as regulations pertaining to securing software supply chains become more stringent, it’s only a matter of time before organizations will be required to embrace DevSecOps workflows. In the meantime, DevOps teams should assume that given the probability cloud infrastructure has been misconfigured, it’s all but certain there will be multiple cloud security incidents. In fact, cybercriminals are actively scanning for misconfigurations that they have already created playbooks to specifically exploit in a matter of minutes.

In the absence of being able to prevent all those issues from arising, the immediate priority becomes remediating as many issues as possible before cybercriminals exploit those vulnerabilities. However, it’s also important to draw a proverbial line in the sand to ensure that all cloud infrastructure being provisioned in the future is much more secure than it has tended to be thus far.

March 7, 2024
Permiso Makes Open Source Tool to Identify Cloud Threats Available

Permiso today launched an open source tool dubbed CloudGrappler that surfaces indicators of compromise in cloud computing environments.

Based on a cloudgrep project originally created by Cado Security, CloudGrappler detect patterns that Permiso, a provider of an identity threat detection and response platform, associated with tactics and techniques commonly used by various cybercriminal syndicates.

The tool enables DevSecOps teams to define the data sources they want to scope in a scan of an Amazon Web Services (AWS) or Microsoft Azure cloud. Via a JSON file, DevSecOps teams can access a list of predefined tactics, techniques and procedures (TTPs) that are commonly used to exploit cloud computing environments. DevSecOps teams can also dynamically add queries or a file with multiple queries to scan a specific data set. After scanning, CloudGrappler delivers a JSON report that provides a breakdown of the scan results.

Ian Ahl, senior vice president for P0 Labs, the research arm of Permiso, said that capability makes it possible for DevSecOps teams to identify issues in cloud computing environments that warrant further investigation before there is a major incident. The primary goal is to make it simpler for DevSecOps teams to determine if they need additional assistance to thwart a potential threat, he added.

Cybercriminals are, like almost everyone else, creatures of habit and often tend to leverage the same TTPs multiple times simply because they know they’re effective. However, those TTPs also provide clues to their presence in an IT environment. Once discovered, a DevSecOps team can decide if they can remediate the issue themselves or need to tap external cloud security expertise, noted Ahl.

In general, cloud computing environments may be more secure than most on-premises IT environments. However, the processes used to provision cloud computing environments are often flawed because developers typically don’t have much cybersecurity expertise. Misconfigurations are often rife across cloud computing environments.

Cybercriminals are also especially adept at stealing credentials to gain initial access to cloud computing environments, which they leverage to escalate privileges in a way that provides them unfettered access to the entire cloud computing environment.

Adoption of DevSecOps best practices has improved cloud security, but there are still plenty of instances where, for example, a port inadvertently left open has enabled cybercriminals to infest a cloud computing environment with malware that could lie dormant within cloud applications for months before finally being activated.

There are simply not enough cybersecurity experts available to secure cloud computing environments, so it’s going to be largely up to DevOps teams to secure them. The issue is that in the race to build and deploy applications as quickly as possible, cloud security best practices are either forgotten or simply ignored. Of course, it’s that very carelessness that cybercriminals are counting on to allow them to wreak havoc in an era where the percentage of mission-critical applications running in cloud computing environments will only continue to increase exponentially.

March 7, 2024
AISecOps: Expanding DevSecOps to Secure AI and ML

The evolution from traditional software development to integrating artificial intelligence (AI) and machine learning (ML) has been nothing short of revolutionary. As AI adoption continues and AI technologies become essential to businesses and even our daily lives, they are increasingly prime targets for cybersecurity threats.

A particularly alarming trend is the targeting of code and image repositories by cybercriminals aiming to inject malware into the software supply chain. This tactic not only compromises the integrity of the software but also poses a significant risk to end-users and organizations that rely on these applications for critical operations. The threat of data poisoning presents a sinister challenge to the integrity of AI models. By introducing maliciously modified code and data into the training sets, attackers can manipulate the behavior of AI systems, leading to long-term impacts as the poisoned data persists within machine learning models.

This insidious form of attack underscores the importance of vigilance and robust security measures in safeguarding the data that fuels AI and ML innovations. The cybersecurity landscape has been profoundly shaped by our experiences in securing software through DevSecOps practices. These lessons now serve as invaluable blueprints for addressing the familiar challenges posed to AI and ML security, including the need to protect our software supply chain and the integrity of AI models from such insidious attacks.

Over the past five-plus years, DevSecOps has become a staple of how we develop and secure software through collaboration between software and security teams and by embedding improved security practices into every phase of the development process. Is DevSecOps “there yet” as our answer to our software security challenges? No, but it is continuing to improve and evolve as most security practices do. This integrated approach has helped us improve our software products’ security and increased the security visibility between security and software engineers. The principles and successes of DevSecOps can similarly guide the secure development and deployment of AI and ML models.

AI and ML models continuously learn and evolve, making them unique compared to traditional software. AISecOps, the application of DevSecOps principles to AI/ML and generative AI, means integrating security into the life cycle of these models—from design and training to deployment and monitoring. Continuous security practices, such as real-time vulnerability scanning and automated threat detection, protection measures for the data and model repositories, are essential to safeguarding against evolving threats.

One of the core tenets of DevSecOps is fostering a culture of collaboration between development, security and operations teams. This multidisciplinary approach is even more critical in the context of AISecOps, where developers, data scientists, AI researchers and cybersecurity professionals must work together to identify and mitigate risks. Collaboration and open communication channels can accelerate the identification of vulnerabilities and the implementation of fixes.

Data is the lifeblood of AI and ML models. Ensuring the integrity and confidentiality of the data used for training and inference is paramount. Lessons from DevSecOps emphasize the importance of secure data handling practices, such as encryption, access controls and anonymization techniques, to protect sensitive information and prevent data poisoning attacks.

Embedding security considerations from the outset is a principle that translates directly from DevSecOps to AI and ML development. This approach also aligns with the growing emphasis on ethical AI, ensuring that models are not only secure but also fair, transparent and accountable. Incorporating security and ethical guidelines from the design phase helps build trust and resilience in AI systems.

The security challenges presented by AI and ML technologies are complex but not new to us. It’s no silver bullet, but we must utilize the lessons from DevSecOps’ successes and failures. By applying DevSecOps lessons learned to AISecOps, we can approach these challenges with approaches that elevate the visibility of AI and AI data security and emphasize continuous security, collaboration, secure data practices and security by design.

Our future is AI-driven; cybersecurity and AI professionals must come together to fortify the foundations of these transformative technologies. It is critical we unlock the full potential of AI and ML while ensuring the safety, privacy and trust of all stakeholders involved.

March 6, 2024
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.

March 6, 2024