devopsy.kinsta.cloud

Tag: OpenSSF

OpenSSF’s CRob: ‘The Runway Is Rapidly Running Out’ on EU CRA Readiness

The EU’s Cyber Resilience Act kicks into high gear this September, and companies are still clueless about how they must obey its strictures.

MINNEAPOLIS — At Open Source Summit North America, Christopher “CRob” Robinson, Chief Security Architect for the Open Source Software Foundation (OpenSSF), spoke about the European Union’s (EU) Cyber Resilience Act (CRA). CRob warned that companies are still “running straight at that wall” as the first CRA enforcement date draws ever closer.

The CRA, for those who don’t know it, sets mandatory cybersecurity rules for nearly all “products with digital elements,” which means hardware and software, sold on the EU market, with most obligations falling on manufacturers but some also on importers and distributors. That means if you sell pretty much anything in the EU, you must include a security risk assessment; design them with secure default configurations and the ability to restore to a secure state; eliminate known exploitable vulnerabilities; and provide and deploy security updates. If you don’t, the EU will sock you with fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Scary stuff, right? You’d think companies would be working their fingers to the bone getting their goods ready for the post-CRA market. You’d be wrong.

“It’s wild,” CRob said. “We did a report last year… and we’re doing the sequel. And people still are not aware of what they need to do and are not prepared, but the runway is rapidly running out.”

How bad is it? CRob said, “62% of people in Europe were unaware of what they needed to do last year. This year it’s 66%, which is statistically the same.”

It’s even worse outside Europe. In a blog post, CRob pointed out that “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.”

The Linux Foundation and partners had expected their second CRA readiness survey to show clear progress after a year of talks and guidance aimed directly at manufacturers and developers. Instead, the tech business remains oblivious.

“The TL;DR is we and other groups within the industry have been working on this very hard for a year, and we thought we had done a better job of getting in the rooms where the manufacturers or developers are,” CRob said. “We had expected that the second iteration of the report was going to be amazing… but the results are very middling.”

Looking ahead, the Linux Foundation is taking its message to Brussels, the de facto EU capital, in June. There, “we’re going to talk with the European Commission and ENISA.” In addition, Linux Foundation Europe will host a European policy day on June 8, followed by a June 9 event focused “purely on cyber security, mostly the CRA,” but Robinson expects the AI Act will also be on the agenda. In short, ” people need to wake up.”

Robinson argues that CRA compliance cannot be delegated to technical teams alone and says senior executives are not yet sufficiently engaged. “It’s an urgent wake‑up call, that’s for damn sure,” he added, “You need the C-suite, and it needs to get involved. This can only happen from the top down, and they’re just not going to pay attention to the open-source conferences.”

Beyond awareness, Robinson says many companies are making structurally bad bets about how to meet CRA obligations around vulnerability management and updates. In a separate Linux Foundation economics study on ROI for Open Source Software Contribution, he cites “a little over half” of organizations reporting that they “passively wait for upstream to do something before they react.”

“With the CRA, Robinson continued, “that’s like a really bad move because the upstream doesn’t have the deadlines and the fines,” he said. “They’ll try to work as quickly as they can, but… they’re not going to be yelled at or threatened to work any faster.”

Others respond by forking open source code and maintaining private branches: “They’ll do private forks, where they’ll have a private copy, they might do their own patches and not contribute that upstream,” Robinson said. “That was like over almost $260,000 of either expense or engineering labor for each product release by those organizations, that’s the technical bet they’re taking.” He argues that those numbers should “wake up the C-suite,” given the number of releases many vendors cut each year.

For large organizations (5,000+ employees), CRob added, “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.”

Robinson also links CRA readiness to the rapid adoption of AI in software security, which he says will massively increase the volume of fixes vendors must handle. “It’s an explosion of AI. I see it in three tiers right now.”

At the top are upstream maintainers, who he expects will “figure a way to manage this” by automating and leveraging new tools, but who will also generate “exponentially more patches every day.” The second tier consists of manufacturers “on the hook for things like the CRA,” who must “retool internal processes that have existed for decades… very conservative, very brittle, slow processes.”

