devopsy.kinsta.cloud

Category: Application Performance Management/Monitoring

  • Considering Scriptless Automation: iOS App Dev in 2023

    Considering Scriptless Automation: iOS App Dev in 2023

    According to Statista, over 31,000 apps were released on Apple’s App Store in March 2023. As impressive as that is, it’s considerably smaller than the number of apps submitted to the Apple store during the same month.

    And it’s probably less than the number of apps removed from the App Store.

    Why?

    According to Apple, most submissions fail because of common issues like bugs, crashes, incompleteness, placeholder data and broken links.

    But getting app approval is just one of many challenges faced by iOS developers today.

    Contemporary iOS App User Expectations

    The truth is, even if you slip by Apple, there’s an even greater critic to be concerned about: Your audience. Users are much less forgiving and have high expectations. If your app isn’t perfect, you’ll lose your chance at meaningful adoption and your users will just go elsewhere.

    For iOS users, perfect is simply the status quo, and users have grown to expect it. In practice, this means that apps must be stable across devices and versions, see regular improvements. and provide a great user experience at all times.

    Seamless experience between devices, versions and iterations
    iOS users expect the same experience across multiple devices. From one iPhone to the next, from version to version and from screen size to screen size. It’s the responsibility of developers to prioritize a consistent experience across devices.

    Fast release cycles and regular updates
    Contemporary app users demand feature-rich applications that go above and beyond the simple functions they expect from an app. Given the statistics above, chances are that the competition is fierce. Achieving success usually requires an efficient and speedy release cycle with more planning, more deployments and more testing.

    Easy and frictionless user experience
    User experience (UX) and functionality are one of the big reasons iOS adoption is so strong. People have come to expect high quality from anything under the Apple banner: Users expect an intuitive and trouble-free user experience on every app with which they interact. Every user’s experience needs to be intuitive, issue free and consistent with other iOS applications.

    Challenges Abound

    Meeting those escalating user expectations comes with a wide variety of challenges. For example:

    Device landscape fragmentation
    With so many device types and form factors in circulation, how do you test across all of them? With dozens of iterations of the iPhone combined with an array of versions, screen sizes and configurations, app developers need a way to test on enough devices to cover the majority of their user bases.

    This leads many developers to turn to simulators and emulators to cover devices they lack access to.

    This poses another problem. Simulators aren’t perfect. A simulator doesn’t replicate the functions of the actual device; it can only mimic certain aspects of an iOS device. And it simply can’t effectively mimic hardware, component functionality or network.

    Using a simulator, you can’t test how an application will respond to factors like low battery, a rising network spike, or limited memory, not to mention GPS and camera functionality. You also can’t monitor usage metrics or run meaningful performance tests.

    Real devices present their own challenge. The vast majority of the time, developers will have to worry about the cost of acquiring, storing, maintaining and updating devices. In addition, they’ll have to centralize and control access to them. In an increasingly remote workforce, it’s not a great strategy.

    Manual tests
    Today, most organizations are over-reliant on manual testing. The result? Running test cases becomes the bottleneck that holds up releases. Sure, manual testing is unavoidable in some cases, but their ad-hoc, inconsistent nature leaves room for error. No matter how detailed the instructions may be, people test differently, and that’s a disaster waiting to happen in today’s complex software world.

    Maintaining complex test scripts
    If you’re automating test cases, you’ve experienced the pain of maintaining code-based test scripts. Every release requires coinciding updates to countless unit tests, integration tests and UI tests. The smallest changes can break test cases, causing false negatives and more deployment delays.

    On top of that, you’ve also got to worry about retaining talent that understands your language-specific testing framework. Given the economic uncertainties of today, that’s certainly not a good situation to be in.

    Constant iOS updates
    Each year sees Apple deliver iOS major releases and a variety of minor releases, patches and bug fixes. Organizations have to test after two release cycles: Their own and Apple’s. Failure to do so can lead to compatibility and App Store compliance issues.

    App store guidelines
    As I mentioned above, Apple maintains strict guidelines for any apps published on the App Store. Excellent testing can mean the difference between releasing an app or waiting another few weeks for the next approval. When time is money, this adds up fast.

    Security at scale
    As requirements change, scope increases and features add up, it’s easy to see how it can become more and more challenging to monitor for potential security flaws. In turn, testing needs to be continually updated to reflect the latest security risks.

    A Shift Toward Scriptless Solutions

    Scriptless automation is part of a growing industry of no-code automation tools, often dubbed the no-code revolution. It’s everything test automation is without the reliance on code-based frameworks.

    Scriptless test automation involves recording user interactions with app elements, asserting expected outcomes and assessing the results. The test is then automated, templatized and extended to test other scenarios.

    With scriptless test automation, you can walk through test cases step by step. Some tools even allow you to test on live devices and choose from real iOS devices that are hosted in the cloud.

    Scriptless testing allows you to:

    ● Easily reuse and templatize test scripts. Scriptless automation makes it easier to reuse test cases, create templates and compose new test cases.

    ● Enable faster time to value. Write test cases quicker, make changes without knowing how to write code and integrate directly with your CI/CD tool. As soon as you make changes to your application, your testing team is right there. Some no-code testing tools can analyze your source code and identify testing gaps so that you can address them right away.

    ● Untangle the web of code-based dependencies. With scriptless iOS test automation, testers don’t have to lift and shift their code every time they make a big change. Instead, the no-code framework provides a visual, easily-navigated UI that tells you simply what’s passing, what’s failing and what needs to be updated.

    ● Improve collaboration between teams. Scriptless iOS test automation improves collaboration between testers and developers by making it easy for all teams to visualize test cases.

    Real Device Testing

    When the pain points of fragmentation meet the shortcomings of simulation, developers are wise to test on real devices. At the end of the day, live device testing is the only way to accurately capture an end user’s experience.

    Yet it’s no secret that managing your own device lab is expensive and unrealistic for modern remote work environments. A real device cloud setup solves this problem: A device cloud hosts devices for you that you can access from your desktop, from anywhere.

    Given the ever-increasing complications of today’s mobile app landscape and the incredibly cut-throat mobile app landscape, it’s worth keeping in mind that you may only get one chance at making the right impression on your audience. Getting testing right is the key.

    Into the Future

    Everyone expects more. As a competitive organization, you have to do more with less: Fewer resources, less time and less room for error. Scriptless automation and real device testing won’t guarantee that your app stands out from the crowd, but it will certainly help.

  • New Relic Adds App Security Testing Tool to Observability Platform

    New Relic Adds App Security Testing Tool to Observability Platform

    New Relic today made available a public preview of an application security testing tool that will be integrated into its observability platform.

    Esteban Gutierrez, CISO and vice president of information security for New Relic, said the New Relic Interactive Application Security Testing (IAST) will provide DevSecOps teams with the context needed to identify the root cause of a cybersecurity issue down to specific lines of code.

    DevSecOps teams will be able to take advantage of IAST to identify vulnerabilities both in code as it is written and after it has been deployed in a production environment without any false positives, he noted.

    New Relic achieves that goal using deterministic testing techniques that surface an actual proof-of-exploit using observability data collected from both applications and the underlying infrastructure upon which they depend, said Gutierrez. DevSecOps teams are then provided with guided remediation suggestions, guardrails and tracking tools to both remediate the issue at hand and prevent it from reoccurring, he noted.

    New Relic IAST takes advantage of the agent software New Relic provides to collect observability data, which reduces the total cost of DevSecOps by providing IT teams that have adopted the New Relic platform with an integrated set of application security testing tools that doesn’t require them to acquire and manage a separate additional platform, added Gutierrez.

    That approach also ensures that application security testing is integrated with the continuous integration/continuous delivery (CI/CD) platforms that New Relic already observes, he added.

    The reason most vulnerabilities are not remediated in a timely fashion is the DevOps teams responsible for creating and deploying the required patches lack any context. They often don’t know, for example, how many instances of a vulnerability there might be or the actual level of severity. Without those insights, it becomes exceedingly difficult to prioritize remediation efforts, noted Guttierrez.

    As application security requirements become more stringent in the wake of forthcoming legislation, it’s now more of a question of when than if organizations will be required to better secure their software supply chains. The issue DevOps teams face now is finding a way to integrate application security testing tools into existing DevOps workflows without slowing down the pace at which applications are being developed.

    Of course, not every vulnerability discovered requires the same level of attention. Depending on its severity and likelihood of being exploited, DevOps teams need to prioritize which vulnerabilities need to be remediated first. There simply are not enough resources available today to fix every vulnerability an application might have. For the foreseeable future, there will remain technical debt involving vulnerabilities that will need to be addressed after an application is deployed in a production environment.

    The issue, of course, is that cybercriminals are getting more adept at exploiting those vulnerabilities. The amount of time any DevOps team has to resolve issues before they result in a breach continues to dwindle.

  • Dynatrace Adds Generative AI Capabilities to Davis Engine

    Dynatrace Adds Generative AI Capabilities to Davis Engine

    Dynatrace today revealed it has added generative artificial intelligence (AI) capabilities to its Davis engine it uses to apply machine learning algorithms to its observability platform.

    Steve Tack, senior vice president for product management at Dynatrace, said that hypermodal approach to AI will allow DevOps teams to take advantage of probabilistic AI capabilities provided by Davis CoPilot that are enabled by large language models (LLMs) originally developed by OpenAI.

    The generative AI capabilities effectively provide DevOps teams with a tool that surfaces workflow recommendations via a natural language interface. The recommendations are based on historical data such as sales and customer experience trends, seasonality and cloud application health. It is also able to analyze dependencies across large sets of data while retaining context accessed via the Dynatrace Grail data lakehouse and the Dynatrace Smartscape application visualization and mapping framework.

    Dynatrace is now making a case for a multimodal AI platform that uses a common set of metrics, traces, logs, user behavior and topology to enable machine learning algorithms to predict anomalies and causal-AI dependencies to determine the root cause of an IT issue and then leverage generative AI to provide recommendations to resolve it. The company is forecasting IT teams will achieve 10% to 20% productivity improvements year-over-year as a result.

    It’s too early to determine the full extent to which a multimodal approach to AI will transform IT management, but it’s clear that as IT operation teams become more productive, more time will be freed up for innovation, noted Tack. Many of the manual tasks that IT teams still need to perform divert time away from building and deploying additional applications, he added.

    Naturally, there’s a lot of speculation concerning the impact AI will have on DevOps. Some contend it’s only a matter of time before the entire software engineering process is automated. As those advances are made, the cost of building applications will effectively drop to zero. Others argue that AI will augment DevOps teams in a way that makes it simpler to manage IT at scale using either the same number or possibly even fewer engineers.

    The one thing that is certain is that AI will soon be pervasive, which will drive the adoption of automation frameworks as organizations look to operationalize the insights surfaced by AI platforms. As rich as the insights any AI model surfaces might be, they only provide real value when integrated with an automation framework, noted Tack.

    Ultimately, most DevOps professionals will not want to work for organizations that don’t provide them with AI tools that make it more likely for them to be successful. Organizations that embrace AI may not have a sustainable competitive advantage when every other organization is doing the same, but those that don’t will soon be left behind. Those that succeed will benefit from managing application environments at a previously unprecedented level of scale at minimal additional cost. The challenge is determining which tasks will be automated with an eye toward planning how DevOps roles will need to evolve.

  • How Platform Engineering Bridges the IT and DevOps Divide

    How Platform Engineering Bridges the IT and DevOps Divide

    Ballooning lead and process time, with an opaque corollary relationship to fixed and marginal cost, is a significant and complex burden for any enterprise. And multi-cloud complexity and inefficient organizational and technical processes are some of the most wasteful areas companies face–so much so that Synergy Research reports organizations are cutting back on their cloud spend as tech budgets continue to fall under intense scrutiny, resulting in a Q1 2023 cloud spending growth rate of 19% compared to 32% just last year. With cloud cost containment a top priority, Forrester advised tech leaders to demonstrate to CFOs how they will stay on budget and demonstrate ROI at the board level. A key area where companies can eliminate expensive waste and increase time to value is the relationship and workflow between IT and developers, which, while being the DevOps charter for nearly 15 years, has gotten less attention among the viable cost-containment strategies for enterprises in 2023. Revisiting the latest iteration of this DevOps charter through the implementation of platform engineering strategies can help enterprises create a faster, leaner and more scalable dynamic. Let us examine why it’s now time for enterprises to consider platform engineering as a potent way to not only increase efficiency but also to bridge the divide between DevOps and IT.

    The Old Way: Forcing DevOps to Dance to the ITSM Tune

    In traditional enterprise organizations, IT typically dictates a top-down ITSM practice that limits the tools an organization can use for development and deployment; in many cases, it inhibits CI/CD and other core capabilities and practices of DevOps. This awkward attempt to accommodate modern DevOps practice through an aging ITSM paradigm has led to a suboptimal software delivery performance and poor developer experience (DX).

    McKinsey, highlighting the criticality of DX, found developers at a leading SaaS provider spent 20% to 30% of their time integrating different services such as firewall changes, DNS and security access to deliver code through its CI/CD pipeline. That’s a lot of time spent on low-value, repetitive tasks, ensuring a painful journey for a disappointing result. If the DX pain is high enough, developers often go around IT and create resources on their own, leading to shadow IT, adding new cost burdens and growing security exposures. Every minute and engineer count: Five minutes saved per day among 500 developers saves a week’s development time.

    Surely, there is a better way.

    Platform Engineering: Collaboration Through Composition

    Platforming engineering and “platform as a product” have been key to the PaaS ecosystem for years but are now gaining fresh traction in the industry. In Puppet’s State of DevOps Report, 51% of respondents said they had already adopted platform engineering and 93% said it was a step in the right direction. Gartner predicted 80% of software engineering organizations will have platform teams by 2026.

    The concept can be defined in several ways. Gartner reported platform engineering is “an emerging trend intended to modernize enterprise software delivery… designed to support the needs of software developers and others by providing common, reusable tools and capabilities, and interfacing to complex infrastructure.” PlatformEngineering.org’s recent blog post defines it as the discipline of designing and building toolchains and workflows for self-service capabilities in software engineering organizations during the cloud-native era.

    Regardless of definition, platform engineering is the latest iteration of IT centralization, though now attempting to retain all the benefits of distributed team empowerment through “composition” rather than converged control. As modernization continues, we experience the ebb and flow of composition and decomposition, both organizationally and technically. Microservices, Kubernetes, and GitOps patterns pushed the rational limits of decomposition and significantly raised the level of technical complexity in the enterprise. The natural counter pressure is a new cycle of composition that aims to simplify that complexity through platform engineering practices. Teams now look for these toolchains and workflows to be centralized in internal developer platforms (aka IDPs), exposing the development, deployment and maintenance of the entire life cycle of modern, cloud-native applications.

    IDPs can facilitate the flow, speed and innovation DevOps teams are demanding without sacrificing stability, security and control. They enable developers to configure their toolchain while meeting all controls through approved blueprints or “golden paths,” reducing lead and process time. Developers can focus on delivering business value instead of infrastructure tasks.

    Bringing IT and DevOps Back Into Alignment Saves Time, Money and Sanity

    Platform engineering creates a collaborative framework that connects IT and DevOps teams, so they can focus on outcomes rather than methods. Developers can use an IDP to follow conventions that speed up development and prevent anti-pattern creep. Guardrailing choices through golden paths reduce cognitive load and simplify execution context for security teams. The result? Developers can focus on what they were hired for and want to do–creating innovative, transformative applications and differentiated value. Security can sleep well knowing bespoke behavior isn’t opening new attack surface areas.

    On the Day 2 operations side, IDPs enable SRE and support teams to have a fleet-wide view and work effectively with developers to streamline the management of production needs across all applications, clouds and tech stacks.

    The reframing of composition breaks the false dichotomies between IT and DevOps practices. You don’t have to choose between control and flow, change isn’t triggered by serial requests or async events, safety isn’t found in planning or speed, value isn’t found in stability or innovation and administrative plane primitives aren’t servers or clusters. Platform engineering practices allow you to prioritize composition, orchestration, golden paths, holistic scalability and fleet management to get teams out of entrenched myopia and embrace systems thinking that gets your business delivering strategic gain instead of tactical win/loss tallies.

    Finally, platform engineering positively impacts software delivery and operational performance metrics by streamlining development processes and reducing manual efforts. The bottom line is faster time to market while ensuring more consistency, less human error and improved software quality. This maximizes productivity, minimizes downtime and optimizes resource utilization, leading to cost advantages and increased efficiency for enterprises.

  • Webb.ai Launches AI-Based Continuous Root Cause Analysis

    Webb.ai Launches AI-Based Continuous Root Cause Analysis

    Webb.ai today opened an early access program access to a Continuous Automated Root Cause Analysis platform that uses artificial intelligence (AI) combined with a knowledge graph to dynamically keep track of and analyze changes to IT environments.

    Manish Gupta, CEO of Webb.ai, said the platform uses a mix of machine learning algorithms and generative AI capabilities based on large language models (LLMs) to aggregate alerts into higher-order insights that are presented in natural language to members of a DevOps team.

    That approach differs from legacy approaches because it tracks causal relationships between changes versus relying on probabilistic models that tend to create a lot of false positives, he noted.

    Webb.ai is also taking advantage of Kubernetes clusters to enable its platform to scale up and down as needed when analyzing data, added Gupta. That platform is also more efficient than other approaches to observability that require IT teams to store massive amounts of data. In contrast, the Continuous Automated Root Cause Analysis automatically surfaces anomalous events that DevOps teams can choose to save rather than requiring them to save all the metrics, logs and traces that would otherwise need to be tracked, he noted.

    Most IT incidents can be traced back to the most recent changes made to an IT environment. The challenge is as IT environments have become more complex, it’s not feasible for humans to keep track of those changes without relying on AI and a knowledge graph, said Gupta.

    As businesses become more dependent on software to drive digital processes, the cost of downtime is exponentially increasing. The need to identify the root cause of an IT incident as fast as possible has become a critical requirement, he added.

    Webb.ai doesn’t see AI technologies replacing the need for DevOps professionals and site reliability engineers (SREs) for at least another 10 to 15 years. In the meantime, many tasks that today are completed manually will be increasingly automated, said Gupta. A DevOps engineer dragged out of bed at 2:00 A.M. to address an issue does not want to have to sift through alerts. Instead, generative AI tools will summarize the issue at hand with recommendations on resolving it, noted Gupta. In effect, DevOps teams will be augmented by AI so they can manage IT environments at even higher levels of scale, he said.

    There is always going to be some sense of fear and loathing when it comes to AI, but ultimately, AI should reduce the burnout rates that today adversely affects any organization’s ability to retain DevOps professionals. Far too much time is spent trying to identify the root cause of a slowdown in a cloud-native application’s performance that could be caused by any number of issues involving one dependency or another. The frustrating thing, of course, is that while it may take days to identify the root cause of an issue, it often takes just a few minutes to resolve.

  • Splunk Goes Azure With Microsoft Partnership

    Splunk Goes Azure With Microsoft Partnership

    It’s not every day that a well-established technology provider announces they are building their solutions on a new cloud technology stack, but that’s what Splunk announced at its .conf23.

    “…[O]ne of the most exciting [announcements] is Splunk’s new strategic partnership with Microsoft to build Splunk’s cloud solutions natively on Microsoft Azure. Together, our approach will enable our joint customers to migrate, modernize and grow their environments with end-to-end cloud and hybrid visibility at scale,” Splunk President and CEO Gary Steele said in a Splunk blog post this morning.

    Why such a bold move, might you ask? “Splunk’s strategic partnership with Microsoft to build Splunk natively on Azure demonstrates our commitment to advancing digital resilience and meeting our customers where they are…” Well, indeed, a big, big draw is the vast landscape of customers building and operating applications in Azure. While Gary didn’t share too many details about specific new capabilities or offerings yet, customers will get to use their Azure credits for Splunk offerings. I suspect two other important underlying factors made such a tech marriage happen: Open source and AI.

    First, Microsoft is far removed from the days of being viewed as a pariah by the open source community and is now a leader and contributor to well-known open source projects (OpenTelemetry, to name one); it abandoned its proprietary service mesh tech and got behind Istio (a recently-graduated CNCF project) and now owns the largest open source repository ecosystem with GitHub.

    While Splunk is by no means a noob when it comes to incorporating AI into products, the company continues to announce new AI capabilities, including a generative AI chat interface with a preview of Splunk AI Assistant, an improved version of the former SPL Copilot. Other AI-related announcements include Splunk App for Data Science and Deep Learning (DSDL) 5.1, which allows customers to leverage LLMs to build and train models with their domain-specific data for text summarization and text classification use cases. Stay tuned for more from .conf 2023!

  • Splunk Adds Generative AI Tool and OpenTelemetry Collector

    Splunk Adds Generative AI Tool and OpenTelemetry Collector

    At its .conf23 conference, Splunk today revealed it added a slew of capabilities to its portfolio of operational analytics tools, including an assistant that leverages generative artificial intelligence (AI) capabilities that use large language models (LLMs) the company developed to enable IT teams to use natural language to invoke the Splunk Processing Language (SPL).

    In addition, Splunk is also previewing OpenTelemetry Collector, an add-on that uses open source agent software being developed by the Cloud Native Computing Foundation (CNCF) to capture metrics and traces. It is designed to enable IT teams to use OpenTelemetry alongside existing agent software that Splunk uses to capture metrics.

    Tom Casey, senior vice president for products and technology at Splunk, said the domain-specific LLMs that the company created enable Splunk Assistant to write or explain customized SPL queries in a way that augments rather than replaces the need for IT professionals. Splunk Assistant is designed to surface recommendations to optimize IT environments to reduce toil rather than automate entire processes, he noted.

    Splunk is adding other tools infused with machine learning algorithms to its portfolio. These include the Splunk App for Anomaly Detection and an Outlier Exclusion for Adaptive Thresholding to detect and omit abnormal data points that has been added to version 4.17 of the Splunk IT Service Intelligence platform.

    In addition, Splunk is previewing an ML-Assisted Thresholding tool for Splunk IT Service that uses historical data and patterns to create dynamic thresholds with a single click.

    The company is making available a 5.4 update to the Splunk Machine Learning Toolkit (MLTK) 5.4 and a Splunk App for Data Science and Deep Learning (DSDL) 5.1 toolkit that provides access to additional data science tools that can extend MLTK to enable organizations to build their own custom LLMs and AI assistants.

    Finally, Splunk added Unified Identity to make it simpler to access Splunk Cloud Platform and Splunk Observability Cloud along with an update to Splunk Cloud Platform and Splunk Enterprise that make it simpler to ingest, route, search and export data.

    It’s still early days as far as the application of generative AI is concerned, but it’s already clear that the way IT is managed is about to be transformed. Coupled with tools such as OpenTelemetry that make it less expensive to collect massive amounts of data, the opportunity to train LLMs that streamline a wide range of processes is immense. Those capabilities won’t replace the need for humans to manage those processes, but they will most certainly cause staff realignments as many manual tasks become increasingly automated.

    In fact, it’s hard to imagine an IT team that would not want to take advantage of AI capabilities to simplify the management of complex IT environments that now function at a level of scale that few IT professionals can successfully manage on their own. One way or another, AI is going to be broadly applied to IT workflows. The only thing left to be seen now is the ultimate impact.

  • Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk today launched a platform for ingesting data from sensors, industrial equipment and internet-of-things (IoT) platforms so that it can be analyzed alongside data collected from IT environments.

    Announced at the company’s .conf23 conference, the Splunk Edge Hub extends the reach of the troubleshooting platform Splunk provides that increasingly involves various types of edge computing platforms.

    Tom Casey, senior vice president for products and technology at Splunk, said Splunk Edge Hub is designed to be deployed in those edge computing environments and reduce the total amount of data that needs to be transferred back to an instance of the Spunk analytics platform running in a data center or in the cloud.

    That approach makes it possible to remotely monitor everything from environmental conditions to identifying anomalies indicative of an outage that might be prevented. The overall goal is to unify visibility across IT and operational technology (OT) environments as these systems and applications become more integrated, said Casey.

    It’s not clear how quickly that integration is occurring, given the historic cultural divide that has existed between IT and OT teams. But with the rise of digital business transformation initiatives, the data collected from edge computing platforms is increasingly being incorporated into a wide range of applications deployed at the edge, in local data centers and in the cloud.

    In general, observability tools are being used to not only improve processes but identify and block suspicious activity. Of course, OT teams have been monitoring edge computing platforms for decades, but observability platforms make it feasible to interrogate logs, metrics and traces to hopefully discover issues before there is a disruption to services. The challenge, of course, is that not everyone on either the OT or IT team necessarily knows how to shape the queries required to discover the root cause of a potential issue. The Splunk approach essentially leverages the skillset of IT professionals that have mastered its platform to address that issue; something most OT professionals are not going to be able to do using their existing tools and platforms.

    One way or another, DevOps teams will soon need to be able to remotely diagnose edge computing issues as the number of workloads deployed on these platforms expands. IT teams are not going to be able to travel to the physical location of every edge computing platform every time an issue arises. In many ways, the rise of edge computing will force a transition to observability tools that will enable IT teams to more proactively manage IT environments rather than responding after a metric that OT teams are monitoring has already exceeded its threshold.

    In the event there is still an issue, observability platforms should also reduce mean-time-to-remediation (MTTR) as visibility into IT environments, including edge computing platforms, is improved.

    It’s not likely that OT and IT teams will ever be completely unified, but as observability platforms continue to evolve, there will be much greater opportunities for collaboration.

  • Communicating Common Web App Security Threats to Developers

    Communicating Common Web App Security Threats to Developers

    Automated security testing tools enable us to identify web application vulnerabilities early and often, but what happens after a vulnerability has been identified? Does your security team have the coding skills to mitigate it themselves, or are your developers suddenly security experts once a vulnerability is discovered? Most likely not. So, how do we go from finding vulnerabilities to fixing them? Enter a key component of shifting left: Collaboration between security and developer teams. And a portion of that involves providing developers with the context they need to prioritize and remediate threats appropriately.

    Useful context includes (but is not limited to):
    – The vulnerability type
    – How it works
    – What malicious actors can accomplish by exploiting the vulnerability
    – Ways to mitigate

    The list below provides context around five common web application security threats to help you collaborate on resolutions with your developers. A shared understanding of these threats and how to mitigate them early in the development life cycle will significantly improve overall security posture without impacting software delivery.

    SQL Injection

    A SQL injection attack is executed when an attacker injects malicious code into an application’s database through user-controlled data. While these types of attacks can accomplish many different things, there are several common outcomes. SQL injection attacks can enable attackers to gain unauthorized access to sensitive data stored in the database, and largely depending on what data is stored in a particular database, can result in access to authentication information, financial information and personal data. The second key outcome is the manipulation or removal of data. Malicious actors can then leverage this outcome to access the larger infrastructure and find even more sensitive information.

    To help protect against SQL injection attacks, organizations should never implicitly trust and always validate user input and utilize input encoding, prepared statements, parameterized queries or stored procedures instead of dynamic SQL statements whenever possible. By combining frontend and backend standards to prevent SQL injection from happening, your application can increase its security against this type of threat.

    Cross-Site Scripting (XSS)

    Another common web application attack is cross-site scripting (XSS) which involves inserting malicious code or script into a website. The website will then execute on the given script, enabling attackers to steal sensitive user data, such as session tokens and cookies.

    There are three main types of XSS attacks we regularly encounter: Reflective, stored and DOM. Reflective XSS attacks insert malicious code into a website that is immediately executed, whereas a stored XSS attack involves injecting malicious code into a website that is stored and executed later. DOM XSS is an attack pattern that is used more in single-page applications but acts similarly to reflective XSS. If successful, a cross-site scripting attack can lead to the theft of user session IDs and/or website defacement and lead to redirection to malicious sites, thus enabling phishing attacks.

    Similar to SQL injection attacks, to protect against cross-site scripting, organizations must never implicitly trust and always validate user input and use output encoding techniques while also using auto-sanitization libraries such as OWASP AntiSamy and implementing a content security policy.

    Cross-Site Request Forgery (CSRF)

    Cross-site request forgery (CSRF|XSRF) attacks trick users into performing an action on a website without their knowledge or consent. This is often achieved by inserting a malicious link or form into a website where a user is already authenticated. When the user clicks the link or submits the form, the action is performed on their behalf, leading to potential data loss or unauthorized access.

    Mitigating these types of attacks requires leveraging CSRF protections which are built into the framework you are using, if applicable. Using CSRF tokens, which are unique, randomized values associated with a user’s session and can verify the authenticity of a request will also help migrate an attack. In addition, SameSite cookie settings can help prevent attackers from being able to send requests on behalf of a victim.

    Insecure Direct Object References (IDOR)

    Insecure direct object references (IDOR) occur when an application exposes direct object references, like URLs or database keys, which allow attackers to gain access to restricted data by manipulating these references.

    Safeguarding against IDOR requires the implementation of proper access controls and session management, ensuring that only authorized users have access to certain resources or data. Also, avoid using predictable references and instead utilize globally unique identifiers (GUIDs) to prevent attackers from guessing the direct object references they need to access restricted data.

    It is important to remember that IDOR-based vulnerabilities don’t occur singularly and are coupled with other vulnerabilities to become an effective attack vector.

    Remote Code Execution (RCE)

    Remote code execution (RCE) gives an attacker the ability to execute arbitrary code on a server, which can lead to the compromise of entire systems and offer unauthorized access to highly sensitive data. RCE attacks can occur through an array of means, including exploiting vulnerabilities in code libraries or injecting malicious code through user input fields. As illustrated by the critical zero-day exploit discovered in the Java logging library Log4j in December 2021, RCE can be a determinantal vulnerability.

    A successful RCE attack can cause denial-of-service (DoS) attacks, expose sensitive data, lead to illicit cryptocurrency mining and the execution of malware. In more severe instances, a successful RCE attack can allow an attacker to gain full control over the compromised machine.

    The good news is organizations can implement the same tactics used for protection against SQL Injection and XSS—never implicitly trust user data and adhere to strong user input sanitization and validation.

    Understanding Common Threats

    Safeguarding applications and ensuring a sound security posture requires both security and developer teams to have a shared understanding of common threats and the associated risks.

    The details provided in these examples only scratch the surface in terms of useful context for developers. When you can pinpoint when a vulnerability was introduced, which repository branch and code commit it’s associated with and whether it is exploitable from the outside, you create a powerful feedback loop that accelerates fixes.

  • Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

    Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: SUSE announces a Red Hat Enterprise Linux fork after Oracle said a similar thing, and Sarah Silverman says OpenAI and Meta have stolen her words. (more…)