Join us in Minnesota on May 21, 2026 for OpenSSF Community Day!

Category

Blog

May 21
Love0

OpenSSF Notes Quarter of Growth with New Members, Added AI Security Resources, and Growing Community

By Blog, Press Release

Foundation celebrates five additional members, new cyber reasoning sandbox project, and release of v1.0.0 Python Secure Coding Guide to support open source security globally

MINNEAPOLIS – OpenSSF Community Day North America – May 21, 2026 – The Open Source Security Foundation (OpenSSF), a cross-industry initiative of the Linux Foundation focused on sustainably securing open source software, today announced five new members have joined the foundation. The OpenSSF also notes additional technical resources for Python secure coding, the first cohort of OpenSSF Ambassadors, and new projects like OSS-CRS joining the foundation’s sandbox during OpenSSF Community Day North America in Minneapolis. OpenSSF’s efforts ensure that open source remains a trusted foundation for digital innovation by addressing the technical, legal, and human elements of modern cybersecurity.

These milestones address two main converging pressures in the software ecosystem: increasingly mandatory security standards and the need to unify organizations and countries behind those standards. By providing practical resources, the OpenSSF helps projects navigate complex requirements such as the CRA. The project continues to expand its global community as well, keeping all that benefit from open source software ahead of sophisticated risks and threats. 

“As the threat landscape for software supply chains becomes more complex, the need for community driven security standards has never been more urgent,” said Steve Fernandez, General Manager of OpenSSF. “The growth we’re seeing in our membership and the arrival of projects like OSS-CRS show that security is an important priority for all. The OpenSSF is providing the practical tools and guidance developers need to build more resilient software.”

New OpenSSF members include ActiveState, Aikido, Minimus, and TuxCare, who join the Foundation as General Members. The FreeBSD Foundation also joins as an Associate Member. These organizations will contribute to working groups and technical initiatives to help drive the strategic direction of the OpenSSF. By collaborating within a neutral forum, these members support the long term sustainability of the open source ecosystem.

Foundation Updates and Milestones

In the second quarter of 2026, the OpenSSF achieved several milestones to secure and support more resilient software for all: 

  • Publication of the European Union Cyber Resilience Act (CRA) Guides and Resources for Maintainers and Stewards: The Global Cyber Policy Working Group created this technical roadmap to help foundations and projects navigate global regulations, including the EU Cyber Resilience Act (CRA).  
  • OSS-CRS Joins OpenSSF: Following its debut in the DARPA AI Cyber Challenge, the Open Source Cyber Reasoning System (OSS-CRS) has been formally accepted as an OpenSSF Sandbox project to advance AI-driven automated vulnerability finding and patching. 
  • First Release of the Python Secure Coding Guide: The BEST Working Group has announced version 1.0.0 release of the Secure Coding Guide for Python, providing developers with high-confidence anti-patterns and compliant code examples to mitigate common vulnerabilities. 
  • Security Slam 2026 Conclusion: OpenSSF celebrates the successful completion of Security Slam 2026, which resulted in dozens of open source projects reaching the Open Source Project Security (OSPS) Baseline and publishing their first formal threat models. 
  • New AI Security eBook: In collaboration with the Cloud Native Computing Foundation (CNCF), OpenSSF released Securing Open Source in the Age of AI: A Practical Guide for Maintainers, Security Engineers, and Researchers. The guide offers actionable advice for managing AI generated contributions and using AI to improve security.
  • Mentorship Program Expansion: OpenSSF selected eight mentees for its Summer 2026 program. These contributors will provide dedicated support to Repository Service for TUF (RSTUF), GITTUF, SBOMit, and Minder.
  • Inaugural Ambassador Program Cohort: Today at OpenSSF Community Day, the Foundation announced the first cohort of the OpenSSF Ambassador Program, featuring 13 community leaders dedicated to spreading security best practices.

Supporting Quotes

 “The Linux Foundation and OpenSSF are where the serious work on open source security gets done. No single organization secures the software supply chain alone. Thirty years of building secure open source infrastructure is what we bring to that work, and that work is better done together.” 

– Abby Kearns, CEO, ActiveState  

“Open source software is the foundation of modern software development, and supporting that ecosystem has always been core to Aikido’s mission. Through projects like Safe Chain, Zen Firewall, OpenGrep, and BetterLeaks, we’re investing in practical, community-driven security tooling that helps developers build and ship software with speed, trust and confidence. We believe securing open source is a shared responsibility, and we’re proud to contribute technologies that make the broader ecosystem safer and more resilient for everyone.”

– Willem Delbare, Founder and CEO, Aikido Security

“As a critical component of the global digital infrastructure, we believe FreeBSD must be part of the security discussions shaping the future of open source. Joining the OpenSSF will enable us to collaborate with others to help protect the software the world depends on.” 

– Deb Goodkin, Executive Director, FreeBSD Foundation

“Minimus is proud to join OpenSSF and work alongside its other members to help secure the open source ecosystem that allows us all to thrive. Enabling developers to build on open source components while keeping security teams happy is central to our business, and we intimately understand the responsibility we all share in achieving that goal.”

– Kat Cosgrove, Head of Developer Advocacy, Minimus

“TuxCare is pleased to be joining OpenSSF and the cross-industry effort to strengthen open-source security. For more than a decade, we’ve worked to keep open source secure and reliable in enterprise production over the long term. We see that kind of sustained reliability as essential to the trusted, secure open-source ecosystem OpenSSF envisions.”

– Igor Seletskiy, CEO, TuxCare

Events and Gatherings

OpenSSF members are gathering this week in Minneapolis at OpenSSF Community Day North America. To get involved with the OpenSSF community, join us at the following upcoming events: OpenSSF Community Day Europe (Prague; October 6) and Open Source Summit Europe (Prague; October 7-9).

Additional Resources

About the OpenSSF

The Open Source Security Foundation (OpenSSF) is a cross-industry organization at the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all. For more information, please visit us at openssf.org. 

About the Linux Foundation 

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure, including Linux, Kubernetes, LF Decentralized Trust, Node.js, ONAP, OpenChain, OpenSSF, PyTorch, RISC-V, SPDX, Zephyr, and more. The Linux Foundation focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org. 

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Media Contact
Grace Lucier

The Linux Foundation
pr@linuxfoundation.org 

May 21
Love0

Introducing the First Cohort of the OpenSSF Ambassador Program

By Blog

Securing the open source software ecosystem is a monumental task, and it is not one we can tackle alone. It requires collaboration, education, and passionate advocates who are willing to share their knowledge across the globe.

Today, at OpenSSF Community Day, we are beyond excited to announce the launch of the OpenSSF Ambassador Program and to introduce the 13 incredible community leaders who make up our First Cohort!

Earlier this year, we put out a call for community leaders to apply to become OpenSSF Ambassadors. The response was incredible, and reviewing the impressive backgrounds of our applicants reinforced just how dedicated our community is to open source security.