The third, and in his view least prepared, group is downstream enterprises such as “a bank, or a hospital, or whatever.” “All these people… are totally unprepared for thousands of fixes hitting their inbox,” Robinson warned, adding that bad actors will inevitably weaponize AI‑driven vulnerabilities and exploits. He asked, “How do we prepare purely downstream consumers to be able to take these patches, deploy them quickly, so that they aren’t… a victim to some attack?”

That’s a good question, and for now, there are no good answers. Companies will soon have no choice but to figure it out. All the hysteria about how bad Y2K was going to be turned out to be so much hype because the hard work had already been done. When it comes to the CRA, however, far too few companies have done their homework.

May 20, 2026
Open Letter Calls for Fundamental Change to Open Source Economics

Leading stewards of several major open source projects today issued a joint open letter calling for major changes to be made to the way the IT infrastructure used to support these initiatives is funded, operated and maintained.

Posted on the Open Source Security Foundation (OpenSSF) website, the open letter signed by representatives from open source projects such as Maven Central/Sonatype, OpenJS, The Python Software Foundation and The Rust Foundation called for fundamental reforms to be made in terms of both how IT infrastructure is funded and the way open source software is being consumed.

At the core of the issue is vendors and non-profit entities that launched and support these projects are shouldering the cost of maintaining the underlying IT infrastructure required to support package repositories and managers with no way to recoup that investment.

Specifically, the open letter identifies automated continuous integration (CI) platforms, large-scale dependency scanners, and ephemeral container builds as IT tools and platforms that are putting an enormous strain on infrastructure. These commercial-scale workloads often run without caching, throttling, or even awareness of the strain they impose. The rise of generative and agentic artificial intelligence (AI) coding tools is only going to drive a further explosion of wasteful automated usage that compounds those existing challenges, according to the signers of the letter.

As a result, the letter notes “a small number of organizations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users, including commercial entities that extract economic value, consume these services without contributing to their sustainability.”

Rectifying the economic imbalance will require commercial and institutional partnerships that help fund infrastructure in ways that are aligned to usage and/or adoption of tiered access models through which fees might be charged for organizations that consume large amounts of IT infrastructure resources.

According to the letter, the maintainers of open source projects might also attempt to monetize analytics, such as usage statistics, in ways other providers of service might value.

Sonatype CTO Brian Fox said hopefully as more enterprise IT organizations as they become aware of the cost issues will adopt best practices, such as caching, that reduce the load on IT infrastructure by cutting the number of downloads but even then there is still going to be a chronic need for additional funding.

Mike Milinkovich, executive director of the Eclipse Foundation, added that while cloud service providers have been in many cases subsidizing the funding of IT infrastructure, the business model is fundamentally broken. The open letter is the first step toward raising awareness of an issue that will eventually need to be addressed, for example, by throttling and rate limiting to moderate usage of package managers that were never supposed to become critical elements of a software development process.

It’s not precisely clear how much is being spent on IT infrastructure to support these projects but costs are in the tens of millions with no sign of abatement. In effect, open source projects are becoming economic victims of their own success. The issue now is determining how best to fund these projects in a way that is economically sustainable both now and, just as importantly, in the forthcoming era of AI.

September 23, 2025
OpenSSF Siren: Security for One, Security for All
It’s getting harder by the day to ensure your programs are safe. We used to count on the National Institute of Standards and Technology (NIST) Common Vulnerabilities and Exposures (CVEs), but NIST has almost completely stopped adding analysis to the CVEs. Plus, as CEO and co-founder of coding security company Chainguard Dan Lorenc pointed out, the CVEs themselves are drowning under a flood of bad CVEs, created by AI bots seeking security credibility for their authors. What’s a DevOps pro to do?

The Open Source Security Foundation (OpenSSF) has an answer: Siren, a threat intelligence sharing list.

