An epidemic of cyberattacks on open-source software has mounted in recent months, making clear how uniquely difficult it is to protect the publicly available code, from both a policy and a technical perspective, that serves as the foundation for so much of the digital world.

While open-source software security got a boost in attention under President Joe Biden — whose administration grappled with the fallout from the potentially catastrophic Log4j flaw that emerged in 2021 — a number of open-source experts say that government protection efforts have suffered setbacks under President Donald Trump. Many also say companies that heavily rely on open-source software, which is basically all of them, haven’t shouldered enough of the responsibility for safeguarding it.

“What we’re seeing is years of lack of investment sustainment in open-source software that is finally starting to catch up to us, where it seems like every week there’s a new supply chain compromise,” said Jack Cable, who held a role at the Cybersecurity and Infrastructure Security Agency where he worked on open-source security before departing under Trump.

The advancements of frontier artificial intelligence models stand to exacerbate the risk further, while simultaneously illustrating what makes defending open source difficult: Project Glasswing said shortly after its announcement that it had uncovered 6,202 high- or critical-severity vulnerabilities in a scan of more than 1,000 open-source projects, but that it had disclosed only 502 of them to open-source project maintainers and only 75 had been patched as of May 22 (albeit some due to typical patching lagtimes).

At the same time, there are questions about how much the government can help, even as overseas governments seek to focus on open-source security.

The evolution of open-source risk 

There are a series of factors contributing to the current threat to open-source software, experts say.

One is simply that attackers go to the area where they can get the highest return on their work. Compromising open-source software gives them the chance to get into the supply chain and exploit additional targets.

“Twenty years ago, open source was still fairly niche,” said Æva Black, who also worked on open-source security at CISA but left when Trump came back into power. “The potential blast radius if you managed to compromise open source was relatively small, because back then the world didn’t run on open source. Now almost everything runs on open source,” she said, from modern cars to satellites.

Another part is the nature of open-source software itself.

“It’s a symptom [of having] lots of open source [that] is a little bit under-maintained or not cared for enough, so that we spend too little effort and money and infrastructure on them,” said Daniel Stenberg, who is the creator and maintainer of cURL, a popular open-source project. “Lots of open source is being maintained by small teams, lots of volunteers, and I think that that’s a tough situation.”

That doesn’t mean the maintainers are to blame, Stenberg said. The companies that rely on open-source need to be diligent about using it, Black said.

“What we’re seeing in that realm right now is not new; it is more advanced and far more widespread,” she said. “The problem remains that companies who use open source — because open source is by far the most efficient way to collaborate on non-product value features — most companies are not implementing a responsible and safe utilization pathway.”

Open-source projects lack a systematic way to handle coordinated vulnerability disclosures, unlike companies or industry groups with formal processes, said Dan Lorenc, CEO and co-founder of Chainguard. Project maintainers sometimes aren’t reachable, and those who are available are flooded with reports, many of them unverified findings from AI tools that waste their time without adding value..

Of course, some of those vulnerability reports turn out to be legitimate. “Mythos and AI models have contributed to an uptick in the number of vulnerabilities and things that we’re able to find” in open-source software, said Alex Zenla, chief technology officer for the cybersecurity company Edera.

All of that leaves more room for companies, non-profits and world governments to improve open-source security.

A moment of momentum

While open-source software security isn’t a new issue, the 2021 discovery of the Log4j flaw sounded alarms within the cybersecurity community. Jen Easterly, then the director of CISA, called it “one of the most serious I’ve seen in my entire career, if not the most serious,” with the potential to affect hundreds of millions of devices given the ubiquitous nature of the popular open-source logging library.

A year later, the Cyber Safety Review Board released its report on the incident, concluding that swift action from industry and government averted a disaster. But the incident “called attention to security risks unique to the thinly-resourced, volunteer-based open source community,” it wrote. “This community is not adequately resourced to ensure that code is developed pursuant to industry-recognized secure coding practices and audited by experts.”

