devopsy.kinsta.cloud

Tag: Lineaje

Lineaje Adds Ability to Automatically Apply Governance Policies to AI Components

Lineaje this week unfurled a platform that automatically discovers the artificial intelligence components of an application, defines security and governance policies, and then autonomously generates guardrails.

At the core of the Lineaje UnifAI platform are a set of artificial intelligence (AI) capabilities that are integrated with an orchestration framework for applying governance policies that has been embedded within a Model Context Protocol (MCP) server to integrate with AI coding tools.

The Discovery Agents that Lineaje developed continuously map an AI Bill of Materials (AIBOM) to identify every model, agent, MCP server, dependency, skills, and data connections. Additionally, AI agents will craft an AI Kill-Chain model to thwart known threats using the defenses a DevSecOps team has put in place.

Lineaje CEO Javed Hasan said that approach enables the platform to derive application behavior intent from the tools used to design and build an application, which it then uses to generate the appropriate governance policies. DevSecOps teams can also upload internal governance documents that are converted into enforceable policies. In addition, Lineaje’s AI Research Labs continually publishes new policies to address emerging threats in agentic AI environments.

Those updates will prove crucial because the tactics and techniques being created to exploit AI software continue to rapidly evolve, noted Hasan.

Armed with those insights, a DevSecOps team can rely on the UnifAI platform to, in real time, automatically map every system, connection, and behavioral pattern to assess risk, he added.

The platform also automatically recommends policies for data protection, identity and access management, compliance alignment, threat prevention, and vulnerability remediation, eliminating the need for teams to write policies from scratch. The overall goal is to identify and resolve risks before applications are deployed in a production environment, added Hasan.

Ultimately, each DevSecOps team will need to determine to what degree they want to rely on AI to generate and apply governance policies, but in time this process will become automated as confidence in AI increases, noted Hasan.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said the Lineaje UnifAI platform illustrates how AI governance is being operationalized. Automated discovery of AI components, policy generation, and guardrail enforcement can now be embedded directly in the development workflow. This positions governance as a continuous, lifecycle-spanning function rather than a pre-deployment checkpoint, he added.

Additionally, DevSecOps teams gain policy enforcement in a way that is tied to actual application behavior, derived from the tools and dependencies used to build it, noted Ashley. As agentic AI components multiply across the stack, teams that rely on manual policy authorship will face growing exposure; automated AIBOM discovery and kill-chain modeling become baseline requirements, not optional enhancements, said Ashley.

DevSecOps teams will need to determine to what degree they will re-engineer their workflows as more AI components are embedded within their applications. Many of those components, unfortunately, are susceptible to, for example, malicious prompts that are relatively trivial to create. In the absence of any governance policies, the amount of havoc that might be wrought is now far greater than ever.

March 19, 2026
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.

June 4, 2025
Lineaje Adds Module to Manage Open Source Software Security Lifecycle

Lineaje has added an Open Source Manager (OSM) that leverages artificial intelligence (AI) to help DevOps teams prioritize their remediation efforts better.

OSM uses an existing Lineaje AI with a BOMbots tool to analyze software bills of materials (SBOMs). It identifies dependencies and surfaces recommendations for remediation in open source software issues across the software supply chain. OSM adds a module to that tool to centralize workflow management, enabling DevOps teams to apply rules that restrict which open source components can be used based on their IT organization’s policies.

Nick Mistry, senior vice president and CISO for Lineaje, explained that, in many instances, an organization may not have any means of remediating a vulnerability because no patch exists. The best that can be done is to alert the open source project’s maintainers in the hope that they will provide a patch or pass along the guidance to a third party to address the issue.

However, DevSecOps teams still need to identify when patches are available, especially if an issue stems from a known vulnerability that has already been remediated. In many cases, organizations run older versions of software with known vulnerabilities that were subsequently fixed in a later update. In other instances, DevOps teams might just as easily discover that the vulnerability discovered is not manifesting itself in software exposed to the Internet, noted Mistry.