Security mailing lists, such as oss-security, are nothing new. The OpenSSF is well aware of these. Indeed, it supports them.

Individual lists for particular problems are well and good. However, these days, as most of you know to your pain and sorrow, security issues seldom concern one specific program. They can spring from combinations of operating systems and programs.

The open source community has proven methods of communicating vulnerabilities to others within the community. However, developers don’t have a way to efficiently communicate information about exploits with the broader downstream audience. While consumers and enterprises may have intelligence-sharing structures in place, this does not always extend to the upstream open source community. OpenSSF Siren seeks to bridge these gaps.

As the OpenSSF states, Siren is meant to provide “a secure and transparent environment for sharing Tactics, Techniques, and Procedures (TTPs) and Indicators of Compromise (IOCs) associated with recent cyber attacks. Siren is intended to be a post-disclosure means of keeping the community informed of threats and activities after the initial sharing and coordination.”

So, Siren is the wrong place if you’re looking for information about zero-day security holes before they are disclosed. This isn’t for sharing security problems and answers once they are disclosed and, we hope, fixed.

Since open source powers up to 90% of modern software, the importance of this can’t be understated. Recent attacks on projects like XZ-Utils are stark reminders of the importance of proactive security measures.

Specifically, Siren brings you:
- Open source threat intelligence: Information is shared with the community about actively exploited public vulnerabilities and threats.
- Real-time updates: List members receive email notifications about emerging threats relevant to their projects. This gives you an opportunity to take action to mitigate risks swiftly.
- Adherence to CLEAR guidelines: To facilitate effective, unrestricted, transparent communication, the list follows the Traffic Light Protocol (TLP) CLEAR guidelines for the sharing and handling of intelligence. TLP is a simple color-coded system that designates how far the information should be shared. Red, for example, means the information should only be shared by people actively working on a security problem, while green means the security news should be restricted to the community.
- Community-driven resources: Contributors from diverse backgrounds collaborate to enrich the intelligence database, fostering a culture of shared responsibility and collective defense.
By leveraging the collective knowledge and expertise of the open-source community and other security experts, the OpenSSF Siren hopes to empower projects of all sizes to bolster their cybersecurity defenses and increase their overall awareness of malicious activities.

Ready to act? You can register for an OpenSSF Siren membership to receive real-time threat intelligence updates and talk about these issues. I hope to see you there. Together, we can make the world a little bit more secure for you, me, and everyone else.

Photo credit: Jan Antonin Kolar on Unsplash
May 21, 2024
OpenSSF warns of Open Source Social Engineering Threats

Linux dodged a bullet. If the XZ exploit had gone undiscovered for only a few more weeks, millions of Linux systems would have been compromised with a backdoor.

We were lucky. But can we stay lucky?

The Open Source Security Foundation (OpenSF) and the OpenJS Foundation revealed that a similar hackling attempt had targeted several JavaScript programs.

Just as with XZ Utils, a few people wanted OpenJS to designate them as new project maintainers despite having little prior involvement. They “implored OpenJS to take action to update one of its popular JavaScript projects to address any critical vulnerabilities, yet cited no specifics,” wrote Robin Bender Ginn, OpenJS executive director, and Omkhar Arasaratnam, Open SSF general manager.

Well, that was never going to happen.

Jia Tan, the mysterious hacker who became a top XZ programmer and maintainer, before inserting a backdoor in the code, had spent years establishing his project credibility before making his move.

Still, warned Ginn and Arasaratnam, we’ll see more of these kinds of social engineering attacks. In such instances, the friendly attacker seeks to exploit “the sense of duty that maintainers have with their project and community in order to manipulate them.”

Specifically, these security leaders warn against pull requests containing blobs as artifacts. For example, they point out that the XZ backdoor included a cleverly crafted file in the test suite that wasn’t human-readable.

Dubious source code may also be intentionally obfuscated or difficult to understand. For example, the XZ issue started with a relatively innocuous replacement of safe_fprintf() with fprintf() to see if anyone would notice. No one did.