What is the OpenSSF Ambassador Program?

The OpenSSF Ambassador Program was created to empower passionate open source security advocates. Our Ambassadors are recognized leaders who share the OpenSSF vision of a future where open source software is secure by default.

Whether they are writing thought leadership articles, speaking at global conferences, contributing to critical working groups, or mentoring the next generation of security professionals, our Ambassadors are the dedicated champions of our community.

Meet the First Cohort

Over the past couple of weeks, you may have noticed the reveal of our amazing Ambassadors. Today, we are happy to present the complete lineup. These individuals bring a diverse wealth of knowledge spanning supply chain security, policy, community building, and engineering.

Please join us in welcoming:

Ben Cotton is the Open Source Community Lead at Kusari. He has been active in Fedora and other open source communities for over a decade. His career has taken him through the public and private sector in roles that include desktop support, high-performance computing administration, marketing, and program management. Ben is the author of Program Management for Open Source Projects.

Rob Kenefeck is a Field CTO at ControlPlane. He likes to talk about how Security is fundamental to DevOps and how Kubernetes often isn’t the best answer to your reliability problem. A CNCF Ambassador and organizer of KCD Melbourne and CloudCon SYD, he has spent the last several years helping enterprises navigate the intersection of platform engineering, security, and cloud transformation. He participates in the CNCF TAG Security APAC group and brings a community-first perspective to his work believing that open source is how the industry levels the playing field on security.

Ejiro Oghenekome is a Cybersecurity Professional and Open Source Advocate passionate about open source security, cloud technologies, and digital resilience in Africa and globally. She contributes to open source projects like OpenSSF, focused on strengthening awareness and collaboration around secure open source ecosystems. Her interests include cybersecurity research, open source security, and security awareness within the African tech ecosystem, with a growing focus on deepening her technical expertise and contributing to real-world security solutions.

Justin Cappos is a NYU Professor and a Creator of five Linux Foundation projects: TUF, in-toto, Uptane, SBOMit, and gittuf. His research advances are adopted into production use by Google, RedHat/IBM, VMware, Docker, Amazon, Palantir, Lockheed Martin, Datadog,  Bloomberg, millions of automobiles, and other IoT devices, and are also used to protect the legal code across a variety of jurisdictions, including Washington DC, Baltimore, and the State of Maryland.

John Kjell is a Principal Consultant at ControlPlane, where he helps some of the world’s most security-conscious organizations build and assure mission-critical platforms. He is a maintainer of the Witness and Archivista sub-projects under in-toto and serves as a co-chair of the CNCF’s TAG Security. John is also actively involved in several initiatives within the OpenSSF. Prior to joining ControlPlane, he was the Director of Open Source at TestifySec and held engineering leadership roles at VMware.

Brandt Keller is a Staff Software Engineer with a passion for Open Source. He serves as a Maintainer and Technical Lead for the CNCF Security & Compliance Technical Advisory Group, a Cloud Native Ambassador, and a project maintainer within the OpenSSF for the Zarf Project. He has led and contributed to multiple foundation working groups, to include publishing artifacts to enhance end-user security.

Tabatha DiDomenico is an Open Source Security Engineer and Advocate focused on the people and practices that keep open source secure and sustainable. She’s president of Security BSides Orlando, co-hosts the GR-OSS Out podcast, and contributes to OpenSSF and FINOS projects and working groups. At G-Research, she’s part of the Open Source team, working on supply chain security, secure open source practices, and community and developer relations.

Kadi McKean is passionate about the DevOps / DevSecOps community and has been since her days of working with COBOL development and Mainframe solutions. At ReversingLabs she collaborates with developers and security researchers to help entities prioritize their open source risk, reduce technical debt, and meet compliance objectives. When she’s not working with the developer community, she loves running, traveling, and hanging out with her dog Milo.

Roman Zhukov is a Cybersecurity Expert, Engineer, and Leader with over 20 years of hands-on experience securing complex systems and products at scale. Currently Principal Architect at Red Hat, he leads open source security strategy, upstream collaboration, and cross-industry initiatives focused on building trusted software ecosystems. Previously, Roman led Product Security & Privacy for Data Center and AI software at Intel. He is a Security Champion for several open source projects and an active contributor to working groups under the OpenSSF, Eclipse Foundation, and other global initiatives.

Katherine Druckman is a senior technologist, speaker, and longtime advocate for open ecosystems. Currently Head of Community and Partnership Engagement at JetBrains, she specializes in developer experience, combining software ecosystem strategy, content strategy, and community building, grounded in a foundation of hands-on software engineering experience and proven leadership. She is a long-time open source advocate, developer, and podcaster, and is currently the host of the Reality 2.0 podcast.

Hannah Braswell is an Associate Product Security Engineer at Red Hat, focusing on proactively securing complex open source systems. With a B.S. in Computer Engineering from NC State University, she brings a deep background in microarchitecture and embedded systems to her work in the open source ecosystem. As an active contributor to several projects and Working Groups within the OpenSSF, she is passionate about pragmatic development and using automation to enhance security workflows. She currently serves as the Community Manager for the OpenSSF Gemara Project and excels at making technical concepts digestible for all audiences. Outside of her work, she enjoys traveling, hiking, and exploring art exhibitions.

Yunseong Choi Yunseong Choi is a cybersecurity strategist dedicated to resilient open source ecosystems. An adjunct Professor at Kyonggi University and lecturer at Korea University, he bridges the gap between academic research and pragmatic open source security practices. As a member of the Presidential Council on National AI Strategy in South Korea, he spearheads national initiatives for SBOM/VEX standardization and compliance automation. He actively promotes global collaboration within the OpenSSF to ensure secure, sustainable open source ecosystems for developers worldwide.

Walter Pearce is a key Leader of the Rust Foundation’s Security Initiative. Walter comes from a 14-year career in security. For the past seven years, he has specialized in offensive security in the gaming industry, leading efforts to find and mitigate vulnerabilities affecting tens of millions of players at Epic Games and Blizzard Entertainment. Before that, he was a security consultant providing penetration testing, red teaming, and code review services for many Fortune 100 companies whose foci included operating systems, languages, and embedded systems. Walter has always had a passion for technical security problems and has built his career helping craft novel solutions to new, challenging issues in security. In his spare time, Walter enjoys playing open source games. He was previously a contributor and member of the Amethyst Game Engine and a lead contributor on other open source game development projects.

What is Next?

You will see our Ambassadors representing OpenSSF at upcoming industry events, hosting local meetups, and creating content to help developers secure their code. Be sure to follow them on socials, and say hello if you see them in the OpenSSF Slack!

Interested in becoming an Ambassador in the future? Sign up for our Newsletter for announcements regarding our next cohort application window.

May 20
Love0

Detecting Malicious Packages using the OSV API