The goal is to reduce the mean time to protect (MTTP) when vulnerabilities in open source software across a spectrum of risk levels, Mistry added. That capability also serves to reduce the total cost of maintaining open source software by surfacing issues involving licenses, code quality, security posture, maintainability, age, supplier and provenance.

DevOps teams can model the potential impact of an upgrade using the Lineaje AI with the BOMbots tool. In addition, fingerprinting capabilities can be applied to make identifying components with suspicious and unknown origins easier. DevSecOps teams could identify open source software projects that are not being well maintained, noted Mistry.

While open source software security issues are a major concern, most organizations are not going to reduce their reliance on these components. Just about every packaged or custom application has at least one open source component. The pace at which modern applications are being built would not be sustainable if it were not for all the reusable open source components that have been made available.

The challenge now is securing the software supply chains that organizations rely on to build applications using those components at a time when governments around to world are starting to hold organizations more accountable for the security of the applications being deployed. OSM, in effect, is designed to enable organizations to achieve continuous compliance with those regulations, said Mistry.

Regardless of motivation, more organizations than ever are clearly focused on securing open source software. The only thing that remains to be determined is how quickly that goal can be achieved before one or more known vulnerabilities lead to a catastrophic breach.

May 30, 2024
Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

Lineaje this week revealed it has partnered with Persistent Systems to provide a managed service for remediating open source vulnerabilities that leverages artificial intelligence (AI) technologies.

Persistent is extending an existing open source software maintenance service by incorporating a Lineaje platform that makes use of machine learning algorithms to analyze software bill of materials (SBOMs) to provide recommendations for fixing code and surface remediations such as updates that should be applied.

Lineage CEO Javed Hasan said Persistent Systems is augmenting that capability with a dedicated team of specialists that IT organizations can contract to maintain open source code along with previous investments the managed service provider has made in large language models (LLMs) that add generative AI capabilities.

Options for the services range from simply identifying issues that an internal IT team should address to a white glove offering through which Persistent Systems ensures all open source components are continuously updated.

In the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, more attention is being focused on the inherent cybersecurity risks associated with employing open source software to build applications. Many open source projects are led by a handful of maintainers that often lack the time and skills required to ensure the components they employ have not, for example, been compromised by malware that might find its way into downstream applications.

Those maintainers are not being paid, so cybersecurity patches to open source software might not be readily made available, and even when they are, many organizations lack the skills and resources required to apply them in a timely manner. The majority of known vulnerabilities within application environments are still unpatched. Many IT teams are also reluctant to upgrade components for fear of breaking applications that have dependencies that are often difficult to track.

It’s not known how much of the open source software that many developers routinely incorporate into their applications might contain vulnerabilities that could be exploited, but the level of technical debt that has accrued over the last several decades is considerable. While only a small percentage of those vulnerabilities have been exploited, cybercriminals are becoming more adept at discovering them.

Hopefully, more contributions to open source projects will improve the overall state of application security, but in the meantime, it’s clear organizations will need to rely more on AI to drive DevSecOps workflows as ever-increasing amount of open source software continues to be relied on to build applications, said Hasan.

The challenge, of course, is identifying which vulnerabilities, if exploited, will have the biggest impact on the organization. After all, at this point, it’s not possible to defend every application so the focus needs to be on prioritizing remediation efforts based on their actual severity rather than a general rating.

In the meantime, DevSecOps teams would be well-advised to have incident response plans in place for remediating breaches involving both known and zero-day vulnerabilities that, in addition to being all but inevitable, can now be exploited within minutes of being discovered.

November 22, 2023
Report: Most IT Teams Can’t Fix Open Source Software Security

Lineaje, a provider of a platform for securing software supply chains, today published an analysis of 41,989 open source components embedded in the top 44 popular projects managed by the Apache Software Foundation (ASF). That analysis found more than a quarter (26%) of vulnerabilities are not patchable by the application development team that deployed them.