The question now is: Are such attacks already ongoing? Or, far worse, have they already been made, and they weren’t spotted? Chris Hughes, chief security advisor at Endor Labs, told me, he “suspects that many of these are already underway and may have already been successful but haven’t been exposed or identified yet.”

How? Hughes explained, “Most open source projects are incredibly underfunded and run by a single or small group of maintainers, so utilizing social engineering attacks on them isn’t surprising, and given the pressures maintainers are under, they will likely welcome the help. If done well by the attackers, it may be difficult for the maintainers to determine which involvement is from those interested in collaborating and contributing to projects versus those with malicious intent.”

He’s not wrong.

As Jim Zemlin, the Linux Foundation‘s executive director, said at the Open Source Summit North America in Seattle, we’ve been making progress with security. But “trust is something we need to talk more about,” he added. We need to answer the question: “Who writes all this software? This is different from a security question. Security is ‘Is there a vulnerability?’ Who is more of a trust question? Do we trust this identity? Enough to give them a maintainer role?”

Bad news, folks. Zemlin admitted we don’t have a good solution to this problem.

Indeed, we’ve seen such attempts before. In 2021, for example, researchers at the University of Minnesota tried to insert vulnerabilities in the Linux kernel to see if it could be done. Spoiler alert: They failed, and they were banned from the Linux kernel.

But don’t get comfortable. The Linux kernel has a large team of passionate, brilliant maintainers. Few projects are so lucky.

Dan Lorenc, founder and CEO of the security company Chainguard, put it well. “Projects get stale, maintainership changes, and there are a lot of considerations to keep in mind when granting someone new commit access to a critical project. There’s no single right way to do this, but cataloging best practices with the community would go a long way to helping prevent this in the future.”

What are the trust best practices? We honestly don’t know yet. But, if we’re to trust our open source projects, we must figure it out.

April 17, 2024
Summit Highlights Open Source Software Security Progress

More than a year after the Open Source Security Foundation (OpenSSF) summit kicked off an initiative to better secure open source software-based software supply chains, a lot of progress has been made—but much work remains to be done.

The OpenSSF this week hosted a Secure Open Source Software (SOSS) Summit 2023 event in Washington, D.C., during which it made available a Secure Open Source Software Vision Brief 2023. The brief describes the various efforts being made to improve open source software security, including, for example, providing maintainers of open source software projects with free DevSecOps tools.

This week, the Cybersecurity and Infrastructure Security Agency (CISA) also published an Open Source Software Security Roadmap that defines its role in providing more visibility into how open source is being used and the associated risks.

However, it’s not clear how much maintainers of these projects are embracing DevSecOps workflows. Many projects are led by a handful of maintainers that often lack the time and skills required to ensure the components they employ have not, for example, been compromised by malware that might find its way into downstream applications.

Sonatype CTO Brian Fox said the focus of the summit’s participants will be on education and securing public code repositories. While there is a lot of focus on maintainers, he added that there is not enough attention to all the organizations that have not updated open source components within a software build with known vulnerabilities. Many IT teams are reluctant to upgrade components for fear of breaking applications with complex dependencies, but the amount of code that is potentially insecure is massive. “There’s a huge mountain to climb,” he said.

The challenge is determining which code to upgrade first in a way that will have the most impact in terms of improving application security, added Fox.

Shawn Ahmed, chief product officer for CloudBees, also noted that organizations should evaluate the DevSecOps processes being applied by maintainers of open source software projects. CloudBees, for example, reviews the plugins provided by the open source community for the Jenkins continuous integration/continuous delivery (CI/CD) platform for vulnerabilities every month, he noted.

It’s also critical for organizations that consume open source software to contribute code to improve the security of open source software, added Ahmed. Too many organizations are focused on open source software security without devoting resources that would help resolve the issue. he added. “We need to make sure open source software is not a vulnerability threat,” said Ahmed.