By Blog, Guest Blog

By Nigel Douglas

By now a bunch of people in the OpenSSF community might already be aware of the Malicious Packages repository, but are you using it as part of your day-to-day software supply chain security?

The OpenSSF Malicious Packages repo is the first open source system for collecting and publishing cross-ecosystem reports of malicious packages – such as dependency and manifest confusion attacks, typosquatting, offensive security tooling, protestware and more.

In the past months we have seen a rise in targeted attacks on open source upstream registries like npm and PyPI – most notably Axios and LiteLLM. These compromised, misleading or outright malicious open source software packages are the focus for this project. A centralised source-of-truth repository for shared intelligence helps the open source community understand the complete range of threats, but ultimately to prevent developers consuming software dependencies that are essentially just backdoors in your codebase.

The reports in the Malicious Packages repo use the Open Source Vulnerability (OSV) format. OSV was, as the name suggests, originally created for classifying open source software packages in JSON-formatted output for known vulnerabilities, fix availability and other security advisory information. By using the OSV format for malicious packages it is possible to make use of existing integrations, including the OSV.dev API, the osv-scanner tool, deps.dev, and build your own tools on top of these open source data sources.

Getting up and running with the API

A good place to start is understanding how malicious packages or malware is classified in OSV. Similar to how vulnerabilities start with “CVE-” (ie: CVE-2025-3248), malicious packages start with “MAL-” (ie: MAL-2025-6812). You can simply curl the existing vulns endpoint for api.osv.dev, but instead of using a CVE ID, use the Malicious Packages ID. 

curl -s "https://api.osv.dev/v1/vulns/MAL-2025-6812" | jq .

While the above command does return a bunch of information about a specific malicious package record, it would assume you already knew what the malicious package ID was in the first place. A more common use-case for the API is to look for a specific package name/version and the associated open source upstream source (ie: npm) to see if there’s a malicious package record associated with it.

curl -s -d   '{"package": {"name": "axios", "ecosystem": "npm"}}'   "https://api.osv.dev/v1/query" | \

  jq '.vulns[] | select(.id | startswith("MAL-"))'

Or in the case of the Axios compromise, there were two different affected versions. Rather than scanning each version separately, you can use the querbybatch endpoint to handle multiple packages, versions and even ecosystems. In the case of MAL-2026-2307, both package versions carry the same malicious package ID. 

curl -s -d \

  '{"queries": [

    {"version": "1.4.1", "package": {"name": "axios", "ecosystem": "npm"}},

    {"version": "0.30.4", "package": {"name": "axios", "ecosystem": "npm"}}

  ]}' \

  "https://api.osv.dev/v1/querybatch" | jq .

Building a custom Kubernetes Scanner

I came up with a simple osv-kubernetes.py scanner. The thought process here is that I could create a simple python-based Kubernetes deployment manifest. This pod has a list of Python packages in the filesystem of the pod, as seen when I run the pip list command.

So, I proceeded to create a fake python library (rather than downloading an actual malicious software package). I mean, the package name and version were real, but I fabricated the entire content of the package. It’s a totally dummy package – as you can see from the below echo commands. Let’s see if our custom osv-kubernetes scanner script will pick it up.

So, we created a fake typosquatted Python package. “Reuests” instead of the legitimate “Requests” library. All versions of the typosquatted Reuests library are tracked under MAL-2022-7441. While this is a simple experiment, it takes us beyond the manual process of scanning each library name and version, and automates it by piping the output of the pip list command into the API query. There are many ways that users can use the OSV API, this was purely an experiment for Kubernetes workloads.

Use OSV-Scanner

While there are certainly use-cases for building your own custom scanners, like what we did with the Kubernetes pod scanner earlier, I would recommend using the official OSV-Scanner to find existing vulnerabilities and malicious code injection affecting your project’s dependencies. OSV-Scanner provides the officially supported frontend to the OSV database and CLI interface to OSV-Scalibr that connects a project’s list of dependencies with the vulnerabilities that affect them.

In the below scenario, I used syft to create a simple Software Bill of Materials (SBOM) in JSON output based on an existing Python requirements.txt file. As we found out earlier, the OSV API is entirely JSON-structured, so we wouldn’t scan unstructured .txt files. The most common file to scan would be the SBOM or lock files (ie: osv-scanner –lockfile=package-lock.json).

syft packages requirements.txt -o cyclonedx-json=sbom.cdx.json
osv-scanner -L sbom.cdx.json

As you can see from the screenshot, the CycloneDX SBOM is successfully sourced. The packages LiteLLM and requests were correctly identified as being from the PyPI ecosystem since the Python requirement.txt file was converted into SBOM. As well as having multiple security advisories related to an upstream compromise, LiteLLM was corrected marked as malicious – MAL-2026-2144.

Again, this process is good and all, but you really need to integrate it into the CI/CD process. The OSV-Scanner Github Action leverages the malicious packages repository and the OSV-Scanner CLI tool to track and notify you of known malicious packages across the existing languages and ecosystems. The most common workflow for Github triggers a scan with each pull request and will only report new instances of malware introduced through the PR. The Github Action compares a scan of the target branch to a scan of the feature branch, and will fail if there are new vulnerabilities or malicious packages introduced through the feature branch. Alternatively, this process can be achieved on Scheduled Scans using a cron job.

Moving towards best practices

I say this a lot, but in light of the recent axios@1.14.1 compromise, please make sure you always commit your npm project with the package-lock.json file. It is the only version-locking enforcement mechanism that exists in npm today. Developers should be using npm ci instead of blindly using npm install on Javascript libraries sourced from npm. The npm ci command will only work if a package-lock.json file exists. These lockfiles can also be easily scanned, as seen with osv-scanner. 

Likewise, if you need to update or pull new packages from open source registries like npmjs.com, it’s also worth using the –min-release-age flag (available since npm v11.10.0) to make sure you only install updates, which are at least 3 days old (ie: npm install –min-release-age=3). Most open source malicious packages end up getting classified by OSV.dev within the first 3 days, so configuring a cooldown period is perfect to help prevent consumption of unknown or new variants of malware campaigns.

You can literally hardcode this setting (min-release-age=7) into your .npmrc file. There will always be more malicious actors attacking popular npm and PyPI packages in the future. Thankfully, most will get caught in the first 24 hours, in part due to the fantastic work going on within the OpenSSF Malicious Package packages project. I’m not trying to say that the Javascript (npm) and Python (PyPI) ecosystems are broken by design, but we certainly cannot apply blind trust to the software supply chain.

Get Involved: Help Us Secure the Ecosystem

The strength of the OSV project lies in its community. You can help protect the open source landscape by:

  • Reporting Threats: If you encounter a malicious package, report it to the OpenSSF Malicious Packages repository.
  • Contributing: Help us improve the database by contributing to the OSV project or integrating the API into your own security tooling.

