devopsy.kinsta.cloud

Author: Mike Vizard

  • Fast Code, Real Risks: Guardrails for AI-Generated Software

    Fast Code, Real Risks: Guardrails for AI-Generated Software

    Yonatan Arbel, developer advocate in the Office of the CTO at JFrog, dives into the potential risks and rewards of relying on artificial intelligence (AI) agents to build and deploy software.

    Yes, more code is shipping faster than ever, Arbel admits, but volume alone isn’t a win—each hastily synthesized line must still survive build servers, security scanners and production reality. “Not everything in life comes for free,” he reminds, framing AI acceleration as an IOU that must eventually be paid down with careful review.

    To drive the point home, Arbel shares a personal misadventure. While traveling, he used a “vibe-coding” platform to whip together a receipt-tracking app. The tool auto-generated an impressive login flow and slick UI, so he proudly shared the URL with friends—only to discover their receipts mixed with his the next morning. A quick code dive revealed an AI-written SQL query that fetched every user’s data instead of scoping to the current account, proving how easily privacy can be breached when humans skip the boring inspection step.

    From there, the conversation turns to guardrails. Developers are becoming “pilots with copilots,” Arbel notes, spending more time instructing chat windows than writing functions. That shift demands automated policy checks, dependency vetting and runtime governance so velocity doesn’t eclipse trustworthiness. DevOps teams must embed quality gates early and often, treating AI-generated packages and prompts just like any other third-party code subject to organizational rules.

    Arbel’s advice is pragmatic: Start small, review everything, and remember that speed without oversight is just a fast track to technical—and financial—pain. Used thoughtfully, AI can compress months of work into days, but only if teams stay vigilant, enforce context-aware policies and let security evolve in lockstep with the bots.

  • Spacelift Adds On-Premises Edition of Infrastructure Management Platform

    Spacelift Adds On-Premises Edition of Infrastructure Management Platform

    Spacelift has made available an on-premises edition of a platform for automating the provisioning and management of IT infrastructure that previously was only accessible via a software-as-a-service application.

    Company CEO Pawel Hytry said the on-premises edition of the platform satisfies both the requirements of highly regulated industries and the emergence of sovereign cloud requirements that stipulate data must remain within a specific geographic region.

    Regardless of whether this edition of Spacelift is deployed in a local data center or in a cloud service that ensures IT infrastructure is restricted to a single availability zone, the Spacelift observability platform can now be deployed in a way that satisfies any compliance requirement, he added.

    It’s not clear how many organizations that previously relied on a SaaS edition of the platform might be required to shift toward an on-premises edition because of sovereign cloud requirements that have risen in the wake of recent globe trade tensions. Organizations in Europe have now become especially sensitive to dependence on IT infrastructure that might reside in the U.S. out of fear that the U.S. government might impose additional restrictions in the form of, for example, a tariff on digital services.

    It’s also unclear how many providers of SaaS platforms might need to address similar sovereign cloud requirements, but it’s evident IT teams will soon have a lot more deployment options to consider.

    In the meantime, Spacelift is making a case for a platform that makes it easier to enforce best practices across the infrastructure-as-code tools that application developers routinely use to provision IT infrastructure. The challenge organizations are encountering is that much of that infrastructure is misconfigured in ways that enable cybercriminals to exploit vulnerabilities.

    Unfortunately, a recent Spacelift survey found that only 14% of respondents have fully implemented infrastructure automation best practices. The bulk of organizations, in fact, have simply created various islands of automation that they then attempt to manually integrate using multiple scripts, noted Hytry.

    Hopefully, with the rise of platform engineering, more of the management of infrastructure will become automated. A recent survey conducted by Futurum Research finds that adoption of platform engineering as a methodology for building and deploying applications at scale is gaining significant traction, with more than a quarter of respondents (26%) having mastered platform engineering, compared to 41% who are still working toward applying platform engineering across multiple projects. Another 24% are still working toward operationalizing a set of best practices for platform engineering, while 7% are just getting started.

    Roughly half of platform engineering teams provide cloud/multi-cloud management (52%) and dev/test/production environment support (48%). DevOps toolchains (43%), standard platform configurations (42%), and containers/Kubernetes (41%) support are also prevalent.

    Regardless of the approach to IT infrastructure automation, the need to unify the management of platforms has become a more pressing issue. Each platform an organization deploys tends to increase the total cost of IT simply because an additional team of IT professionals is usually required to manage it. Hopefully, as more artificial intelligence (AI) is applied to the management of IT infrastructure, the ability to scale those teams will significantly increase in the months and years ahead.

  • Secure Code Warrior Defines Security Rules for AI Coding

    Secure Code Warrior Defines Security Rules for AI Coding

    Secure Code Warrior has made available a set of security rules for application developers using artificial intelligence (AI) tools to generate code.

    Company CTO Matias Madou said the AI Security Rules made available on GitHub are intended to encourage developers to review code generated by AI for security issues that these tools may inadvertently introduce. Most AI tools were trained using samples of code that were randomly collected from across the web. As such, they can introduce vulnerabilities simply because they were trained using code that contains similar flaws, noted Madou.

    Additionally, the AI Security Rules encourage developers to establish guardrails that steer AI away from risky patterns and common security missteps, such as insecure authentication flows or failure to use parameterized queries.

    Previously, Secure Code Warrior has made available AI security training courses for application developers that Madou said will continue to be expanded.

    In general, AI coding tools have, from a cybersecurity perspective, plusses and minuses. AI coding tools are, for example, unlikely to introduce a SQL Injection vulnerability. In fact, there may come a day when this particular vulnerability is completely eliminated as AI coding tools become more widely used, noted Madou. However, AI coding tools also introduce other potential security concerns, including hallucinations.

    It’s not clear to what degree developers are relying on AI tools to generate code, but a recent Futurum Group survey finds that 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code.

    Additionally, The Futurum Group finds organizations are exploring multiple paths to employing artificial intelligence (AI) capabilities across the software development lifecycle (SDLC). Over the next 12 to 18 months organizations plan to increase spending on not only AI code generation (83%) and agentic AI technologies (76%), but also existing familiar tools that have been augmented with AI.

    In effect, there is now a battle underway between incumbent providers of tools and startup rivals for the hearts and minds of software engineers.

    Regardless of how code is written, an application developer remains accountable for its quality. The challenge is that over time there is often a tendency to trust the output of an AI coding tool too much. Inevitably, the code generated might not only contain vulnerabilities but might also be deeply flawed in ways that might prevent an application from running at all. Just as challenging, AI coding tools might not be of much help when updating existing application environments simply because they might not have enough context to generate code that will work, noted Madou.

    On the other hand, there are many developers that only have a rudimentary appreciation for security issues. AI coding tools in those instances can significantly improve the quality of the code that might otherwise have been created by an application developer.

    There is, of course, no going back. AI coding tools are here to stay. The real issue is putting the guardrails in place that minimize any security vulnerabilities or other types of flaws that might compromise the security of an application.

  • Chronosphere Streamlines Management of Log Data to Reduce Costs

    Chronosphere Streamlines Management of Log Data to Reduce Costs

    Chronosphere today added additional capabilities to its log management platform that enable DevOps teams to both reduce costs and surface more actionable insights.

    Alok Bhide, head of product innovation for Chronosphere, said Chronosphere Logs 2.0 provides DevOps teams with more granular control over how log data is collected and stored. The overall goal is to make it simpler for DevOps teams to not only leverage analytics to identify which log data is actually being used but also more easily correlate it with metrics, events and traces, he added.

    Additionally, Chronosphere has added a Logs Quotas tool that enables DevOps teams to enforce budget restrictions on individual teams all the way down to specific datasets.

    Most DevOps teams are already being overwhelmed by the amount of telemetry data being collected, an issue that will only become more challenging to manage as more cloud-native and artificial intelligence (AI) applications are deployed in production environments.

    There is, of course, no shortage of observability platforms, but as IT environments become more complex, the need for tools that go well beyond simple monitoring of pre-defined metrics to troubleshoot applications has become a lot more pressing. The challenge is observability platforms collect data at levels of scale that from a cost perspective quickly add up. As a result, managing telemetry data has become a significant challenge. Unfortunately, most DevOps teams are not going to be able to hire someone to optimally manage the flow telemetry data. Instead, that needs to be a core capability of the observability platform.

    Less clear in the longer term is to what degree observability will become a task assigned to an artificial intelligence (AI) agent rather than a DevOps engineer. There is no doubt DevOps engineers will need to review the findings of an AI agent that has investigated an incident, but much of the tedious effort required to sort through metric, events, logs and traces should become increasingly automated. Each DevOps engineering team will then need to decide how comfortable they are allowing another set of AI agents to automatically remediate issues as they are uncovered, noted Bhide.

    In the meantime, organizations have never been more dependent on software than they are today, but even as the number of applications being deployed increases, the size of the DevOps teams tasked with maintaining them continues to remain relatively stagnant. In fact, in an AI era where more applications are expected to be deployed in the next few years than the entire last decade, supporting all those applications will require an ability to investigate and, if necessary, remediate anomalies within minutes of being discovered. Legacy monitoring tools were never intended to provide forensics insights in near real time.

    Of course, convincing business leaders to invest in observability platforms can be a challenge. DevOps teams need to be certain that the cost of storing massive amounts of telemetry does not outweigh the benefits. After all, no matter how many issues an observability prevents, someone in the finance team will still be closely monitoring the cost of a platform that over time only continues to grow.

  • Atlassian Adds CLI Option to AI Agent for Building Software

    Atlassian Adds CLI Option to AI Agent for Building Software

    Atlassian has added a command line interface (CLI) option to provide application developers with a familiar construct for invoking Rovo Dev, its artificial intelligence (AI) agent for building software

    Part of a portfolio of Rovo Software Agents that Atlassian now makes available in beta, Rovo Dev completes and debugs code, creates tests, surfaces insights and explanations of code bases, makes suggestions to improve code and generates documentation. It is also integrated with Jira project management software and Confluence collaboration tools provided by Atlassian.

    Using a set of software engineering (SWE) benchmarks maintained by researchers at Princeton and Stanford, Rovo Dev achieved a 41.98% resolve rate across 2,294 tasks.

    It can also be integrated via a Model Context Protocol (MCP) Server to access external data sources capable of providing more context that might be needed to complete a specific task.

    Shuyin Zhao, vice president of product for Atlassian, said the goal is to provide a single agent capable of performing a wide range of tasks versus requiring developers to create workflows that require them to orchestrate multiple agents to build and deploy software. The more memory that can be allocated to an AI agent the more it is able to preserve context, she added.

    Longer term, as the reasoning capabilities provided by large language models (LLMs) continue to expand, the scope of complex tasks that can be assigned to that AI agent will also increase, noted Zhao.

    Eventually, many developers will find they will be spending more time reading and evaluating code rather than writing it themselves, she added.

    It’s not clear how widely AI tools are being adopted by software developers and engineers, but a Futurum Group survey found 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code. The one thing that is certain is more developers than ever are using these tools to write code, but how much of that code is making it into production environments is unknown. In some instances, an AI tool might enable a developer to write better code than they can on their own. In other instances, it might create vulnerabilities or recommend using software packages that simply don’t exist.

    Additionally, even as more code is generated, the existing DevOps pipelines might not be robust enough to deploy software at higher levels of scale than what is already being achieved.

    None of that means AI agents won’t be incorporated into DevOps workflows, but it does mean there is still a considerable amount of effort required to re-engineer those processes in a way that is optimized for AI agents rather than human application developers.

    In the meantime, however, DevOps teams would be well-advised to start creating a list of tasks they are willing to delegate to AI agents, assuming there is some level of supervision. Otherwise, it’s all but inevitable that AI agents might generate the same issues that human developers create, albeit just at a different level of scale. The issue then becomes making sure the right governance policies are in place to prevent as many of those issues from arising in the first place.

  • AWS Extends Cloud Security Reach to Include DevSecOps Tools to Scan Code

    AWS Extends Cloud Security Reach to Include DevSecOps Tools to Scan Code

    Amazon Web Services (AWS) this week made Amazon Inspector, a code scanning tool for surfacing vulnerabilities that is designed to be natively integrated with GitHub and GitLab platforms, generally available.

    Announced at the AWS re:Inforce 2025 conference, Amazon Inspector combines a static application security testing (SAST) tool for analyzing application source-code with a software composition analysis (SCA) tool for evaluating third-party dependencies and an ability to scan infrastructure as code (IaC) for valid definitions.

    Findings from these scans are then surfaced both in the Amazon Inspector console and within the source code management platform as fast feedback for the developers.

    Mitch Ashley, vice president and practice lead for software lifecycle engineering at The Futurum Group, said the expansion of the DevSecOps capabilities provided by AWS into code, dependencies, and IaC enable a critical ‘shift left’ for cloud security, fundamentally embedding vulnerability management earlier into the development lifecycle. That unified approach addresses a long-standing challenge for DevOps teams by accelerating feedback and fostering truly secure-by-design applications, he added.

    Additionally, AWS also revealed it has made available under an open source license a software package, dubbed @verifiedpermissions/authorization-clients-js, that enables developers to implement authorization in Express.js web application APIs in minutes. That approach reduces the custom authorization code that developers would have previously needed to create on their own.

    Finally, AWS demonstrated how it is internally using Amazon Q Developer, an artificial intelligence (AI) agent framework, to identify vulnerabilities in code as it is being developed.

    George Argyros, applied science manager of AWS, told conference attendees Amazon Q Developer makes it possible to “squash bugs” early in the application development process in a way that ultimately serves to improve the quality of the code being created. The overall goal is review code at the time a pull request is made and then surface recommendations to mitigate any issue, with Amazon Q Developer also being used to create and test any patch required.

    It’s not clear how widely the DevSecOps tool and platform being provided by AWS have been adopted, but it’s clear the cloud services provider is now moving well beyond securing infrastructure. It’s still the responsibility of organizations to secure the applications deployed on the cloud, but AWS is making the tools and services needed to achieve that goal more accessible.

    Hopefully, there will even come a day soon when application development teams are routinely using AI tools to prevent vulnerabilities and misconfigurations from being created in the first place.

    In the meantime, however, DevOps teams need to be sure to review the code being generated by AI tools that have been trained using examples of code that is of varying quality. In one instance, that code might be better than what some developers might write on their own. In other cases, segments of code with known vulnerabilities might have been copied multiple times over. In fact, about the only thing that is for certain is that there will soon be more code than ever to scan and review as developers continue to lean on AI tools to create code that they are becoming less inclined to write themselves.