The U.S. government actions after included some steps focused specifically on open-source software such as creation of the Open-Source Software Security Initiative and hires of well-regarded open-source security experts at CISA such as Black, but also some steps that could be applied more generally and still help with open-source security, such as greater promotion of secure-by-design, memory-safe languages and software bills of materials (SBOMs).

Some of the Biden administration work on open-source security started before Log4j, such as provisions from an executive order he issued in 2021 that directed CISA along with the Office of Management and Budget and General Services Administration to issue guidance to agencies. 

The administration’s 2023 cybersecurity strategy also stepped into the long, thorny discussions over software liability, with a mention of open-source security: “Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not on the end-users that often bear the consequences of insecure software nor on the open-source developer of a component that is integrated into a commercial product.“ The Biden administration always indicated that addressing software liability would take a prolonged battle ahead.

Under Trump, many of the Biden administration’s efforts have languished. CISA’s splashy hires on open-source are gone, including Black, Tim Pepper and Anjana Rajan. Also departed are leading figures on secure-by-design and SBOMs, with CISA personnel cutbacks slicing deep. 

No one has seen any sign that the national cyber director-led Open-Source Software Security Initiative is active, with few participants remaining in government today. The Trump administration cyber strategy doesn’t mention open-source.

“The loss of open-source experts at CISA “is unfortunate, and it will be hard for the government to try to rebuild capacity, but I do think now more than ever CISA has a core role to play to secure open source software,” Cable said.

The pressure is mounting

It’s not that the issue is getting zero attention from those in a position to make a difference. Nick Andersen, the acting director of CISA, said last month that open-source security was an area of particular concern for him.

Andersen responded to concerns about CISA staffing levels on open-source security and spoke more broadly on the topic in a statement to CyberScoop.

“As artificial intelligence and other technologies have the power to transform how vulnerabilities are discovered and exploited, CISA recognizes that the open source software (OSS) that underpins much of the nation’s critical infrastructure will need to be hardened,” he said. “CISA actively collaborates with our partners on shared priorities, including OSS security, to ensure time and resources are spent where they matter the most.  We have an immensely talented team, but are also accelerating our hiring in critical areas, to strengthen the nation’s defenses against cyber threats.”

The Office of the National Cyber Director did not respond to requests for comment.

There’s been some activity on Capitol Hill, too. The Securing Open Source Software Act, which Cable worked on during a stint as a Senate staffer, would direct CISA and other agencies to take actions to mitigate open-source software security risks, but the legislation has stalled since its introduction in 2022. A portion of the bill, however, was included in the Department of Homeland Security funding law Trump signed in April, directing CISA to brief Congress on the value of establishing something like an open source program office, which some companies use to manage open source within a given firm.

Senate Intelligence Committee Chairman Tom Cotton, R-Ark., has pushed the executive branch to improve its awareness of foreign adversaries playing roles in open-source software used by national security-focused agencies.

The annual defense policy bill in the House calls on the Defense Department’s chief information officer to report to Congress on a plan to secure open-source software supply chains, saying lawmakers are “concerned that the Department lacks sufficient visibility into the origins, maintenance, and security of OSS applications and software dependencies.”

That defense authorization bill language is “really beneficial, and I think it signals acknowledgement of this changing of culture” around open-source security risks, said Hayden Smith, founder of HuntedLabs, whose company won a contract with the Space Development Agency on supply chain security — agency work that the defense bill singled out.

“The report language is the first time the Hill is trying to get a true handle on foreign influence in open source code where they have oversight,” he said, saying it was a “piece of the puzzle” along with Cotton’s letter and a memo from Secretary of Defense Pete Hegseth last year about foreign influence in the Pentagon supply chain. “It’s good and would trickle down into everyone who provides software to the department.”

Zenla, though, believes trying to isolate China from open-source systems isn’t in and of itself a good idea. 

“I don’t think that that makes a lot of sense, because they’re actually pretty good things that people contribute to open source,” she said. “Not everyone is malicious, and what are we going to do, spy on every single open source maintainer?” It’s more about doing things like making sure that highly-classified systems are set up in a separate way, she said.