Moran Ashkenazi, chief strategy officer (CSO) and vice president of security engineering for JFrog, said on the plus side, there is a lot more awareness of open source software security issues since the disclosure of a zero-day vulnerability in the Log4j shell tool widely used to manage logs in Java applications. But added that this issue is not going to be resolved overnight. “That was a wakeup call,” she said.

Tapabrata Pal, vice president of architecture for Fidelity Investments, noted that the fundamental problem is that cybercriminals have become more adept at injecting malware into software supply chains, so no one knows whether their application environments might be compromised. “It’s a serious issue,” he said.

It’s not known whether the open source software that many developers routinely incorporate into their applications might contain vulnerabilities that could be exploited, but the level of technical debt that has accrued over the last several decades is considerable. The issue is finding a way to address it without becoming overwhelmed by the enormity of the task.

September 14, 2023
Sigstore Code Signing Service Becomes Generally Available

A free digital signing service for software created by the Sigstore open source community has become generally available this week via the cloud.

Announced at the SigstoreCon event that occurred during the KubeCon + CloudNativeCon North America conference, the cloud service makes it possible for developers to both cryptographically sign artifacts and verify that the components used to build applications are secure.

The Sigstore community operates under the auspices of the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation. Sigstore project sponsors, including Google, Red Hat, GitHub and Chainguard, have committed to operating a service with a 99.5% uptime and round-the-clock pager support. More than 70 organizations, including Shopify, Autodesk, Trail of Bits and Rancher Government Solutions are actively involved in maintaining and scaling Sigstore.

More the four million Sigstore signatures have been logged using Sigstore thanks mainly to Sigstore support that is already included by maintainers of open source Kubernetes and Python projects. The npm community also announced it is working to integrate Sigstore in all packages used to build JavaScript applications.

Bob Callaway, co-founder of Sigstore and technical lead and manager for the Open Source Security Team at Google, said this service will make it much simpler for developers to add digital signatures to code in a way that can be more easily verified within a software bill of materials (SBOM).

The goal now is to expand the number of open source projects that will commit to employing Sigstore to better secure software supply chains, he added.

The security of open source software became a major concern in the wake of the open source Log4j zero-day vulnerability. Sigstore was under development prior to that disclosure, but the Biden administration’s executive order requiring Federal agencies to verify the security of open source software has enabled the availability of more resources for the project.

In response to the executive order, the OpenSSF outlined a 10-point plan to secure open source software that would require more than $150 million in funding. One of those goals is to have 50 of the top 200 projects and 1,000 of the top 10,000 projects adopt an interoperable approach to software signing. That project was estimated to cost $13 million for the first year and $4 million per year beyond, with a one-time additional $10 million required after the first year.

It’s not clear how broadly developers will employ digital signatures, but given the current level of concern, it’s probable most organizations will soon require any code they use to be digitally signed so it can be verified as immutable. The next big challenge, of course, is finding a way to operationalize the collection of all the SBOMs that will include those signatures. After all, SBOMs are only the first step in a larger DevSecOps workflow that will enable organizations to accept or reject software components based on all the data being collected.

October 27, 2022
Rust Foundation Allies With OpenSSF and JFrog to Secure Code

The Rust Foundation announced today it is working with the Open Source Security Foundation (OpenSSF) and JFrog to help maintainers secure open source software created using the Rust programming language.

Rebecca (Bec) Rumbul, executive director at the Rust Foundation, said even though Rust is a memory-safe language, there are still security issues that maintainers need to be able to address. The goal is to provide the resources those maintainers need to better secure their software supply chains.

As part of that effort, the Rust Foundation is adding a dedicated security team to help maintainers of open source projects built using Rust to better secure their software supply chains. That team is being underwritten by JFrog and the Alpha-Omega Initiative funded by Google and Microsoft which was recently launched by OpenSSF. JFrog last week announced it is joining the Rust Foundation at the Platinum level alongside Amazon Web Services (AWS), Google, Huawei, Meta, Microsoft and Mozilla.

The first initiative for the security team will be to conduct a security audit and develop threat modeling tools that will provide the foundation for a set of best security practices for maintainers, said Rumbul. The team will also help advocate for those security practices across the Rust landscape, including the Cargo package manager and Crates.io directory projects.