About the Author

Nigel Douglas is the Head of Developer Relations at Cloudsmith. He champions Cloudsmith’s developer ecosystem by creating compelling educational content, engaging with developer communities, and promoting software supply chain security best practices. Nigel helps build and shape the DevOps community through events, tutorials, and innovative programs.

May 18
Love0

Taking Stock of the State of European Cyber Resilience Act (CRA) Compliance: An Urgent Wake-up Call for the Open Source Ecosystem

By Blog, EU Cyber Resilience Act, Global Cyber Policy

By Christopher (CRob) Robinson, OpenSSF

For the better part of two years, discussions surrounding the European Cyber Resilience Act (CRA) have been somewhat theoretical: mapping requirements, debating definitions, and analyzing how the requirements will impact our amazing ecosystem. But folks, it’s mid-2026, and the CRA is live. Theory is officially in the rearview mirror as implementation milestones roll out over the next two years. 

I’ve just finished reviewing the finalized 2026 CRA Awareness and Readiness Report, a joint effort with LF Research experts, and to be blunt, the results are a sobering reality check. Despite tireless community work, the broader ecosystem is far from ready for CRA compliance.

CRA Awareness Has Stalled 

The most disappointing finding is that awareness surrounding this regulation has decreased year-over-year. Today, 66% of respondents remain unfamiliar with the CRA, a slight increase from 62% in 2025. That means a growing portion of the software ecosystem is unaware of a regulation with global consequences and hefty fines. 

The geographic disparity is even more alarming. In the United States and Canada, nearly 72% of respondents are unfamiliar with the regulation. It cannot be understated: if you are a North American company selling software products into the EU market, you are legally required to comply with the CRA. However, the majority of the neighborhood is still walking unprepared toward a September 2026 reporting deadline. 

Why the “Consume and Forget” Model is No Longer Possible

For years, organizations have treated open source like a free lunch: grabbing code and assuming the lights are being kept on by someone else. Under the CRA, that posture is no longer tenable. Manufacturers now bear the legal responsibility for the security of the components they integrate. For some (read: most) this is a stark wake up call. 

Despite that, 51% of manufacturers still passively rely on upstream projects for security fixes. In the new world of the CRA, “passive” is a level 10 risk.

Private Forks Are Not the Answer (They’re Worse) 

Many of you have tried to dodge the upstream journey by maintaining private forks, but inefficient code is still inefficient code, and now we have the bill to prove it. The report shows that maintaining private workarounds is a massive form of technical debt, costing organizations an average of $258,000 in labor every single release cycle. With some release cycles as short as a matter of hours, these costs can quickly get out of hand. 

For large organizations (5,000+ employees), this burden exceeds 11,152 labor hours per cycle. Maintaining these divergent codebases is a giant bill for a strategy that actually makes supply chain transparency worse. Contributing fixes upstream isn’t just being a “good neighbor” – it’s the only financially rational path forward.

For the last several years, the OpenSSF community has observed traditional vulnerability disclosure systems buckling under the strain of volume of discoveries being reported through them. Data from the report points to a surge of 394% increase in Common Vulnerabilities and Exposures (CVEs) and an 811% spike in vulnerabilities that fall within the High+ severity categories in the first quarter of 2026. Several factors contribute to this trend:

  • Transparency: Open source is open and transparent, which means the community cannot hide vulnerabilities behind opaque processes or paywalls. 
  • Project Growth: Year-over-year we’re seeing an explosion of MORE open source projects.
  • Ubiquity: Open source is quite literally the majority of software used globally. 
  • AI Tools: More users are leveraging Large Language Models (LLMs) and other tools to explore and analyze software. The transparency of open source software offers a low barrier of entry for those using these new tools and test code. 

Globally, regulations like the CRA are codifying long-standing security guidance into law. This shifts security from a “nice-to-have” recommendation to a legal requirement backed by heavy non-compliance fines. 

How Does Upstream Investment Improve Your Security Posture? 

On the bright-ish side the data reveals a clear correlation: organizational diversity is a strong predictor of a project’s security posture. When more organizations invest in a project, that project becomes more resilient, making upstream investment a direct catalyst for your own compliance posture. Organizations have an important role in their own security health through their participation in open source projects.

However, the participation of small and medium-sized enterprises (SMEs) is crucial to the entire ecosystem, they are the backbone of the industry. Currently, over half of European SMEs remain unfamiliar with the CRA, creating a significant gap in project diversity. Directed investment in SME engagement is essential to prevent compliance from becoming a structural barrier to innovation. By funding the support and tools these smaller players need to remain compliant, we ensure the entire upstream supply chain remains robust and competitive.

What OpenSSF Resources Can Help Organizations Prepare for the CRA? 

While we wait for the full 2026 report to drop, the tools to succeed already exist. Our previous research, Unaware and Uncertain: The Stark Realities of Cyber Resilience Act Readiness in Open Source, highlighted these same gaps a year ago. It’s time to start acting. The tools to succeed already exist and practitioners who find our resources rate them highly:

This ecosystem is rife with the talent and the collaborative instincts to meet this challenge. The December 2027 deadline is a forcing function, but it’s an opportunity to build a software supply chain that is actually secure by design.

Europe is leading the way in protecting consumers globally. Despite our geographic distance in the U.S., the oceans between us all do not provide isolation from this regulation any longer. Software and products with digital elements are built with hardware, software, and firmware created through international collaboration. That fact feeds the global economy and makes manufacturers globally responsible for CRA adherence. Events that happen “over there” DO truly affect everyone.  

The results of the CRA research conducted with our peers in LF Europe is truly grave. A significant amount of work and collaboration has occurred across the ecosystem since CRA enforcement. It is shocking to look back at all this work done by both the OpenSSF and its partners and see that 39% of manufacturers, who have BILLIONS of euros at stake in potential non-compliance penalties, are still unaware and uncertain about their requirements.  

The next stage in our shared journey together unfolds  in September 2026 when the vulnerability reporting obligations are enforced. There is not much time to prepare. Organizations have a narrow window to audit their upstream dependencies and establish the processes needed to report and patch new vulnerabilities as they emerge. The more complex aspects of the CRA are currently a year out, coming due December 2027. Please, take action today to protect yourselves, your companies, the upstream maintainers on whom you depend, and your customers.

The OpenSSF encourages everyone that benefits from open source software to consider the beauty and complexity of the open software world. Every day in software repositories, chat channels, and mailing lists a talented cohort of developers co-engineer the tools you use and love. We ask that organizations and their leaders understand that free software is NOT free. Being a responsible consumer and participant in the  ecosystem creates benefits for everyone. With CRA in our midst, there is ample opportunity to make this shared space better and more secure for everyone. My hope is that we can rise to that opportunity.

Stay Ahead of the CRA

