devopsy.kinsta.cloud

Author: Mike Vizard

  • 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.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Hanwha Vision America
    Santa Clara, California
    Senior DevOps Engineer
    $160,000 to $200,000

    Indeed.com

    Tecton
    Remote
    DevOps Engineer
    $156,000 to $231,000

    CareerBuilder.com

    The Pokémon Company International
    Redmond, Washington
    Senior Technical Program Manager – DevOps
    $151,000 to $189,000

    SimplyHired.com

    JP Morgan Chase
    Jersey City, New Jersey
    Lead Software Engineer – FinOps/DevOps
    $147,200 to $215,000

    Dice.com

    XTIVIA
    Remote
    Senior DevOps Engineer
    $120,000 to $140,000

  • GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian this week revealed it has allied with CyberArk to streamline secrets detection and management by making it easier to share insights.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the two companies have integrated their respective platforms using open source software that integrates GitGuardian Secrets Detection and CyberArk Conjur Cloud, a software-as-a-service (SaaS) platform for managing and rotating secrets as needed.

    In addition, CyberArk Conjur Cloud is now integrated with HasMySecretLeaked, a tool for discovering if a specific secret has been exposed on GitHub. That capability enables DevSecOps teams to periodically cross-reference secrets and credentials against a private database of secrets known to have been publicly exposed.

    GitGuardian claims to have uncovered more than 20 million publicly exposed secrets on the GitHub repository. While GitGuardian provides tools to discover exposed secrets, organizations rely on the CyberArk platform to manage secrets and remediate issues that arise when they are left exposed.

    The immediate challenge is to find ways to integrate secrets detection within the context of larger ecosystems, said Ghalleb. In the longer term, GitGuardian is working toward embedding its tool into integrated development environments (IDEs) to surface exposed secrets as developers build software, said Ghalleb.

    Naturally, there is a lot more focus on secret detection, and secrets management is getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. For many organizations, however, it’s still early days as far as adopting DevSecOps best practices to secure those software supply chains, but it’s clear more responsibility for application security is shifting left toward developers and the DevOps teams that support them.

    Unfortunately, too many developers still hard-code secrets in plain text into applications to create shortcuts as software is developed. Many forget to remove those secrets before an application is deployed in a production environment. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all.

    In the meantime, cybercriminals are becoming more adept at using scanning tools to discover secrets and then exploiting them to compromise applications after they have been deployed.

    Hopefully, DevOps teams will implement DevSecOps best practices to address those issues before any fines are levied. But the challenge, as always, is ensuring application security without adversely impacting the rate at which software is currently being built.

    It’s only a matter of time before more stringent regulations require organizations to revisit the security of software supply chains. Countries around the world are drafting legislation that would hold organizations much more accountable for the security of the applications they build and deploy. As more fines are eventually levied, the tolerance for leaving secrets exposed in applications is only going to decline.

    Secrets discovery and management is, of course, only one aspect of application security, but the more these issues are addressed before applications are deployed the less stressful cybersecurity becomes.

  • Cisco Extends Scope and Reach of Observability Platform

    Cisco Extends Scope and Reach of Observability Platform

    Cisco this week expanded the scope of its observability platform by adding predictive and generative artificial intelligence (AI) capabilities along with log analytics and a Core Web Vitals tool to make it simple to ensure web pages don’t lose their search engine ranking because of poor user experience.

    In addition, Cisco is now leveraging extended Berkeley Packet Filters (eBPF) in the kernel of Linux operating systems to provide visibility into Kubernetes workloads and a session replay capability for cloud-native applications. In addition, Cisco has allied with Komodor, a provider of a Kubernetes management platform, to gain additional visibility into these environments.

    Cisco also added digital experience monitoring (DEM) capabilities based on real user monitoring (RUM) and the full-stack observability it provides following its recent acquisition of Accedian, a provider of an analytics platform for monitoring end-user experiences.

    Finally, Cisco added a Data Security Posture Management (DSPM) Observability module to the company’s Business Risk Observability platform based on the same core platform.

    Announced at a Cisco Live EMEA event, these latest updates are part of an ongoing Cisco effort to extend the reach of its observability platform well beyond DevOps workflows.

    Gregg Ostrowski, executive CTO for Cisco AppDynamics, said as part of that effort, Cisco is making it simpler to aggregate telemetry data for the AI for IT operations (AIOps) capabilities it provides by pulling directly from platforms such as Cisco ThousandEyes and Cisco DNA Center as well as from third-party partners such as VMware, Zabbix and ServiceNow. Similarly, Cisco is now leveraging eBPF to collect data from Kubernetes environments.

    Ostrowski added that the overall goal is to reduce the amount of instrumentation effort that IT teams would have to undertake to instrument highly distributed IT environments.

    There will still be a need to instrument applications, but the collection of telemetry data from the underlying IT infrastructure environment is going to be increasingly automated, he noted. In the meantime, it’s become less expensive to instrument applications using open source OpenTelemetry agent software, added Ostrowski.

    In general, Cisco, in addition to enabling organizations to rationalize existing tools, is also making a case for improving collaboration by, for example, making use of natural language capabilities enabled by generative AI to launch queries and provide summarizations.

    At the same time, Cisco is partnering to add additional capabilities, such as the ability to monitor machine learning algorithms via an alliance with Aporia and AS/400 systems via an alliance with Perform IT.

    Ultimately, Cisco is betting that observability across the entire enterprise IT environment is going to become more unified as organizations increasingly look to correlate business processes with specific IT events, including indications of cybersecurity breaches. It’s not clear how far down that path enterprise IT organizations are just yet, but given the total cost of observing and monitoring IT environments today, there is more pressure than ever to find more cost-effective approaches to holistically managing IT. The challenge, as always, is unifying all the existing fiefdoms in IT organizations that have already embraced a wide variety of tools and platforms they are hesitant to give up.

  • F5 Looks to Streamline Application Networking

    F5 Looks to Streamline Application Networking

    At its AppWorld 2024 conference this week, F5 announced a software-as-a-service (SaaS) edition of its NGINX application networking portfolio, which are now all available under a single enterprise license.

    Shawn Wormke, general manager for NGINX, said NGINX One will eliminate much of the friction enterprise IT teams currently encounter when implementing NGINX Plus, NGINX Open Source, NGINX Unit, NGINX Gateway Fabric and the Kubernetes Ingress Controller the company provides.

    As part of that effort, F5 is also now making available a unified console across its application networking portfolio that promises to streamline the management of the F5 application networking portfolio.

    Currently available under an early access program, NGINX One creates an as-a-service platform through which enterprise IT organizations can invoke and pay for these capabilities on an as-needed basis, said Wormke. The overall goal is to reduce the total cost of application networking by eliminating the need for IT teams to integrate the various elements of NGINX One on their own, he added.

    In general, application networking has become more complex with the rise of cloud-native applications based on microservices. By reducing the cognitive load required to network those applications, it becomes simpler to make network operations a more natural extension of DevOps workflows, noted Wormke.

    Most organizations have some level of experience with application networking using proxy servers, but as application environments have become more complex, the need for gateways and ingress controllers to provide these capabilities at scale has become more apparent. As a result, more IT organizations are starting to revisit how they are structured. There may always be a need for dedicated networking specialists to manage the physical network underlay, but as other networking services become more integrated with DevOps workflows, responsibility for some networking services is starting to shift further left toward DevOps teams that will either deploy these capabilities themselves or take advantage of a SaaS platform such as NGINX One. The overall goal is to be able to dynamically provision application networking services without having to wait for a network administrator to provision them.

    There are, of course, a lot of approaches to application networking that are now emerging. Regardless of how application networking evolves, however, the rigidity that has characterized the delivery of network services for decades should finally start to fade away. Today, outside of a cloud computing environment, it’s still common for IT teams to provision virtual machines or Kubernetes pods in hours only to wait days or even weeks for network connectivity to be provisioned. As IT environments become more hybrid and more workloads are pushed to the edge, there is a clear need for a more agile approach.

    Each organization will need to decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications at a time when IT environments have become much more complex to manage. The challenge, as always, is reducing as much friction as possible without unduly raising the total cost of IT to a point where it becomes unsustainable.

  • Kobiton Open Sources Test Script Generation Tool

    Kobiton Open Sources Test Script Generation Tool

    Kobiton today announced it is open sourcing a script generation tool for the Appium automation framework that automates the running of test scripts.

    The overall goal is to make the tool, which makes it simpler to create more testing scripts, more widely available and, ultimately, lead to higher-quality applications being deployed.

    Kobiton CTO Frank Moyer said the tool makes it possible to generate tests from a test case that has been captured in a Node.js format. Rather than having to hire hundreds of testers to create those scripts manually, it’s now possible to automate those tasks using an open source tool, he added.

    On average, Kobiton claims the tool it developed can write a 30-step script in 10 minutes, whereas a manual approach could take as long as four hours to construct a similar test.

    Once created, those test scripts can automatically be executed using the Appium framework. The output from that tool can also be used on other testing platforms, including Sauce Labs, BrowserStack and LambdaTest or integrated with low-code testing platforms from Perfecto and Tricentis.

    It’s no secret that the quality of any given application tends to vary widely, not just between organizations but also within them. Most of those issues can be traced back to a lack of testing that usually occurs because there isn’t enough time. As deadlines near, one of the first places organizations look to make up for delays is the time available for testing. The hope is that whatever issues arise will be addressed via the next update. Of course, when the update falls behind schedule, the testing process is again cut back.

    Ideally, application development projects would not be allowed to go forward without adequate testing, but given business pressures, they often do. The only way to limit the impact of application development delays is to reduce the time required to create and run tests. The more automated that process becomes, the less time there will be spent on manually running routine tests. In fact, hopefully, there might even be enough time to run more complex tests to uncover issues that might adversely impact the user experience in ways no one might have otherwise considered.

    One way or another, the quality of the applications being deployed needs to improve if for no other reason than end users have options. Most end users will never give a mobile application a second chance if the initial experience doesn’t meet expectations. At the same time, application security regulations are only going to become more stringent. The tolerance for known vulnerabilities discovered after an application has been deployed is falling. Many organizations will find themselves subject to fines being levied simply because there was not enough adequate testing baked into the software supply chain.

    In fact, application security should, in the final analysis, be an element of a large quality assurance process that begins with adequate testing.

  • Survey Surfaces Raft of Ongoing Agile Development Challenges

    Survey Surfaces Raft of Ongoing Agile Development Challenges

    A survey of 788 software development professionals finds 71% are using agile development methodologies within their software development life cycle (SDLC) but only 44% said it is working very well (11%) or somewhat well (33%) in the enterprise.

    Conducted by Digital.ai, the survey identifies end-to-end visibility and traceability from business initiative through deployment as the top opportunity for improvement (44%), followed by an ability to measure cycle time, wait time and bottlenecks (34%), continuous testing (29%) and identification and measurement of technological risk (28%).

    Nearly half (46%) identified too many systems as a primary reason Agile was not scaling, followed by siloed teams (37%), culture clash (34%), inconsistent adoption (30%) and the inability to measure business value (28%).

    Despite these issues, nearly two-thirds (63%) said they have visibility into their Agile pipeline, with 55% claiming they have complete visibility. However, only 36% said DevOps teams currently work together as one team to accelerate innovation and deployment of high-quality and more reliable software. At the same time, only two-thirds (66%) claimed at least 50% of their applications were delivered on time and “with quality.”

    Joyce Tompsett, general manager of the State of Agile project at Digital.ai, said the survey makes it clear many organizations are still trying to strike the right balance when it comes to developing software. For example, the survey finds the top two reasons organizations adopt Agile (tied at 41%) are to accelerate time to market and prioritize delivery and measure customer/business value. Most software development teams are being evaluated both based on velocity (33%) and the value delivered (29%), the survey finds.

    The survey also identifies customer satisfaction (43%), time to delivery (39%) and competitive advantage (34%) as their top priorities for 2024.

    In general, the survey finds that 33% of respondents reported business leaders and executives are actively leading and participating in company-wide agile transformation. However, more (41%) said there was not enough leadership participation. Well over a third (37%) said business teams simply don’t understand what Agile is or what it can do. More than a quarter (27%) said there is not enough training.

    Not surprisingly, the most widely adopted methodology is Scrum (63%) with the Scaled Agile Framework (SAFe) being the most widely used (26%). Another 22% don’t have a mandated framework, while 12% said they have created their own.

    The debate over what precisely constitutes agile development is, of course, ongoing. Each organization tends to adopt the elements of the framework that make the most sense for them, so the actual state of adoption from one organization to the next will vary widely. The one thing that is certain is the more complex the IT environment, the more challenging it can be to embrace agile development.

    And there continues to be lots of room for improvement. If only two-thirds of organizations are delivering half (50%) of their applications on time with an acceptable level of quality, it means there are more projects that are failing to meet that standard than many software development teams might care to admit.

    As more organizations become more dependent on software, however, tolerance for that level of failure will only continue to decline as businesses and leaders lose patience with application development practices that do not live up to expectations.