The OpenSSF has previously called for replacing programming languages like Java that are not memory-safe as part of a larger plan to secure open source software supply chains.

In general, the Rust Foundation is committed to enabling Rust developers to achieve their scale, security and sustainability goals, said Rumbul. Given the early stages of the Rust programming language, there is no better time to start addressing security issues that application developers can’t ignore, she added.

In the longer term, The Rust Foundation is also committed to providing developers with Rust security education and is also working to come up with a fair approach to certifying which projects have achieved an appropriate level of cybersecurity maturity, said Rumbul.

It’s not clear whether developers are abandoning older programming languages in favor of a memory-safe language such as Rust. Rust employs a compiler to track the ownership of values that can be used once and a borrow checker that manages how data is used without having to rely on traditional garbage collection techniques.

Of course, replacing trillions of lines of code that have already been constructed using a variety of legacy languages is a gargantuan task that might never be fully completed. However, as new applications are built using a memory-safe programming language, the overall security posture of an organization will steadily improve. The challenge, of course, is that the number of developers that know how to build applications using those languages is still relatively small.

Nevertheless, there may come a day when the way applications are coded is a lot more secure by default than it is today. In the meantime, however, the number of vulnerabilities that exist with application environments is still too numerous to count.

September 13, 2022
Survey Uncovers Depth of Open Source Software Insecurity

A survey from Snyk and the Linux Foundation published today found that less than half of respondents (49%) work for organizations that have security policies in place for the use or development of open source software.

The survey, which polled 550 software development professionals, was conducted by Snyk, a provider of tools for securing software, and the Linux Foundation. Just under a third (30%) of respondents without any policies in place also admitted that no one on their team is currently directly addressing open source security. A total of 41% said they didn’t have high confidence in their open source software security. Nevertheless, 59% of respondents said the open source software they deployed is somewhat or highly secure.

Matt Jarvis, director of developer relations for Snyk, said many organizations are not aware of the degree to which open source software is now being targeted by cybercriminals looking to surreptitiously insert malware into widely used software projects. Those same organizations also lacked clarity about how open source software is constructed, he added.

In many ways, the open source software community has now become a victim of its own success, noted Jarvis.

Overall, the survey found the average application development project has 49 vulnerabilities and 80 direct dependencies on open source software. Only 18% of respondents said they are confident of the controls they have in place for their transitive dependencies. A full 40% of all vulnerabilities discovered were found in transitive dependencies.

Only a third of respondents (33%) are using static application security testing (SAST) tools within a continuous integration process or software composition analysis (SCA) tools to discover those vulnerabilities, according to the survey. Overall, 44% reported they use some type of tool to analyze source code.

In terms of additional capabilities, 59% said they would like to see more intelligence added to these tools, while 52% cited a need for more clearly defined cybersecurity best practices. Nearly half (49%) also wanted increased automation and tools for conducting security audits.

The survey also found that fixing vulnerabilities in open source projects takes 19% longer than in proprietary projects.
Among organizations that do have security policies in place, 80% vested responsibility with the security team. Only 40% of organizations without such policies did the same, according to the survey.

The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. Developers today routinely reuse open source software. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure the projects and software are secure is on the organizations that decide to deploy that software.

Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities. Hopefully, following an executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead.

June 21, 2022
OpenSSF Adds Open Source Package Analysis Tool Prototype

The Open Source Security Foundation (OpenSSF) has made available a prototype of a package analysis tool that has already identified more than 200 malicious packages uploaded to PyPI and npm software components.

Caleb Brown, an OpenSSF maintainer of the project, said the goal is to understand the behavior and capabilities of packages available on open source repositories. It also tracks how packages behave over time to make it easier to identify when previously safe software began to act in a suspicious manner.

