Category: Features

  • Survey Surfaces Uneven Adoption of SBOMs to Secure Software

    Survey Surfaces Uneven Adoption of SBOMs to Secure Software

    A survey of 100 security professionals finds nearly half (48%) of security professionals admit their organizations are falling behind on meeting software bill material (SBOM) requirements as specified by the U.S. Office of Management and Budget (OMB) Memo M-22-18, Executive Order 14028, and the European Union (EU) Cyber Resilience Act.

    Conducted during the recent RSAC conference by Lineaje, a provider of tools and services for securing software supply chains, the survey also finds a nearly equal percentage (47%) have either not started SBOM integration or are still evaluating tools and practices.

    Additionally, just over a third conceded their organization still has difficulty identifying and tracking open-source components in applications accurately, while nearly a third (29%) still lack the tools and processes needed to analyze SBOMs for vulnerabilities.

    As a result, only 38% of respondents said their organization prioritizes fixing the most vulnerable areas within their applications,

    On the plus side, a full (88%) of respondents expect artificial intelligence (AI) to have the potential to critically or significantly enhance software supply chain security visibility. At the same time, respondents are also aware that AI also introduces additional data security and privacy risks (35%) as well as potential vulnerabilities when used to write code (26%).

    Lineaje CISO Nick Mistry said AI should also make it simpler to determine whether a fix is available for a vulnerability. However, while there seems to be a lot of confidence being placed in the ability of AI to improve software supply chain security, there is still much work to be done, he added. In fact, it’s already been shown how ChatGPT can be used to create an exploit for 87% of known vulnerabilities, so the number of vulnerabilities that might be exploited is about to substantially increase, noted Mistry.

    AI tools have also experienced hallucinations that result in references to software packages that don’t exist. Cybercriminals are now creating software packages that bear the same name as part of an effort to fool developers into downloading software packages that have malicious code, said Mistry.

    Despite those concerns, however, just under a third (32%) of survey respondents said they believe their organization will one day deliver software that has no vulnerabilities. In contrast, 68% said they are uncertain that goal might ever be achieved.

    Ultimately, the ability to build and deploy secure applications comes down to processes. Unfortunately, most of the processes being used to identify vulnerabilities and then mitigate them are still flawed, said Mistry. There is still a tendency to create long lists of vulnerabilities that are then thrown over the proverbial wall for application developers to investigate. Much of that effort, however, is wasted when it is determined that an application that might have a vulnerability is either not externally accessible or the code suspected of having a vulnerability was never actually loaded into memory.

    More troubling still, 70% of the survey respondents admit that when a fix is not available for a vulnerability, they either don’t have or are not sure if they have an alternative remediation plan in place.

    It’s clear that organizations need a more unified view of vulnerabilities that will enable cybersecurity and application developers to work more collaboratively, noted Mistry. The challenge and the opportunity now is to provide those insights into software supply chain security in a way that enables everyone involved to see the same issues not just the same way, but also at the same time.

  • Redgate Extends Effort to Integrate Database Management and DevOps Workflows

    Redgate Extends Effort to Integrate Database Management and DevOps Workflows

    Redgate has updated its Flyway platform for applying DevOps workflows to database platforms to now provide deeper integration into command line interface (CLI) tools and integrated developer environments (IDEs).

    In addition, the Flyway platform now enables state-based deployments using scripts that can be generated based on a specific schema.

    Finally, Redgate is also adding options that enable DevOps teams to choose whether they want to include backups as baselines, automate the backup process altogether or never allow any type of shadow database.

    Max Drobot, group product manager at Redgate, said these latest additions are intended to make it simpler for software engineering teams with varying levels of maturity to start automating the management of databases within the context of a DevOps workflow. Rather than trying to create the perfect process, it’s now simpler for DevOps teams to more easily experiment with automating database deployments without increasing risks, he added.

    While DevOps engineers and database administrators (DBA) often need to work closely with one another, each of these teams has historically developed a separate culture around different classes of tools. Since it first launched Flyway, Redgate has been making a case for a platform that helps narrow that divide by enabling DevOps engineers to, for example, spin up a database when needed versus waiting for a DBA to have the time that would otherwise be required.

    That approach doesn’t eliminate the need for a DBA, but it does serve to reduce the overall level of friction that often exists between DevOps teams and DBAs, noted Drobot.

    The need to reduce that friction will become that much more pressing as the amount of data that needs to be incorporated into the next generation of artificial intelligence (AI) applications continues to exponentially increase, he added.

    Additionally, DevOps teams as part of building and deploying more secure applications will also eventually need to programmatically apply policies and guardrails to the data being accessed by their applications, noted Drobot.

    Managing databases has, of course, become more challenging as the number and types of them has steadily increased. Provisioning and managing databases using legacy manual processes is simply no longer tenable, he said.

    Many organizations are already embracing platform engineering as a methodology for managing DevOps workflows at scale, so it’s now more a question of when database operations will become more centrally managed within the context of a software development lifecycle (SDLC).

    In the meantime, DevOps teams might want to review how application developers are selecting databases for building applications today. All too often, rather than adhering to corporate standards, those decisions are based more on personal preference. In fact, it’s not uncommon for IT teams to find themselves spending time migrating an application developed on one database to another that the organization actually supports.

    Each organization will, of course, need to decide on its own to converge the management of DevOps and database operations but given the pace at which modern applications are now being developed and updated in the age of AI, the amount of pressure being applied to achieve that goal is only going to continue to increase.

  • Harness Adds MCP Server to Expose Data to Third-Party AI Tools

    Harness Adds MCP Server to Expose Data to Third-Party AI Tools

    Harness today revealed it has developed a model context protocol (MCP) server through which it will be able to provide more context to artificial intelligence (AI) tools, agents and platforms that are being used to build software.

    Rohan Gupta, a principal product manager for continuous delivery and AI DevOps for Harness, said exposing the data residing in the Harness continuous integration/continuous delivery (CI/CD) platform will streamline workflows by eliminating the need to rely on custom plug-ins and application programming interfaces (APIs) to provide additional context about the application development environments where code is ultimately deployed.

    Originally developed by Anthropic, MCP is based on a JSON-RPC 2.0 API framework and is rapidly becoming a de facto API standard for integrating AI tools, agents and platforms. The overall goal is to make it easier to expose relevant data to any AI agent that has permission to access it. The overall goal is to make it simpler for AI coding tools to more easily understand the reasons why, for example, a specific DevOps pipeline might have failed, said Gupta.

    DevOps teams will also be able to employ the role-based access controls (RBAC) provided by Harness to limit access to deployment logs only. All the API keys are managed through Harness and no data is ever sent to a large language model (LLM).

    It’s not clear how widely AI tools and platforms have been adopted but a Futurum Group survey finds 41% of respondents expect AI tools and platforms will be used to generate, review and test code, while 39% plan to make use of AI models based on machine learning algorithms.

    Ultimately, DevOps engineers will soon find themselves supervising a small army of AI agents with the help of what are becoming known as Planner agents, said Gupta. It remains to be seen how multiple AI agents will interact with one another to complete an end-to-end task but as orchestration frameworks continue to evolve there will be higher levels of interoperability between agents that both Harness and its third-party partners are continuing to build, said Gupta.

    In the meantime, DevOps teams might want to start creating an inventory of manual tasks that might soon be assigned to an AI agent. As the ability of these AI agents to reliably complete these tasks improves, DevOps engineers should be able to spend more of their time on activities that provide higher value to the business, he noted.

    Arguably, the next major challenge will be the cultural changes that will inevitably occur as more DevOps tasks are automated using AI agents that, for all intents and purposes, are now part of a DevOps team, added Gupta.

    Regardless of approach to building software, the expectation is that the data that AI agents need to write better code will be readily made available. Each organization will need to decide to what degree to trust AI technologies to build software themselves, but ultimately, as the pace of software innovation starts to accelerate in the age of AI, it may soon not be feasible to effectively compete without it.

  • New Relic Integrates AI Agents with Copilot Coding Agent from GitHub

    New Relic Integrates AI Agents with Copilot Coding Agent from GitHub

    New Relic this week made available a preview of an integration with the artificial intelligence (AI) agents it created for its observability platform with the AI agents that GitHub has developed.

    Nic Benders, chief technical strategist for New Relic, said AI agents that the company has developed will now be able to create an issue that GitHub Copilot will be able to use to improve an application. GitHub Copilot will analyze the issue, draft a fix, and submit a draft pull request for human review. The New Relic platform will then validate the change once it is merged.

    In effect, the New Relic and GitHub agents are creating a virtuous cycle to address incidents and performance as they arise, said Benders.

    Just as importantly, the New Relic agents are creating issues in a semi-structured format that is human readable, so DevOps teams will have the option of either assigning that task to a human developer or GitHub Copilot, he added.

    New Relic is making this capability initially available to eligible accounts that are also Copilot Pro+ or Copilot Enterprise users. Launched at the Microsoft Build 2025 conference, the GitHub Copilot coding agent is currently available as a preview to GitHub Copilot Enterprise customers and GitHub Copilot Pro+ users.

    While DevOps teams are making greater use of AI tools, it might be a few years yet before they are fully mastered, noted Benders. Using AI tools to generate code is one thing but integrating AI agents into DevOps workflows is a more complex endeavor, he noted.

    Nevertheless, a recent Futurum Group survey finds 41% of respondents expect AI tools and platforms will be used to generate, review and test code, while 39% plan to make use of AI models based on machine learning algorithms. The challenge now is identifying the specific tasks that might best be handled by an AI agent to reduce the overall amount of toil that goes into software engineering, said Benders.

    Ultimately, AI agents will also make DevOps teams less dependent on a confusing set of observability dashboards as AI agents begin to proactively discover issues, hopefully, before they have any significant adverse impact on application environments.

    Each organization will need to determine for themselves the degree to which they are comfortable relying on AI to build and deploy applications, but at this point, it’s more a question of how much rather than if. There are clearly productivity gains to be had so long as the work of AI agents remains closely supervised by DevOps engineers that have the expertise required to ensure that application quality is maintained and enhanced.

    In the meantime, DevOps teams should be aggressively experimenting with AI tools and platforms, said Benders. Like most powerful tools, it requires knowledge and expertise to get the most out of AI that only comes with hands-on experience, he added.

    After all, the DevOps goal has always been to automate as many tasks and workflows as possible. AI agents are only the latest in a long series of tools and platforms that enable DevOps teams to achieve that goal.