devopsy.kinsta.cloud

Category: IT as Code

  • Cycode Brings Generative AI to App Security Posture Management

    Cycode Brings Generative AI to App Security Posture Management

    Cycode today added generative artificial intelligence (AI) capabilities to its application security posture management (ASPM) platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments.

    At the same time, Cycode is adding plugins for VS Code and JetBrains integrated development environments, a command line interface and pull request scanners to make it easier to identify security issues as early as possible during the software development life cycle (SDLC). Cycode also revealed today it now has more than 75 connectors to various security tools commonly used within DevSecOps workflows.

    Amir Kazemi, director of product marketing for Cycode, said the company is using OpenAI’s generative AI platform to provide a natural language interface for invoking the Risk Intelligence Graph that is at the core of the Cycode ASPM platform. As part of that effort, Cycode is now also 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 platform, as a result, can now provide automated risk scoring for vulnerabilities based on actual severity and potential impact to the business, said Kazemi. The overall goal is to make it simpler to secure software supply chains by facilitating the proactive collaboration between application developers, DevOps engineers and cybersecurity professionals, he added.

    It’s not clear what impact generative AI is going to have on how DevSecOps workflows are constructed, but making it easier to identify the root cause of security issues in application environments made up of monolithic applications, microservices and event-driven frameworks is now essential. Application security has simply become too chaotic to effectively manage without help from AI, noted Kazemi. In its current state, application security is simply unmanageable, he added.

    The challenge is that just because a zero-day vulnerability has been discovered, it doesn’t always follow that application development teams know where every instance of it exists within their application environment. It’s not uncommon for DevSecOps teams to discover outdated versions of components that have known vulnerabilities to be running months after a patch in an updated version of that component has been made available.

    DevSecOps teams are, of course, always trying to strike a balance between the level of threat a vulnerability represents and the possibility that the patch that should be applied might break an application. However, given the risk to application environments, it’s becoming less risky to patch an application than it is to hope that cybercriminals don’t exploit a known vulnerability.

    While much DevSecOps progress has been made in recent years, it’s clear there is still much work to be done. Hopefully, generative AI will make it simpler for application development teams to address issues more rapidly than ever. In the meantime, however, DevSecOps teams should assume cybercriminals are looking to exploit the same AI capabilities to discover vulnerabilities they can exploit faster than ever.

  • What the Evolution of Specialized Hardware for AI and ML Means for DevOps

    What the Evolution of Specialized Hardware for AI and ML Means for DevOps

    The widespread adoption of artificial intelligence (AI) and machine learning (ML) technologies is accelerating the evolution of computational hardware, essential for automating complex processes and enhancing accuracy in decision-making. This acceleration is crucial in advancing computer science and data processing, especially within the various segments of AI/ML data pipelines.

    This growing demand is prompting a diverse array of chip manufacturers, from established players to emerging contenders, to innovate and lead in the development of faster and more efficient processing solutions. The primary goal? To design chips that optimize data transfer, improve memory management and enhance power efficiency. These advancements are far from incremental; they are pivotal in meeting the escalating demands of sophisticated AI and ML applications.

    This evolving hardware landscape for DevOps necessitates greater unification and automation of the various applications to the specialized AI infrastructure. With chip architectures diversifying, building the application stacks focusing on portability, performance and ease of access becomes even more crucial. The ability to seamlessly embrace multiple architectures will be key to striking the right balance for the varying technical abilities of the people who want to interact with technology.

    This article explores the implications of these hardware advancements on DevOps processes within AI and ML. Additionally, we explore strategies DevOps teams may consider to ensure applications remain efficient and portable across various chip architectures.

    The Rise of Specialized Hardware

    Historically, general-purpose hardware, including GPUs and CPUs, was the staple for many workloads. However, a clear pivot to specialized hardware is underway in artificial intelligence and machine learning, where training and inferencing demands have grown exponentially. These applications often hit performance limitations inherent in traditional hardware, partly due to the modern constraints of Moore’s Law. As a result, there is an increasing need for hardware capable of handling specific AI tasks with increased efficiency and speed. For instance, in certain machine learning scenarios, using hardware that supports single-precision floating-point computations can speed up processes without the need for the accuracy provided by double-precision computations.

    Although NVIDIA remains a dominant force in the AI chip market, the competition is heating up, with various companies offering innovative alternatives. And it’s not only from the usual suspects like Intel or AMD; Google has made strides with its Tensor Processing Units (TPUs). Amazon recently announced Trainium2, a new AI chip designed specifically for training AI systems. This chip, set to compete with Microsoft’s Maia and Google’s TPUs, underscores the growing custom AI chip development trend among major tech companies. Beyond these giants, startups such as Cerebras, SambaNova Systems, Graphcore and Tenstorrent bring fresh takes on AI hardware solutions.

    Challenges for DevOps

    As specialized hardware becomes more prevalent, the DevOps community will need to manage various new challenges, including performance portability. Performance portability refers to ensuring that applications run efficiently and perform well across varying computing architectures with minimal to no modifications.

    Cognitive computing (the broader category of AI and ML) varies in complexity, depending on the algorithms, models and creators’ unique demands for hardware-specific features. While an architecture-tailored version will certainly maximize performance on respective platforms, it complicates the process of ensuring a consistent software experience across diverse hardware.

    The challenge of system design lies in optimizing the environment for maximum efficiency, especially when the precise nature of the workload is unknown to those responsible for designing and supporting the systems.

    Of course, there are also significant and related considerations with continuous integration and continuous deployment (CI/CD) pipelines. The intricacies of CI/CD pipelines are magnified when pursuing performance portability. The need to validate software performance across multiple hardware configurations introduces a more elaborate testing matrix and can extend deployment cycles, directly affecting time-to-market requirements. Suddenly, workloads are now crossing the traditional IT infrastructure and high performance/supercomputing boundaries once defined by microservice and batch processing technologies; they are now one in a CI/CD pipeline.

    As organizations adopt specialized hardware, there’s the potential for a parallel rise in specialists focusing solely on one type of hardware or application use case. While such expertise can drive innovation and optimization for a particular platform, it also creates complexity and the potential for knowledge silos and unnecessary complexities for the operations teams and clients that use those systems.

    Leveling up Performance Portability

    Performance portability and closely related concepts, such as hardware-agnostic performance and cross-platform efficiency, are increasingly important for DevOps teams. As the technological landscape shifts, the pressing question becomes: How can the industry and DevOps teams navigate this evolution seamlessly?

    Ongoing research and development will no doubt play a key role. For example, the U.S. Department of Energy (DoE) is exploring new methodologies to support its Exascale Computing Project. This includes refining existing software libraries, pioneering new programming models and developing new tools that could eventually influence wider DevOps practices. Other researchers are developing software abstraction layers, aiming to simplify the adaptation of generic code for specific hardware configurations.

    Beyond new tools and methodologies that may come from current R&D efforts, there are many existing tools and processes that lend themselves to improving performance portability, including:

    • Containerization: Containers encapsulate applications and their dependencies in a way that helps ensure they run consistently across various environments. Open source tools like SingularityCE with Open Container Initiative (OCI) compatibility can help standardize and simplify deployment across different hardware configurations, promoting performance portability for high-performance computing and traditional IT infrastructure management.
    • Benchmarking and profiling: To achieve performance portability, it’s imperative to understand how software behaves across different architectures. Benchmarking tools provide quantitative performance measures, while profiling tools offer insights into software behavior, helping developers identify bottlenecks and areas that need optimization.
    • Code Portability Libraries: In addition to libraries like OpenCL that enable software execution across diverse hardware, recent advancements in container technologies complement this capability. For example, enhancements in container device interfaces, such as those in SingularityCE, streamline the integration of hardware-specific resources. This development aids DevOps teams in optimizing software for various hardware without extensive codebase rewrites, exemplifying the tools supporting hardware diversity and software agility in all aspects of cognitive computing.

    Of course, on top of all these tools and strategies, agile methodologies will remain essential since they prioritize iterative development, continuous feedback/improvement, and adaptability—all of which are important to fast-evolving hardware and software configurations.

    Looking Ahead: Adaptability as the Key

    As we embrace the new frontiers in AI and ML, the role of DevOps teams in navigating a constantly evolving hardware landscape becomes increasingly vital. At the heart of this journey lies the formidable challenge of application portability—a challenge that calls for technical expertise and a strategic shift toward adaptability. Enter containers emerging as indispensable tools that ensure a consistent application experience and performance across diverse platforms and handle the intricacies of portability.

    Likewise, adopting agile methodologies transcends process adherence; it embodies a mindset of flexibility and responsiveness, essential in rapid technological shifts. These approaches, far from temporary fixes, are integral to a strategy that aims to unleash the potential of AI. As DevOps teams continue to navigate these challenges, their success will depend on their adaptability and willingness to explore and integrate established and emerging technologies—particularly those excelling in scalability and efficiency. This proactive exploration and integration will be the key to surviving and thriving in this dynamic technological landscape. And yet, while we have discussed this problem regarding scientific applications, the impact is also felt on the AIOps side of the house, using AI-specific hardware with AIOps practices. While our goal here was to discuss the complexities of creating and administering systems for artificial intelligence and machine learning, we have yet to approach the security conversation, particularly with confidential computing, which is a topic for another time. Happy computing.

  • ReversingLabs Applies AI to Better Secure Application Binaries

    ReversingLabs Applies AI to Better Secure Application Binaries

    ReversingLabs this week launched a binary analysis tool that uses machine learning algorithms to identify risks before and after applications are deployed.

    Erik Thoen, vice president of product management for ReversingLabs, said Spectra Assure makes use of the same core artificial intelligence (AI) technologies the company uses to discover malware within binaries to analyze the entire software package, including first-, second- and third-party components, to identify potential threats.

    Thanks to the use of AI, Spectra Assure is able to scan applications that are gigabytes in size in minutes or hours, depending on their complexity, noted Thoen.

    That approach is critical because attacks launched against applications are more often aimed at binaries that are deployed in production applications rather than the source code used to create them, he added.

    In addition, Spectra Assure can be applied to both open source and proprietary software, said Thoen. In contrast, many legacy scanning tools are designed to only surface potential issues in open source software, he noted.

    Spectra Assure is designed to be used by both producers of software and the organizations that deploy software, said Thoen. Organizations that develop software need to be able to identify any security potential issues that may have arisen during the build process, while organizations that consume software need to be assured that there are no issues that will later compromise their IT environments, said Thoen.

    ReversingLabs is attempting to fill a gap that exists in many software supply chains between when a software build is completed and deployed, said Thoen. While developers may scan source code for vulnerabilities, it’s not uncommon for changes to be made during the build process that inadvertently create vulnerabilities, said Thoen.

    It’s still not clear which teams within organizations are assuming responsibility for the software supply chain. In many cases, DevSecOps teams are securing the software supply chain, but in other instances, cybersecurity teams have been tasked to lock them down. Among organizations that consume software, responsibility for application security might be assumed by either the cybersecurity teams or a procurement office responsible for purchasing software.

    Regardless of how software supply chain security is managed, the number of attacks against them has risen sharply. A recent ReversingLabs report found there has been a 1,300% Increase in malicious packages found in open source software platforms since 2020.

    Ultimately, it’s only a matter of time before more stringent regulations force the software supply chain security issue. A recent executive order issued by the Biden administration requiring federal agencies to secure software supply chains is a harbinger of stricter controls that enterprise IT organizations must implement. DevSecOps teams, in the meantime, have an opportunity to revisit the workflows that were created in an era where developers tended to overly trust the integrity of software components downloaded from open repositories.

    Of course, it may require a catastrophic event to truly galvanize organizations into action, but one way or another, application security is going to improve. The only issue remaining to determine is how expensive a proposition that will be given the potential fines that are likely to be one day levied.

  • ngrok Previews API Gateway Service to Streamline App Networking

    ngrok Previews API Gateway Service to Streamline App Networking

    Under an early access program, ngrok today made available an application programming interface (API) gateway that can be consumed as a service.

    Rather than having to deploy, maintain, and secure API gateways themselves, application development teams, via a single command or function call, can now invoke a service through which they can route API traffic, authenticate and authorize access, and apply rate-limiting policies using an ngrok policy engine.

    ngrok CEO Alan Shreve said this approach also makes it simpler for IT teams to unify ingress management at a time when application networking is becoming more challenging to manage. That approach also reduces friction because instead of being dependent on an IT operations team, it gives developers more direct control over APIs, he added. Today, most access to APIs is granted after developer first create a ticket request in an IT services management (ITSM) platform, noted Shreve.

    In addition, the ngrok gateway also streamlines access to APIs spanning multiple clouds and on-premises IT environments in a way that enables organizations to implement a multi-cloud computing strategy, he added. Today, many organizations are locked into a single platform because they are dependent on the API gateway services provided by their cloud service provider, noted Shreve.

    Finally, organizations will only need to pay for the API gateway service based on actual usage versus incurring the cost of acquiring a gateway upfront, said Shreve.

    Previously, ngrok has been making available software development kits (SDKs) to provide programmable access to its API gateway. The as-a-service option being offered now is the next logical extension of that effort, noted Shreve.

    In general, more infrastructure than ever is being consumed as a service, so making available an API gateway service is only the latest example of that larger trend, he added.

    Each organization, based on total cost, will naturally need to decide when it makes the most economic sense to consume IT infrastructure as a service; however, as application networking continues to become more challenging to manage at a time when the number of IT professionals with that expertise remains limited. Relying on a service provides a viable alternative for managing what are often hundreds of APIs spanning a distributed computing environment.

    It’s not clear yet precisely which teams within an IT organization are assuming responsibility for application networking, but as layer 4 through layer 7 of the networking stack become more programmable, more responsibility for networking can be assumed by DevOps and platform engineering teams. Existing networking teams, meanwhile, continue to manage the physical networking underlays used to route network traffic. Regardless of how application networking evolves, the rigidity that has characterized the delivery of network services is starting to fade away in a way that makes it possible to dynamically invoke networking services as needed.

    IT teams must decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications. The goal, however, should be to eliminate as much friction as possible at a time when applications have become more dependent on networking services than ever.

  • Veracode Report Shines Spotlight on Massive Application Security Debt

    Veracode Report Shines Spotlight on Massive Application Security Debt

    An analysis of more than a million applications published today by Veracode, a provider of a software supply chain security platform, found 42% of applications contained flaws that remained unfixed for longer than a year.

    Based on 1,553,022 dynamic analysis scans and 11,429,365 static analysis scans, the report noted that those applications with that level of security debt were found in 71% of the organizations maintaining these applications. Nealy half of organizations (46%) have persistent, high-severity flaws that constitute ‘critical’ security debt. Approximately 63% of applications have flaws in first-party code, while 70% contain flaws in third-party code imported via third-party libraries.

    Remediation rates also vary by flaw type. Fixing third-party flaws takes 50% longer, with half the known flaws fixed after 11 months, compared to seven months for first-party flaws.

    Collectively, the scan run by Veracode produced 96 million raw static findings, four million raw dynamic findings and 12.2 million raw software composition analysis findings.

    Chris Eng, chief research officer for Veracode, said it’s clear too many organizations are kicking application security flaws down the road only to find they don’t have the time to address them properly. Meanwhile, cybercriminal syndicates and nation-states are becoming more adept at exploiting these flaws with each passing day, he added.

    In general, there is a lot more focus on software supply chain security in the wake of an executive order issued by the Biden administration that requires federal agencies to identify and remediate security flaws. However, the pace at which enterprise IT organizations are following the lead of the Federal government varies widely. Only a relatively small percentage of the vulnerabilities that exist in applications running in production environments are being exploited, so many enterprise IT teams have yet to prioritize the issue.

    However, as more cybercriminals acquire the skills required to discover and exploit those vulnerabilities, it’s only a matter of time before a major application security crisis ensues, noted Eng.

    Theoretically, at least, artificial intelligence (AI) should one day soon make it easier to discover and remediate vulnerabilities, but it’s just as likely cybercriminals will use the same capabilities to achieve their own nefarious ends. In fact, it’s largely a race against time before existing application flaws are exploited using AI-based tools and techniques. Application development teams that fix flaws the fastest reduce critical security debt by 75%, from 22% of applications to just over 5%, the Veracode report noted.

    Naturally, it’s less costly and simpler to fix security flaws before applications are deployed in a production environment, so the more organizations embrace DevSecOps best practices on the front end, the lower the overall security debt becomes, noted Eng.

    It’s not clear whether organizations might decide to replace or consolidate applications to reduce their security debt, but given the overall lack of cybersecurity expertise among application developers, the current level of security debt is likely to continue to rise. The challenge, of course, is that as the security debt rises, the number of developers available to address, unfortunately, remains comparatively constant.

  • Squaring the Circle: How to Make Public APIs Private

    Squaring the Circle: How to Make Public APIs Private

    APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

    APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

    Day 2 API Security Solutions and Snowflakes

    This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

    Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

    A Difficult Race to Win

    Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

    The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

    Why Not Avoid the Race?

    So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

    Zero-Trust API Networking Needs to be Built for APIs

    To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

    Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

    There are usually three reactions to the diagram above:

    1. OK, tell me how it works. See below.
    2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
    3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.

    How Zero-Trust API Networking Works

    Here are the four pillars of zero-trust API networking:

    1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
    2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code: 
    3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
    4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.

    The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:

    • Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
    • Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
    • Extensibility. Software-only, cloud-native architectures. Preferably open source based.
    • Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
    • Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
    • Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
    • Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.

    Zero-Trust API Networking

    While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

    Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.

  • Legit Security Adds Sensors to Detect Usage of Gen AI Tools to Write Code

    Legit Security Adds Sensors to Detect Usage of Gen AI Tools to Write Code

    Legit Security today announced it has added the ability to detect when developers use generative artificial intelligence (AI) tools to write code to its application security posture management (ASPM) platform.

    The ASPM platform developed by Legit Security already has discovery capabilities for application secrets, for example, enabled by sensors that are now being extended to include generative AI tools.

    Legit Security CTO Liav Caspi said the overall goal is to allow DevSecOps teams to identify who uses these tools to write which types of code. Each DevSecOps team can then decide how stringently to enforce policies to either ban or limit usage of those tools, he added.

    There is no doubt that generative AI tools are increasing developer productivity, but the large language models (LLMs) that provide the ability to generate code were trained using examples of code of varying quality collected from across the web. Much of that code either contains known vulnerabilities or is simply inefficient, which can manifest itself in the output surfaced by a generative AI platform.

    The Legit Security ASPM platform, in addition to identifying generative AI tools being used in real-time, can also be employed to scan the LLM itself to identify security risks such as prompt injection and insecure output handling. Unfortunately, most cybersecurity teams are unaware of the extent to which application code generated by a machine might be insecure, so it currently falls to leaders of DevSecOps teams to determine what is an acceptable use of these tools. It may be perfectly fine to rely on a generative AI tool to create a script that will be used for an internal-facing application. However, using the same tool to write business logic that will be exposed to the internet may not be especially prudent.

    It’s not clear how much of the code finding its way into software builds is being generated by a machine versus a human. In the longer term, the goal is to be able to identify that code by, for example, detecting substantial changes in the way code is normally written by a human developer, said Caspi.

    Of course, while an ASPM may detect usage of generative AI tools that are connected to a corporate environment, there are still plenty of opportunities for developers to use these tools offline to create code that can later be added to a build using a code check-in tool. After all, many developers have used various shadow IT tools to write code for decades. Regardless of who or what wrote that code, however, it should still be reviewed.

    In the meantime, the overall size of the codebase that DevSecOps teams will need to manage and secure will only exponentially increase as developers become more productive. Hopefully, more AI capabilities will soon be embedded into DevOps platforms to further automate the management of software builds at a time when many DevOps teams were already finding themselves overwhelmed even prior to the rise of generative AI.

  • Akamai Launches Gecko Edge Computing Services

    Akamai Launches Gecko Edge Computing Services

    Akamai Technologies today launched an initiative that promises to make it simpler to centrally manage and deploy application workloads on edge computing platforms.

    Shawn Michels, vice president for product management for cloud computing Akamai, said a Generalized Edge Compute (Gecko) offering leverages the global points of presence (PoPs) that Akamai uses for its content delivery network (CDN) to now deploy application workload managed via the Linode cloud service the company acquired in 2022.

    At the core of this offering is a set of virtual machines that enable a full stack of application software to be deployed in an edge computing environment to eliminate latency that would otherwise be encountered when transferring data to a cloud computing environment. The ultimate goal is to provide IT organizations with a federated set of services they can employ to process data where it makes the most sense based on performance requirements, said Michels.

    For example, applications infused with artificial intelligence (AI) will need to be able to invoke enough compute resources to run inference engines at the edge, while other less compute-intensive application workloads are best deployed in cloud computing environments, he noted.

    Michels added that rather than locking IT teams into a specific architecture, Akamai is committing to meeting IT organizations where they are, including adding support for containers running on Kubernetes clusters in its PoPs later this year.

    Akamai has more than 4,100 points of presence around the globe. With the acquisition of Linode, Akamai added a set of cloud computing services to compete directly against hyperscalers such as Amazon Web Services (AWS), Microsoft and Google by making cloud services available at a lower cost at a time when more organizations than ever are concerned about the total cost of IT.

    In its first phase of Gecko, Akamai will provide access to virtual machines in 100 locations by the end of the year. Akamai has already deployed Gecko servers in Hong Kong SAR; Kuala Lumpur, Malaysia; Querétaro, Mexico; and Johannesburg, South Africa, as well as in cities without a concentrated hyperscaler presence, including Bogotá, Colombia; Denver, Colorado; Houston, Texas; Hamburg, Germany; and Marseille, France. Deployment of a tenth Gecko region this quarter is planned for Santiago, Chile. Akamai is committing to adding hundreds of cities to its global cloud computing footprint over the next several years.

    In the longer term, Akamai also plans to add automated workload orchestration to make it easier for developers to build applications across hundreds of distributed locations.

    More workloads than ever are being deployed at the network edge as IT teams look to deploy software closer to the point where data is being created and consumed. That will require extending the reach of existing DevOps workflows to edge computing environments that will be based on everything from x86 and Arm processors to graphical processor units (GPUs).

    The challenge, as always, will be finding a way to effectively manage those workloads when the IT teams responsible for them are often physically located thousands of miles away.

  • Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    A survey published today finds 91% of respondents work for organizations that have experienced a software supply chain incident in the past 12 months.

    The survey polled 368 IT, cybersecurity and application developer professionals responsible for application security in North America and was conducted by the research firm Enterprise Strategy Group (ESG) on behalf of Data Theorem, a provider of an application security platform. The survey found zero-day exploits of vulnerabilities within third-party code (41%) were the most common attack vector, followed closely by misconfigured cloud services (40%), vulnerabilities in open-source software and container images (40%), stolen secrets/token/passwords (37%) and breaches of application programming interfaces (APIs) (35%).

    The biggest areas of impact of those breaches are identified as cryptojacking (43%), inability to meet service level agreements (41%), malware infestation (39%), unauthorized access (39%), stolen developer credentials (37%), data loss (37%) and the levying of fines (37%).

    Despite these issues, however, nearly three-quarters (74%) of respondents claimed their organization has “robust” software supply chain security capabilities even though a similar percentage said they are making significant investments in software supply chain security, with an additional 25% making moderate investments. More than three-quarters (77%) said they have increased their effort to secure third-party software components and container images in the wake of an attack. The top two areas of focus are new detection rules/analytics (33%) and the adoption of multifactor authentication (MFA) (33%).

    Top investment priorities over the next 12 to 18 months include scanning open source code components and third-party libraries for vulnerabilities (44%), followed by discovering and inspecting APIs in source code (39%), using composition analysis tools to create software bill of materials (SBOMs) (38%) and applying runtime API security controls (33%).

    The most widely used tools today are automated open source package risk management (34%), static application security testing (SAST) tools (34%), vulnerability scanning of cloud services (32%), automated security as code policy enforcement (31%) and dynamic application security testing (DAST) tools (31%).

    Data Theorem COO Doug Dooley said while the survey makes it clear progress is being made, there is still a lack of urgency. It may require additional high-profile breaches to create a large enough public outcry to pass the legislation that is going to be required to address software supply chain security issues more vigorously. In fact, 83% of respondents noted industry regulations are a key driver to ensure they create accurate SBOMs.

    In general, the survey finds nearly two-thirds of respondents (65%) have more than 50 Git repositories, with 40% reporting that more than half of their code is composed of third-party software. Half of respondents (50%) said they expected that to rise to more than half in the next 12 months. Well over half (58%) noted more than 30% of their code would be of open source software.

    Only 43% report they are completely confident that their developers are only using secure open source software. On the plus side, 90% are prioritizing efforts to shift security left to developers.

    Overall, 86% said it’s critical or important to know the composition/inventory of application code in use, where code is stored, and who has access to code components connected to their code. A total of 88% also noted it’s critical or important to have accurate inventory of their third-party APIs and cloud services.

    The one thing that is certain in the months ahead is that cybercriminals will put software supply chain security to the test. The challenge and the opportunity now, regardless of what regulations are ultimately passed, is to thwart those attacks before the damage inflicted ultimately forces lawmakers to act in ways that make software development a lot more difficult than it already is.