Be the first to read the 2026 CRA Research Report. Subscribe to our newsletter for an alert when it releases the week of June 9 (European Open Source Security Forum in Brussels).

Get involved with the OpenSSF Global Cyber Policy Working Group.

About the Author

Christopher Robinson (aka CRob) is the Chief Technical Officer and Chief Security Architect for the Open Source Software Foundation (OpenSSF). With over 25 years of experience in engineering and leadership, he has worked with Fortune 500 companies in industries like finance, healthcare, and manufacturing, and spent six years as Program Architect for Red Hat’s Product Security team.

May 12
Love0

Hack to the Future: The Impact and Legacy of the DARPA AIxCC Challenge

By AI, Blog, Global Cyber Policy, Guest Blog

By Helen Woeste

AIxCC Competition Background & Results: 

In 2023, DARPA announced a two-year long competition called the Artificial Intelligence Cyber Challenge (AIxCC) with the goal to safeguard open source software used in critical infrastructure throughout America. The intent is to hasten the development of open source AI tooling that can assist developers with finding and fixing bugs in live software with minimal cost. Open source is a drastically underfunded and underresourced form of infrastructure. It therefore presents an exciting, practical target, and opportunity for the research and development of AI in cybersecurity. Additionally, open source’s publicly observable code is ideal for competition and collaboration. 

AIxCC was run in collaboration with ARPA-H and supported with contributions from Anthropic, Google, Microsoft, and OpenAI, with additional consulting around open source provided by the Linux Foundation and the Open Source Security Foundation (OpenSSF). This research was developed with funding from the Defense Advanced Research Projects Agency (DARPA). The competition consisted of two rounds, the Semifinal Competition (ASC) and the Final Competition (AFC), where cash prizes from a pot of $30,500,000 were distributed. For the ASC, 42 team submissions were accepted across two tracks; the Open Track and the Small Business Track, which required an additional technical paper submission. The top seven teams moved forward to the AFC which was set up to mimic a real world CI/CD pipeline. The scoring algorithm was also designed to highlight behaviors that would make the competing systems more useful to developers. At the conclusion of AFC, the top three teams were Team Atlanta, Trail of Bits, and Theori. 

For the AIxCC competition, real open source projects were selected, and their code was forked and then modified to insert artificial bugs for the Cyber Reasoning Systems (CRS) to discover and fix. However, during the execution of the competition, the CRSs discovered several real potential bugs alongside the artificial ones. This introduced the issue of how to triage and manage resolution of fixes in the projects. OpenSSF engaged third party open source security organization Open Source Technology Improvement Fund (OSTIF) to get involved with the closing out of the bugs identified as a result of the AIxCC competition. 

OSTIF selected the team at Ada Logics for their extensive experience working with open source fuzzing, bug verification, and disclosure. With a list of potential bugs identified through the course of the competition, Ada Logics was tasked with securely submitting verified issues, ensuring that anything reported to open source project maintainers was a proven bug. The Ada Logics team was able to reproduce and confirm twenty-seven issues after multiple rounds of testing and continued coordination between AIxCC competitors, collaborators, and contributors. CRS teams, including Team Atlanta, Team Buttercup, Team FuzzingBrain, Team Shellphish, Team Theori, Team 42-b3yond-6ug, and Team Lacrosse, working together with Kudu Dynamics and the OpenSSF, continued to collaborate and meet with OSTIF around the disclosures to ensure total accuracy of the reported issue’s testing and resulting decision around disclosure. 

It was of utmost importance that any and all real bugs detected during the competition were verified before alerting the project maintainer to the issue. This is to differentiate how the competition reports issues to projects from the low-quality reports plaguing open source maintainers today. In several cases, CRS-generated patches were submitted alongside bugs, an offering to project maintainers looking to quickly resolve the finding. Additionally, feedback was sourced from the projects around their experience as a target in the competition as well as the disclosure procedure following. 

The Findings:

Teams discovered twenty-seven candidate real-world issues during the competition and OSTIF engineers were ultimately able to replicate all of the draft bugs. The affected projects were cURL, shadowsocks-libev, healthcare-data-harmonization, hertzbeat, little-cms, and mongoose. Once identified, the hard work began of fixing those bugs, implementing CRS tooling to perform the second half of its double duty to find and fix security issues. 

However, some of the findings did not meet a level of security concern for various reasons. Some issues were fixed by code changes in the projects during the time-period in between the competition and when engineers reproduced them. Others were outside of the threat model of the project and did not meet the criteria needed to incorporate into the project (for example, the Apache Poi project threat model states “Expect any type of Exception when processing documents,” making any exception-based findings non-issues). One issue had actually already been found by OSS-Fuzz, but the project hadn’t fixed it yet.

Ultimately, interesting findings were discovered and fixed by the Cyber Reasoning Systems in this competition, and the systems found a lot of valid issues. Further, some projects had introduced fixes before the bugs were reported. This is likely because the AIxCC teams submitted the fuzzing harnesses to the projects before triage had taken place, which re-discovered the same bugs before triage had completed. One significant lesson learned from this is that cyber reasoning systems may benefit from doing self-triage when discovering potential issues by checking against the project’s documentation and understanding the types of issues that the project accepts as security bugs that need to be addressed.

Conclusion & Looking Forward:

The AIxCC program was a massive undertaking by dozens of organizations, all working to contribute back to open source security in a meaningful way using novel AI tooling. The competition was mindfully designed and carried out, with attention given towards the open source projects and maintainers, the wide variety of competitors and interests, and the impact of the competition itself on the industry all the way down to the maintainers. 

OpenSSF is the home for extended collaboration on these new open source tools through its newly formed Cyber Reasoning Systems Special Interest Group. OSS-CRS and FuzzingBrain, two open source projects that emerged from the competition, are now hosted at OpenSSF in the Linux Foundation. A third tool applied and was accepted to the OpenSSF, and has a few remaining steps before the official transition. The group aims to foster their development and adoption, and to establish best practices that help projects use CRSs effectively and responsibly.

This work is already producing real results. For example, FuzzingBrain has since turned its AI-assisted fuzzing system on the broader open source ecosystem, discovering sixty-two vulnerabilities across twenty-six projects, from CUPS and Apache Avro to Ghidra and OpenLDAP, with forty-three confirmed by maintainers and thirty-six already patched upstream. 42-b3yond-6ug has expanded its CRS to uncover twelve kernel-related vulnerabilities in the Linux kernel and related components, plus ten zero-day vulnerabilities in userspace projects including Eclipse Mosquitto and OpenLDAP. The team is also developing a platform to support more efficient model training and evaluation of models and agents, with a release expected soon. Using OSS-CRS, Team Atlanta discovered twenty-five vulnerabilities across sixteen projects spanning a broad range of software including PHP, U-Boot, memcached, and Apache Ignite 3. Of those, nine have been fixed and eight more have been confirmed with fixes in progress.