Europe is also taking action to secure open-source software that the United States doesn’t seem ready or willing to do right now. Germany, for instance, devotes grants to the security of open-source projects, although Stenberg pointed out that sometimes money doesn’t equate to maintainers being able to fix flaws more quickly, depending on the project’s size.

The Cyber Resilience Act (CRA) adopted by the Council of the European Union in 2024 could offer another road on open-source security. The CRA requires those who use open-source software products as part of any commercial activity to take certain security measures. 

Black said that when she was at CISA, there were discussions between the agency and European counterparts about finding compatible ideas on open-source security, but that momentum died with the Trump administration.

But “Europe kept rolling, and now has in place a new legal framework that is set to really reshape open-source security for potentially the whole world, but certainly for anyone who wants to work with Europe on open source,” she said.

Lorenc recently wrote that “open source isn’t governable.” He said an organization like a neutral nonprofit, possibly using some government funding, should take responsibility for things like coordinating vulnerability disclosure into one pipeline. He also said there needs to be one authority in charge of “forking” — that is, taking a project and assigning stewardship elsewhere — when a maintainer isn’t responsive to vulnerabilities. 

There are differing opinions on how much past government warnings, advisories and guidance have helped. Smith gave some credit to government agencies that “have all responded to open source attacks using the means they have.”

Stenberg said that “I don’t think they make any big dent at all in the big scheme of things.” They might get some attention initially, “then two years later we all forgot about them, and they actually didn’t change much.”

Ideally, everyone could get on the same page, Zenla said. “The best way to do this is if people actually collaborated on a global scale on some sort of regulation around this, but that seems nearly impossible at the current moment,” she said. (The United Nations’ Open Source Week runs all this week.)

But if there’s an upside to the spate of attacks on open-source software, it’s the energy it gives to how better to secure it, Lorenc said, invoking the political saying to never let a good crisis go to waste.

“Everyone knows the industry has to change,” he said. “This is a really good crisis, and the right things are happening in the right places, and organizations are rethinking their culture around software development, and they know what they have to do. It’s just something that’s never been top of the priority list for the last 10 years. Now it is, and they’re doing it, and it’s, ‘Can we do it fast enough?’”

The post Open-source security is posing challenges governments can’t easily solve appeared first on CyberScoop.

The new framework seeks to help security teams identify which software supply chain vulnerabilities pose the greatest operational, safety, and business risks in AI-driven environments.

The post Exclusive: Meet AIVEX, a New Triage Model Built to Reduce Supply Chain Threat and Risk appeared first on SecurityWeek.

A policy paper published Tuesday advocates for software bills of materials (SBOMs) for artificial intelligence as a mechanism for reducing cyber risk and improving transparency, and seeks to give lawmakers, federal agencies and others a roadmap on how to proceed.

The SBOM, commonly described as an inventory of software ingredients, emerged in the 2010s and has expanded beyond software to include hardware and AI.

But the paper from the Institute for Security and Technology, which CyberScoop is the first to report on, argues that AIBOMS require foundational work before they can be widely implemented.  This comes as some companies are already offering AIBOM services and other organizations are actively shaping AIBOM policy.

“What we’re worried about is we would end up in a ‘fire, ready, aim’ situation where everyone was doing it, but we were all doing slightly different things,” said a co-author of the paper, Allan Friedman, who has worked on SBOMs in multiple U.S. government roles. “If we don’t have a shared vision, it becomes a lot harder to have a coherent policy. It becomes a lot harder to have common tools and interoperable data and it becomes a lot harder to use the data that we’re tracking to actually deliver on the promise of supply chain transparency.”

The idea for the paper sprung from discussions with Hill aides and Pentagon staffers, Friedman said, and people like them are the target audience as well.

A key premise is that AIBOM policy needs to explore the topic from two sides.

“How do you solve the chicken-and-egg issue, where no one’s providing the data, so no one’s asking for it, and no one’s asking for it, so no one’s providing it?” Friedman told CyberScoop. “The answer is, you have to go from both supply and demand.”

On the supply side, “An AIBOM should capture relevant details about the models and datasets used for training, fine-tuning, evaluation, validation, testing, retrieval, grounding, augmentation, or other model development or operational purposes,” the paper suggests.