In addition, the report found that 64% of the vulnerabilities analyzed have no patch as of yet. Overall, 68% of the vulnerabilities analyzed are due to dependencies created when an open source software project included a component or package developed by another open source project maintainer.

Lineaje CEO Javed Hasan said that means that 90% of open source dependencies are transitive, in the sense that they are created when maintainers of a project included a vulnerable open source component created by another entity. Only 10% of the vulnerabilities discovered by Lineaje are the result of a dependency that an application development team could actually address on their own, he added.

Overall, the report found a full 82% of components that are relied on to build open source software are inherently risky due to vulnerabilities, security issues, code quality or maintainability concerns. In addition, 5% of components failed a basic integrity check, with 3% having no known origin.

Open source software is not created equal no matter what consortium is overseeing its development, noted Hasan. Unfortunately, there is no universally accepted method for validating the integrity of open source software, so application development teams should proceed with caution whenever employing open source software, he said.

The challenge, of course, is that developers have been reusing open source software within applications for years now. It’s only in the recent wake of breaches involving open source software that organizations have been taking a harder look at how applications are developed.

The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is now at the forefront of an effort to better secure open source software by focusing on 10 streams of investment that, in total, will require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure open source software is secure when deployed in a production environment belongs to the organization that deploys it.

Hopefully, following a recent executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead—assuming, of course, the organizations that rely heavily on open source software make more substantive contributions to securing it. In the meantime, organizations can count on the fact that cybercriminals have taken note of the vulnerabilities in applications that can be traced back to flaws in a wide range of open source software.

April 17, 2023
Lineaje Unfurls Platform for Creating and Managing SBOMs

Lineaje this week unfurled a platform for creating and managing the software bills of materials (SBOMs) that are increasingly mandated by enterprise IT organizations and government agencies.

Fresh from raising $7 million in seed funding, Lineaje CEO Javed Hasan said the SBOM360 platform provides a simpler way to manage all the SBOMs that will soon inundate organizations.

The SBOM360 platform makes it possible to use a search engine to discover all the components of an application and all the dependencies that exist within it, including vulnerabilities, and indicators of compromise (IOCs) in seconds, said Hasan. The company then adds fingerprinting technology that enables the platform to attest to the authenticity of the entire software supply chain, he added.

While there is no shortage of tools for creating SBOMs, there are not as many platforms that enable DevOps teams to both create and manage them. In the wake of an executive order issued by the Biden administration requiring federal agencies to have an SBOM for all the software they use, interest in SBOMs to better secure software supply chains has significantly increased. However, very few organizations have a process in place that enables them to operationalize all the SBOMs that might be created.

More challenging still, the pace at which software is being updated has accelerated to the point where many SBOMs are likely to be outdated. The only way to keep pace with that rate of change is to rely on a platform designed from the ground up to dynamically create SBOMs in seconds, noted Hasan.

Finally, IT organizations are now being held more accountable for legacy software often polluted with vulnerabilities that need to be remediated, he added. As such, organizations need a tool that makes it simpler to identify vulnerabilities within the context of an SBOM.

It’s not clear whether greater awareness of the need for SBOMs is translating into concrete action, but the expectation is that more organizations will soon be following the lead of the federal government by requiring them. That shift will naturally bring a lot of additional pressure to bear on DevOps teams. Historically, organizations tended to allow developers to aggregate software components without always checking to see if they are compromised. Cybercriminals are becoming increasingly more adept at injecting malware into software components in the hope that malware will find its way into any number of downstream applications.

Regardless of the approach an organization takes to better secure software supply chains, more rigor is being applied to how software is built and deployed. The days when developers were free to aggregate software components as they saw fit by, for example, relying on open source software downloaded from a repository, are now at an end. The expectation now is the developer will be held accountable for the integrity of all components used within an application as organizations move to implement additional processes to more rigorously review code before it is deployed in a production environment.

February 9, 2023