The future of AI assisting maintainers in finding and fixing security vulnerabilities is bright. The challenges raised by the AIxCC competition already have solutions being developed in open source, such as LLM-based tools that build threat models by looking at the data-flow of projects, and AI agents that triage findings against threat models and documentation before reporting issues. As these tools all continue to develop, they will harmonize into reliable solutions that maintainers can use to elevate their security with far less effort than today.

Our gratitude to the folks at Ada Logics for triaging the potential bugs and working hard to reproduce the issues so maintainers didn’t have to, OpenSSF for trusting us to bring together all of the stakeholders to work on the issues together, DARPA and ARPA-H for holding the AIxCC competition and sponsoring this work, the teams that built the Cyber Reasoning Systems for the competition, Kudu Dynamics for their support in confirming the findings, and all of the maintainers that worked with us to resolve the issues.

OpenSSF and OSTIF will continue to support this kind of work by serving as human connectors between CRS tools and open source communities. The goal is to help triage and validate vulnerability reports and proposed patches before they reach maintainers, ensuring findings are accurate, actionable, and respectful of maintainers’ time.

Organizing a competition of this scale on behalf of open source maintainers and its end users takes both enormous collaboration and individual effort. Understanding the communities involved, and building lightweight programs that shield maintainers from headaches while strengthening security is the best possible outcome for the ecosystem. It took everyone coming together to make this happen, and ongoing efforts will bring low-cost and low-maintenance tools to everyone that are valuable and make us all safer. 

As AI moves forward at breakneck speed, innovative work like this highlights how you can move fast and build things together for a better tomorrow. 

Author Bio

Helen Woeste joined OSTIF in 2023, coming from a decade of work experience in the restaurant and hospitality industries. With a passion (and degree) for writing and governance structures, Woeste quickly transitioned into an operations and communications role in technology. 

 

The views, opinions and/or findings expressed are those of the author and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.

Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)

May 06
Love0

Open Infrastructure Is Not Free, Part II: The Hidden Cost of Running Package Registries

By Blog

The September 2025 Working Together Towards Sustainable Open Source open letter raised the alarm about the economic sustainability of open source package registries, highlighting how rising adoption and the pace of innovation are placing new and growing pressures on open source package registries. Those pressures have only accelerated in the time since the letter, amplified by the adoption of AI coding agents and tools.

But what are the real economics of an open source package registry? Beyond obvious infrastructure costs, there’s significant, often invisible work required to keep registries running, maintained by a small number of staff and volunteers. It’s more than just uploads and downloads. It’s strengthening security as threats evolve, continuously improving the developer experience, and more.

To ensure long-term sustainability, the registries have formed a Sustaining Package Registries Working Group hosted by the Linux Foundation to collaborate on and share community-aligned strategies and offerings. The right set of strategies will vary by registry and evolve over time, and some registries have already rolled out new approaches.

Behind the Scenes of a Package Registry

Registries today run primarily on two things: (1) infrastructure donations and credits; and (2) heroic efforts from small paid teams (themselves funded by donations and grants) and unpaid volunteers that operate and maintain registry services. The bulk of donations and grants comes graciously from a small set of donors who care about the value of package ecosystems, but even these donations don’t scale with demands on the registries.

The core job of a registry is to accept packages from open source publishers and make them available for consumers to download: simple in concept, demanding in practice. We expand on the behind-the-scenes jobs below.

Scale Drivers for Registries

For a sense of scale, the registries – npm, Maven Central, PyPI, Crates.io, RubyGems, Open VSX, Packagist, Hex, CPAN and more than a dozen others – will serve over 10 trillion open source package downloads in 2026 as the headwaters of the world’s software supply chains. 

That’s more than one billion downloads per hour or just under double the predicted number of Google searches that will be run in 2026. 

That 10 trillion number is incomprehensibly large but believable. Modern applications contain not just some open source but hundreds of dependencies often spanning language ecosystems, e.g., your Python package manager may be written in Rust, or the continuous integration system for your Java application may be written in Ruby.

The consumption side of the registry ecosystem – those 10 trillion downloads – is part of the pressure on sustainability, and it’s tempting to look at a “click charge” as part of the solution.  

Nonetheless, the scale of adoption and commercial use places a significant infrastructure and human load on the registries to the tune of millions of dollars per year of CDN, infrastructure, and labor.

The AI Boom Presents Big Challenges

Beyond adoption driving downloads, AI is another scale driver, amplifying both legitimate and malicious activity. AI is accelerating the rate of consumption and production of open source, pushing registry management beyond the scale of human action or oversight. (The difference between Python’s 2025 report and 2026 trajectory is striking: PyPI added 130,000 new packages in 2025, nearly matching its total of 140,000 in 2018, and the registry is adding nearly 900 packages per day in 2026.)

Registries also play a front-line role in supply chain security, keeping malware and vulnerabilities from entering the open source ecosystem, and the “good guys” aren’t the only ones using AI.

Attackers are using AI to create and ship more novel, more difficult-to-detect attacks more quickly. The community is still in the thick of Shai-Hulud and other recent supply chain attacks like the ones on Trivy and LiteLLM, and even more recently, the Axios compromise, which demonstrated how AI and social engineering are converging. But going back to 2021, where we can get a full picture of the end-to-end cost of a significant vulnerability, remediating the log4shell (CVE-2021-44228) vulnerability consumed around 10% of a year’s enterprise security effort across the industry.

Complexity Drivers for Registries

With some background on scale and AI drivers, let’s dive into the high-level jobs to be done by a registry, and it’s a long list. No registry does all of these jobs in depth today. Depending on scale, some jobs require fractional or sporadic attention while others, like site reliability engineering, might require a team.

  • Identity and Access Management: Managing publisher identities, credentials, permissions, and audit logs is essential to secure package publication and support incident response.
  • Namespace and Ownership Management: Protecting namespaces and defining publisher, maintainer, and owner roles helps prevent abuse such as brandjacking and typosquatting.
  • Package Ingestion and Validation: Registries must store packages, index metadata, and validate elements like structure, licensing, and signatures to ensure quality and trust.
  • Supply Chain Security and Risk Management: Registries help secure the supply chain by blocking, flagging, quarantining, or removing vulnerable or malicious packages and surfacing risk in package metadata.
  • Registry Security: Registries require continuous hardening, review, and monitoring because a compromise could put the entire ecosystem at risk.
  • Registry Availability: Maintaining reliable publication, discovery, and consumption services requires strong monitoring, alerting, and operational support to minimize downtime.
  • Package Discovery, Search, and Evaluation: Consumers need robust search, filtering, and quality signals to find relevant packages and assess their health and ecosystem importance.
  • Consumption, Distribution, and Mirroring: Registries must deliver packages efficiently through scalable infrastructure while keeping caches and clients aware of upstream changes such as vulnerabilities and new versions.
  • Governance, Policy, and Community Support: Operating a registry requires clear policies, transparent enforcement, and ongoing legal and community support as global regulations evolve.
  • Observability, Analytics, and Ecosystem Insights: Registries provide unique visibility into publishing and consumption patterns, enabling insights that publishers and consumers often cannot gather on their own.