“The demand side begins with some form of forcing function or requirement that organizations understand what is in the products they manufacture and sell,” it states, with one such requirement potentially being an industry mandate to require the tracking of system components — for example, like the “lightweight” standards used in the payment card industry on data security that isn’t overly exact about how components should be tracked.

But it could also include government regulations or contracting conditions, Friedman argues with his Institute for Security and Technology colleague Nick Leiserson. (The scope of government directives on AI is a topic of considerable debate on Capitol Hill and within the Trump administration right now.)

Friedman said the paper isn’t meant to be the be-all, end-all, and acknowledged the prior work of organizations like the Open Worldwide Application Security Project (OWASP) and Linux Foundation.

“We’re not saying this is a brand new topic, nor are we saying that AIBOM will solve all AI security issues,” he said. “I’ve been fighting this fight for SBOM for a decade. You know, SBOM will not pick up your dry cleaning.”

And as AI continues to evolve rapidly, that means papers like the one published Tuesday are just at the beginning of the discussion, Friedman said.

The post A case for how to shape ‘ingredient lists’ for AI models appeared first on CyberScoop.

The goal of the guidance, which outlines minimum elements, is to help organizations enhance transparency in AI systems and supply chains. 

The post G7 Countries Release AI SBOM Guidance appeared first on SecurityWeek.

A group of international government agencies released guidance Tuesday on what they believe any artificial intelligence “ingredients list” tool should include to make AI more secure.

The concept of such a list, known as a “software bill of materials (SBOM),” is to know everything that goes into a particular piece of software so that any supply chain risks are easier to identify. There’s been a growing focus from cyber experts on how they interact with AI.

The guidance produced by agencies from the G7 group of nations, including the Cybersecurity and Infrastructure Security Agency, is aimed at setting minimum voluntary standards for what SBOMs for AI should look like. It builds on past efforts to produce other kinds of SBOM guidance.

“While not exhaustive or mandatory, the supplemental minimal elements outlined in this guidance reflect the consensus of G7 experts and will expand over time to keep pace with the rapid advancement of AI technology,” CISA stated. (Some refer to SBOMs for AI as AIBOMs.)

The elements include those that fall under the categories of information related to the SBOM for AI itself, on the AI system as a whole, for identifying the models used by the AI system, on datasets used during the whole life cycle of the model, on physical and virtual infrastructure needed for operation and support support of the AI system, on cybersecurity measures that apply to AI models and systems and on the AI system’s key performance indicators. 

A trio of industry professionals who have worked on the topic of AISBOMs told CyberScoop they welcomed the guidance, in each case praising it as a good step that could nonetheless be improved upon.

“Pretty much every piece of software out there is now going to have AI incorporated into it, and when a hospital is buying an AI-enabled medical device, or the Department of War is buying an AI-enabled weapon system, or auto manufacturers are putting AI into cars, we need to be able to trust what AI is in those systems,” said Daniel Bardenstein, CEO of Manifest Cyber. “And the first step to trust is to identify what is this AI, where did it come from? How is it trained?”

“This is a strong, applaudable step towards getting everybody on the same page that this is the future of how we need to think about trusting AI,” said Bardenstein, who has built and AIBOM generator and worked on the topic in the past with CISA and the OWASP Foundation.

Dmitry Raidman, co-founder and chief technology officer at Cybeats — and someone who, like Bardenstein, has built his own AIBOM generator and worked on AIBOMs with CISA and OWASP — said the G7 guidance was “amazing” because it covers 80 to 90% of what’s needed.

“There was no baseline, but it now will put out a clear baseline,” he said.

On the downside, Bardenstein said he had concerns with how easily organizations can implement the guidance, and Raidman said it doesn’t adequately tackle the issue of runtime.

Allan Friedman, sometimes called the “godfather of SBOMs,” said the guidance was a good document, but probably mislabeled because it states that the elements it identifies are not mandatory.