Most of the malicious packages detected are employing dependency confusion and typosquatting techniques, Brown said. They usually contain a simple script that runs during installation and provides a few details about the host to an external command-and-control system. Most of these packages are not exfiltrating meaningful data except the name of the machine or a username, but they make no attempt to disguise their behavior. The issue is that any one of these packages could have done far more damage, noted Brown.

Future goals for the project include detecting differences in package behavior over time; automating the processing of the package analysis results; storing the packages themselves as they are processed for long-term analysis and improving the reliability of the pipeline. As such, the OpenSSF is looking for application developers and cybersecurity researchers to contribute to the project. The expectation is that many providers of application security tools will incorporate the package analysis tool within their offerings rather than requiring each vendor to create their own version of the same tool, said Brown.

The OpenSSF has launched a series of initiatives to improve the overall state of open source security. Most recently, it added an Alpha-Omega Project to automate security testing processes for open source software using a $5 million initial investment provided by Microsoft and Google. The core challenge is that many organizations are dependent on open source software projects created and maintained by just a handful of volunteer maintainers and contributors. The individuals that created those projects don’t always have a lot of cybersecurity expertise. In fact, many of them would argue that the onus for securing open source software is on the organizations that use what amounts to free software. It’s not the responsibility of the contributors and maintainers to, for example, drop everything and immediately create a patch to address a zero-day vulnerability.

It’s not clear how easily open source software could be compromised by cybercriminals that insert malware into downstream applications that rely on that code. However, in the wake of a series of high-profile breaches, it’s safe to assume that more cybercriminals than ever are trying to compromise open source software projects. While some organizations may opt to limit their dependency on open source code that has not been properly vetted, there is no way to entirely avoid using open source code. The challenge is finding a more efficient way to ensure the integrity of that code for all concerned.

May 9, 2022
Checkmarx Finds Malicious Open Source PyPi Repository

Checkmarx, a provider of a platform for testing application security, this week disclosed it has discovered a malicious instance of a PyPi repository for Python code that has been downloaded more than 70,000 times.

Tzachi Zorenshtain, head of supply chain security, said this discovery represents another instance where cybercriminals have made available a malicious copy of a popular open source software package that contains malware that is destined to find its way into downstream applications. Cybercriminals, via a tactic known as starjacking, create a web page that includes bogus statistics, such as GitHub stars, to make it appear a software package that a developer might download is from a legitimate open source project, he noted.

Cybercriminals are combining starjacking with typosquatting to set up web pages to mimic a legitimate open source project, noted Zorenshtain.

Starjacking represents yet another effort to compromise the integrity of software supply chains that rely on a wide range of open source software components to build applications. The only way to thwart starjacking is for either developers or DevOps teams to validate components before incorporating them within applications, noted Zorenshtain. Otherwise, it’s possible malware will only be discovered after it has already found its way into downstream applications deployed in a production environment.

The challenge, of course, is remembering to take the time to validate the source of any software component. Developers that are typically trying to build applications as fast as possible don’t always stop to make sure that all the components they are employing are from a legitimate source.

It’s not clear how pervasive fake sites through which developers are encouraged to download malicious software have come to be. However, as cybercriminals expand their efforts to compromise software supply chains, it’s clear their tactics are evolving in ways that exploit the trust developers have in open source software. It’s not likely these attacks will disrupt the open source ecosystem, but they do add additional urgency to make open source software more secure.

The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised more than $10 million to build tools and define best practices for securing open source software projects. Google has pledged to ultimately spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software that is widely employed both inside and out of government agencies a priority by expanding compliance mandates. The White House is also clearly trying to pressure IT vendors and larger enterprises to contribute more to the effort to secure open source software.

The trouble is many open source projects are maintained by a small number of programmers that contribute their time and effort to building components that others are free to use. Many of them argue the onus for making sure that software is secure is on the organizations that decide to deploy that software. Nor is their responsibility to track down cybercrimimals that employ Typosquatting techniques to distribute malicious versions of their software.

Many of the IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or just helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are now also assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may now be only a matter of time before a long-simmering open source software security issue erupts into a major crisis of confidence.

April 20, 2022