Sustainability Call to Action

With massive traffic, a mountain of hard work to do, supply chain attackers at the gates, and a mission to keep access for individuals open and free, the registries need funding and paid services or models that scale with the demands. The way to get there is to bring commercial users and ecosystem stakeholders to the table as paying customers.

The Sustaining Package Registries Working Group is bringing registry leaders together to define what sustainable operation looks like across funding, operations, and transparency.

Now the ecosystem needs to meet that moment. The companies that depend on these systems must help sustain them so the next generation of software can be built on infrastructure that is not just open, but resilient.

Alpha-Omega 

Continuous Delivery Foundation (CDF)

Eclipse Foundation (OpenVSX)

OpenJS Foundation

Open Source Security Foundation (OpenSSF)

Linux Foundation

Packagist (Composer)

Perl and Raku Foundation

Python Software Foundation (PyPI)

Ruby Central (RubyGems)

Rust Foundation (crates.io)

Sonatype (Maven Central)

Apr 17
Love0

Why Third-Party Notices Are Breaking at Scale: What the Ecosystem Needs Next

By Blog, Guest Blog

By Devashri Datta, Independent Researcher, Software Supply Chain Security

Third-party notices (TPNs) are documents distributed to users that list open source third-party software components included in the product and key licensing information. Every time you buy a TV or router, you’ve probably seen them. Yet TPNs were never designed for the complexity, scale, and velocity of today’s software ecosystem. TPNs are one of the most widely distributed and yet least understood artifacts in modern software supply chains.

Inside nearly every appliance, firmware image, SaaS platform, and enterprise distribution, the same pattern persists: a long, unstructured PDF is expected to represent the full scope of open source license compliance.

As software systems have scaled, TPNs have quietly become a critical but increasingly fragile pillar. They are now failing technically, operationally, and structurally under the demands of modern development and distribution.

This article examines why TPNs are breaking. It also outlines what the ecosystem must do next based on large-scale analysis of real-world TPN documents and the development of an automated framework for extracting information directly from them. While traditionally viewed as compliance artifacts, Third-Party Notices (TPNs) also represent an underutilized source of security-relevant intelligence. In many real-world scenarios where Software Bills of Materials (SBOMs) are incomplete, unavailable, or restricted, TPNs may provide the only observable evidence of component usage. This positions TPNs as a critical input to software supply chain security workflows, including vulnerability management, third-party risk assessment, and incident response.

The Hidden Reality: TPNs Are the Supply Chain’s Last Mile

Despite advances in Software Bill of Materials (SBOM) formats such as SPDX and CycloneDX, TPNs remain:

  • The only compliance artifact that many vendors publicly distribute
  • The only artifact available to customers or regulators for proprietary systems
  • The only verifiable attribution record when source code and SBOMs are inaccessible

SBOMs provide structured visibility into software components, but their completeness depends on the generation methods and the availability of build-time data. In practice, SBOMs may not consistently capture full transitive dependencies or runtime-resolved components. In some cases, additional components and licensing details may appear in downstream artifacts such as third-party notices (TPNs), though these are typically not integrated into SBOM analysis pipelines. SBOM availability also varies across organizations and products and may not always be accessible to end users or external stakeholders due to policy or regulatory interpretation. Regulatory frameworks such as the EU Cyber Resilience Act (CRA) are evolving, and expectations around SBOM scope and disclosure remain subject to interpretation. As a result, relying solely on SBOM data may not provide complete visibility into whether a product contains a specific vulnerable component, depending on SBOM completeness and related artifact availability.

In practice, TPNs often serve as the last mile of compliance visibility, bridging internal software composition and external disclosure.

However, TPNs were never designed to operate at the scale or complexity of today’s supply chains.

Security Blind Spot in Software Supply Chains

While SBOMs and software composition analysis (SCA) tools have improved visibility during development, they assume access to structured or source level data. In contrast, TPNs often represent the only externally available artifact in downstream consumption environments such as embedded systems, firmware, and proprietary SaaS distributions.

This creates a structural blind spot in software supply chain security: security teams are frequently forced to make risk decisions without machine readable component intelligence. As a result, vulnerability exposure, dependency risk, and third-party software usage often remain partially or completely unobservable at the point of consumption.

Why the TPN Ecosystem Is Breaking

PDFs Are an Anti-Pattern for Machine-Readable Compliance

Most TPNs are distributed as large, heterogeneous PDFs containing:

  • Multi-column layouts
  • OCR artifacts and noise
  • Inconsistent license formatting
  • Duplicated or truncated license text

TPNs often omit component identifiers and lack specific version numbers for components.

PDFs are optimized for display, not structured data. As a result, extracting meaningful compliance information programmatically is extremely difficult.

Existing Compliance Tools Don’t Address the Problem

Current tools such as FOSSology, ScanCode, and ORT are designed to analyze source code or binaries—not TPN documents. Yet in many real-world scenarios, especially audits or vendor reviews, TPNs are the only artifact available.

This creates a fundamental gap: The most widely distributed compliance artifact is the least analyzable.

Inconsistent Generation Pipelines Lead to Data Drift

TPNs are generated through highly variable processes:

  • Custom scripts
  • Proprietary internal tooling
  • Manual aggregation from legacy systems
  • Partial or outdated SBOM exports

As a result, even TPNs from the same organization can vary significantly across releases, introducing inconsistencies, omissions, and misalignment with actual dependencies.

Scale Has Outpaced Human Review

Modern TPNs often span hundreds of pages across multiple license families and components.

Manual review has become increasingly impractical due to:

  • Repetitive license text
  • Poorly structured component mappings
  • Lack of contextual metadata
  • Hidden obligations within large text blocks

Compliance teams are effectively being asked to analyze documents at a scale that exceeds human capability.

Proposed Contribution: TPN-to-Security Intelligence Framework

This work introduces a systematic framework for transforming Third-Party Notices (TPNs) from unstructured compliance artifacts into structured security intelligence inputs. The framework addresses a critical gap in software supply chain security: the absence of machine-readable component visibility in downstream and vendor-distributed environments.

Unlike traditional software composition analysis tools that rely on source code, build artifacts, or SBOMs, this approach operates on TPNs as a primary data source. It enables the extraction, classification, and interpretation of software components and license obligations from highly unstructured documents.

The key contribution of this work is the demonstration that TPNs can be operationalized into actionable security intelligence for:

  • Vulnerability exposure identification when SBOMs are unavailable
  • Third-party risk assessment using externally visible artifacts
  • Incident response prioritization based on inferred component usage
  • Governance and compliance enforcement through structured outputs