“This document is laying out sets of types of data that could be useful,” said Friedman, who worked on SBOMs in multiple U.S. government roles who is senior technical adviser at the Institute for Security and Technology and technologist in residence at TPO Group. “And so it is a great, great piece to advance AI transparency and AI system transparency, but it lists potential elements. These aren’t the minimum elements.”

Friedman said the next steps could include mapping the guidance into what is being implemented today, and talking about aligning it with policies in the European Union and G7 governments to make sure there are minimal conflicts.

The post Major world economies spell out key elements of AI ‘ingredients list’ appeared first on CyberScoop.

Researcher says the missing piece is a governance-driven intelligence layer that turns SBOM and VEX data into explainable security decisions.

The post Are SBOMs Failing? Supply Chain Attacks Rise as Security Teams Struggle With SBOM Data appeared first on SecurityWeek.

Washington has rediscovered consequences. Just not consistently.

The March 6 executive order rests on a simple, correct idea: cyber-enabled fraud persists because it is profitable, scalable, and too often tolerated. So the government’s answer is to raise the cost. More coordination. More disruption. More prosecutions. More diplomatic pressure on the states that shelter these operations.

Good.

But weeks ago, an OMB Memo rescinded earlier federal software supply chain memos issued during the Biden administration. In practice, that pulled back from the prior attestation-centered model and made tools like the Secure Software Development Attestation Form and SBOM requests optional rather than durable expectations.

Put plainly, we are getting tougher on the people exploiting digital systems while getting softer on the conditions that make those systems so easy to exploit.

The executive order gets something important right. Cyber-enabled fraud is not a collection of random online annoyances. It is an industrialized form of predation: ransomware, phishing, impersonation, sextortion, and financial fraud that’s run as repeatable business models, often transnational and sometimes protected by permissive states. The order responds with a more centralized federal posture built around disruption, coordination, intelligence sharing, prosecution, resilience, and international pressure.

That is directionally correct. Criminal ecosystems do not retreat because we publish better guidance. They retreat when the cost of doing business rises.

But then we arrive at software.

The critique of the old federal assurance regime is not entirely wrong. Compliance can become theater. Bureaucracies are very good at turning legitimate security goals into rituals of form collection and checkbox management. Some skepticism was warranted. OMB says as much explicitly, arguing the prior model became burdensome and prioritized compliance over genuine security investment.

Still, the failure of bad compliance is not proof that accountability itself was the problem.

That is where the logic breaks. The administration is clearly willing to believe that criminal actors respond to deterrence. It is willing to use prosecutions, sanctions, visa restrictions, and coordinated pressure downstream. But upstream, where insecure technology shapes the terrain those criminals exploit, the theory suddenly changes. There, we are told to trust discretion. Local judgment. Flexible, risk-based decisions.

Sometimes that is wisdom. Often it is just a more elegant way of saying no one wants a hard requirement.

This is also why my own position has not changed. In a post I wrote in 2024, I argued that the industry did not need softer expectations or another round of polite encouragement. It needed more concrete action and consequences strong enough to change incentives. The problem was never that we were demanding too much accountability. The problem was that insecure software remained too cheap to ship.

That is the deeper issue. Cybercrime at scale does not thrive only because criminals exist. It thrives because the environment rewards them. Weak identity systems, brittle software, sprawling dependency chains, poor visibility, and diffuse accountability all make predation cheaper. The people who ship avoidable risk rarely absorb the full cost of it. Everyone else does.

So these two policy moves, taken together, reveal something uncomfortable. The government seems to believe in consequences for cybercriminals, but not quite in consequences for insecure production. It wants deterrence for the scammer, but discretion for the supplier.

A coherent cyber strategy would do both. It would aggressively disrupt criminal networks and also create meaningful pressure for secure-by-design production and procurement. It would recognize that punishing attackers matters, but so does changing the terrain that keeps making attack profitable.

The administration is right about one thing: cybercrime will not shrink until the costs of predation rise.

The unanswered question is why that logic should stop at the edge of the scam center.

Brian Fox is the co-founder and CTO of Sonatype.

The post If consequences matter, they should apply to vendors, too appeared first on CyberScoop.