Breaking the Logjam: Toward Automated License Intelligence

To address this systemic gap, I developed an automated end-to-end framework that treats TPNs as primary compliance artifacts, rather than secondary documentation.

The approach enables structured extraction and interpretation of license intelligence directly from unstructured documents. While TPNs may lack some information, they still provide valuable signals. For example, even without version identifiers, knowing that a product includes a component can be very valuable (e.g., when asking “which products contain a version of log4j that might be vulnerable to this attack?”).

Structured Extraction from Unstructured PDFs

Using normalization, segmentation, and page-level reconstruction, the system identifies and extracts coherent license blocks even from highly inconsistent documents.

License Identification and Classification

A hybrid approach combining rule-based methods and fuzzy matching maps extracted text into meaningful license categories:

  • Permissive
  • Weak copyleft
  • Strong copyleft
  • Proprietary
  • Public domain
  • Content licenses
  • Unknown

This approach achieves, in my testing:

  • 92–96% accuracy for permissive licenses
  • 85–90% accuracy for copyleft detection

Risk Interpretation

Each component is evaluated for compliance risk based on obligations such as:

  • Attribution requirements
  • Redistribution conditions
  • Copyleft scope
  • Source disclosure obligations
  • Ambiguous or unidentified licenses

Visualization and Machine-Readable Outputs

The framework produces:

  • Interactive dashboards
  • Structured datasets
  • Outputs compatible with governance workflows and SBOM pipelines

This demonstrates that meaningful compliance intelligence can be derived even from the most constrained artifact available. This closes a long-standing visibility gap in the software supply chain.

Security Implications of TPN Breakdown

The failure of TPNs is not only a compliance problem—it has direct consequences for software supply chain security. When TPNs are inconsistent, unstructured, or incomplete, they reduce the ability of downstream stakeholders to:

  • Identify exposure to known vulnerable components
  • Trace dependency relationships in third-party software
  • Perform accurate third-party risk assessments
  • Respond quickly to emerging vulnerabilities in production systems

This makes TPN degradation a security visibility problem, not just a documentation inefficiency.

What the Ecosystem Needs Next

TPN failures are not isolated inefficiencies. They represent a structural weakness in how the global software supply chain communicates compliance.

Addressing this requires coordinated effort across standards, tooling, and ecosystem alignment.

Standardized, Machine-Readable TPN Formats

The ecosystem needs formats beyond PDFs, such as:

  • Creating a standard TPN-JSON format for use
  • SPDX-aligned TPN profiles

These would enable structured, interoperable compliance disclosures.

One possible longer-term solution is to embed machine-readable data (such as an SBOM in SPDX format or a TPN in JSON format) within the PDFs, creating a “hybrid PDF”. The PDF format already permits adding internal files (called “attached files”). LibreOffice already supports generating PDFs that embed the source document, allowing people to use their existing process for exchanging display PDF while also including machine-readable data. Tools that can quickly extract those embedded files and complain when they’re not present could speed their deployment. However, while this approach has promise, it doesn’t deal with the current documents, which do not embed this information.

Improved Support for Dependency Analysis

Unsurprisingly, many improvements for handling dependencies could help in processing TPNs, SBOMs, and many other related formats.

It would be better if there was shared reference corpora for license matching. That’s because accurate license detection requires:

  • Canonical license datasets
  • Variant and legacy license mappings
  • Community-maintained reference corpora

This would significantly improve consistency across tools and organizations.

In addition, there should be open APIs for information on licensing. Standard APIs should support:

  • License extraction
  • Component-to-license mapping
  • Obligation and risk interpretation

This would enable interoperability between vendors, auditors, and regulators.

Integration Between SBOM and TPN Pipelines

Today, SBOMs and TPNs exist in disconnected workflows. Yet in many cases, TPNs provide the only information available about product components.

A unified pipeline would:

  • Eliminate duplication
  • Reduce inconsistencies
  • Ensure alignment between internal and external disclosures

Related Work

Prior efforts across the software supply chain ecosystem have focused on improving license detection and SBOM generation during development and build phases. However, these approaches often assume access to source code or structured metadata, leaving a visibility gap when Third‑Party Notices (TPNs) are the only available compliance artifact.

Related work on automating TPN analysis demonstrates how unstructured compliance documents can be transformed into machine‑readable license intelligence suitable for governance and audit workflows. Supporting datasets for compliance governance and SBOM alignment are described in:

Datta, D., **TPN Compliance Dataset for Software Supply Chain Governance**, Zenodo, 2025. 

https://doi.org/10.5281/zenodo.19152619

Framework:

https://doi.org/10.5281/zenodo.19099831

Security Workflow Integration Model

The proposed framework reframes TPNs as an input layer in modern software supply chain security workflows. Rather than treating TPNs as static compliance documentation, they can be operationalized into structured security intelligence pipelines.

The extracted data can be integrated into:

  • Vulnerability management systems (to identify exposed components when SBOMs are missing)
  • Third-party risk management (TPRM) platforms (to assess supplier software risk)
  • Incident response workflows (to rapidly evaluate exposure after CVE disclosures)
  • DevSecOps pipelines (to enforce policy-based controls on software composition)

This positions TPN analysis as a bridge between compliance documentation and operational security decision-making.

Conclusion: The Future Requires Fixing TPNs

Third-party notices (TPNs) were originally designed as simple attribution mechanisms and ways to declare licenses to recipients (as required by many licenses). Today, they are expected to support audits, transparency, regulatory compliance, and supply chain security.

But they are still delivered as static documents that do not scale.

TPNs are not failing because organizations lack intent; they are failing because the ecosystem has outgrown the tools and formats upon which it relies.

If we want a more transparent, auditable, and trustworthy software supply chain, TPNs must evolve into structured, machine-readable, and interoperable artifacts.

The next phase of open source security will not be defined solely by SBOMs or scanning tools, but by how effectively we solve the last mile of compliance visibility.

Fixing TPNs is an important step toward a more reliable and verifiable software ecosystem.

 

Acknowledgments

The author acknowledges David A. Wheeler and Sally Cooper for their insightful feedback and helpful discussions during the development of this work.

Resources

The open source implementation of the prototype described in this post, including parsing logic, license-classification rules, and the interactive dashboard, is available on GitHub for anyone interested in exploring or extending the approach:

https://github.com/devashridatta-dotcom/tpn-automation

Community feedback and contributions are welcome.

Author Bio

Devashri Datta is an AI & Software Supply Chain Security Researcher. Security researcher and enterprise security architect focused on software supply chain security, DevSecOps automation, and security governance at scale. Research areas include SBOM governance, vulnerability intelligence (VEX), Third-Party Notice (TPN) analysis, AI-assisted risk modeling, and security exception management in cloud-native environments under compliance frameworks such as SOC 2, ISO 27001, and FedRAMP.