devopsy.kinsta.cloud

Tag: open source software

Open Source Code Just as Secure as Proprietary Software—If You Manage It Right, Says CISA
Open source can be just as safe as proprietary software, though government agencies (and private enterprises) should take additional measures to secure it properly, according to a new guide published by the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

The report, “Open Source Software: Security Principles and Practices,” provides with guidance to help agencies comply with two Presidential Executive Orders (14144 and 14306) which both urged them to do a more thorough job securing the software they use, a response to recent exploits like Log4Shell and XZ utils.

CISA acknowledges that open source can provide immeasurable benefits to government agencies, not merely because it is available without licensing fees, but also because agencies can extend the software to meet their own requirements. But at the same time, open source software must be managed differently than proprietary software.

Malicious hackers (and increasingly AI agents) use vulnerabilities to gain entry and exploit systems. In the case of the vendor software, it is the vendor’s responsibility to provide timely updates should a software vulnerability be found, which agencies should apply as soon as possible.

With open source software, however, agencies need to take a more proactive role in patching and understand the dependencies, or additional software components, that an open source package relies on. Those components also need to be secured, the guidance advises.

The guidance describes established principles for patching. It also provides a framework to evaluate trustworthiness and risk tolerance of software packages, as well as a set of best practices to procure, deploy and maintain open source software.

In practical terms, agencies wishing to use open source should establish a process that supports staff in choosing the software that meets the agency’s needs but minimizes risks to the agency.

For instance, an agency’s Office of the Chief Information Officer may set up a system to pre-approve certain software libraries for use in the agency. Automated tools could help verify safe software packages, and reviews would consider potential risk exposure. The CIO could still individually sign off on higher-risk components, such as operating systems.

To help agencies, CISA produced the C4 Framework, which can be used to assess the trustworthiness of a software package. It looks at four factors (the four Cs):
- Codebase: Take a look at the actual source code and dependencies that make up the software component of interest. How recently was the last update committed? How many vulnerabilities have been found? How many out-of-date dependencies does it rely on?
- Community: How robust is the community that maintains and contributes to the project? Is it part of a foundation, or managed by a private company?
- Conduct: How is the project managed? Is there a vulnerability disclosure process? Do the project leaders follow their own code of conduct?
- Configuration: Is the default configuration secure? Are there guides for use in highly-sensitive environments?
Open source AI systems should go through additional checks, CISA recommends. Agents should get sufficient transparency into the training data, in addition to the software itself. “Only with transparency and access can agencies understand and study the software, analyze it for vulnerabilities, and remediate any found vulnerabilities or risks,” the guide recommends.

CISA has targeted this report to U.S. federal agencies, though the advice here is rock-solid for use in the industrial sector as well. Many businesses in finance and health care, for instance, routinely follow government guidance. So if your organization uses open source in any capacity, this report may be worth checking out.
July 31, 2026
HeroDevs Allies with Commonhaus Foundation to Support Open Source Software

HeroDevs this week revealed it has joined the Commonhaus Foundation as the founding member of the Open Source Sustainability Initiative (OSSI) after establishing partnerships with the open source Hibernate, Jackson, and Quarkus communities to provide commercial support for older versions of these frameworks.

OSSI is a framework administered by the Commonhaus Foundation through which governance of open source software projects is provided.

HeroDevs COO Rob Nalen said the provider of end-of-life support services for open source software sees a clear need to work more closely with maintainers of open source projects that don’t have the resources required to support enterprise IT organizations that for one reason or another are not able to upgrade to the latest version of an open source software framework in a timely manner.

The alliance between HeroDevs and the Commonhaus Foundation, in effect, buys enterprise IT teams, especially if they operate in highly regulated industries, the time they need to eventually make that transition, he added. Over time, HeroDevs also plans to extend the level of support it provides across the other projects that are governed by the Commonhaus Foundation, noted Nalen.

Enterprise IT organizations have for many years now included massive amounts of open source software in their applications. The average enterprise application today has 911 open source components, said Nalen. Unfortunately, they now face a significant dilemma in the age of artificial intelligence (AI). The latest generation of frontier AI models are now able to discover thousands of vulnerabilities in legacy software that, if exploited, could wreak havoc.

The challenge is that once those vulnerabilities are publicly disclosed, it’s also been shown that malicious actors can use AI tools to reverse engineer an exploit in a few hours.

In some cases, DevOps teams might decide to use an AI coding tool to create custom software of their own that replaces the function they once relied on an open source component to provide for. The issue then becomes the amount of time and effort that will need to be allocated to maintaining those custom components. Alternatively, HeroDevs is making a case for relying on an external service provider to maintain open source software on behalf of enterprises that would rather dedicate their limited resources to building and deploying new applications or adding features to an existing one.

Of course, there may not be a single right answer given the volume of dependencies that exist in applications. The decision to replace a component versus relying on an external service provider to support and maintain it will be heavily influenced by just how critical it is to the business. The one thing that is certain is that even in the age of AI coding, it would take possibly years to replace every single open source component that needs to be maintained and secured.

As such, the real issue is determining what to prioritize given the high probability that any number of applications are about to be compromised in the weeks and months ahead.

June 24, 2026
Can Chainguard Save Open-Source Software From Mythos? Can Anyone?

IBM and Red Hat aren’t the only ones that mean to lock down open-source code against AI hacking tools.

Last week, IBM and Red Hat launched Project Lightwell to protect open-source projects with $5 billion and 20 thousand engineers. Not to be outdone, with tongue in cheek, Chainguard’s CEO Dan Lorenc announced a $50 million, 100‑engineer commitment as an attempt to “build new trust infrastructure for open source consumption.” Why? Because Lorenc argues that open source consumption “is fundamentally broken, and no amount of incremental improvement is going to fix it in time.” I wish I could disagree, but he’s right.

In his blog post, The Hardest Fork, Lorenc warns “Mythos is real,” pushing back on those who dismiss Anthropic’s scary code scanner as hype or a “marketing stunt.” He describes the Mythos findings as “novel combinations of a few dozen issues out of thousands of things every SAST [Static Application Security Testing] scanner already finds, chained together into something much worse.” In short, Mythos is “not a better scanner” but “a different category of threat.”

This means modern AI is ruining coordinated vulnerability disclosure into an at‑scale problem: “A model can now find hundreds overnight in the long tail. The existing system is not going to keep up, and we all need a backup plan for the vulnerabilities that don’t get patched.”

Lorenc argues that the basic way enterprises use open source is unsustainable under AI pressure. He wrote, “The way the world consumes open-source software is fundamentally broken, and no amount of incremental improvement is going to fix it in time.” Open source is “going to have to change.”

After all, he points out that “modern apps are layers of dependencies,” where changing one component can cascade through an entire stack, especially in large organizations with legacy codebases. On the maintainer side, he notes that “some of the most critical software on the internet is maintained by one or two people in their spare time,” and that “automated scanners and AI-generated reports have already been burying them in low-quality noise for years.”

What to do?

Plan A: coordinated disclosure that actually scales

In the near term, Lorenc says the ecosystem needs both “a Plan A and a Plan B.” Plan A is “coordinated disclosure that actually works at scale,” which he defines as “a single, trusted group that routes fully vetted reports and patches upstream, and supports the maintainers who want help.”

That’s all well and good, but who will that be? IBM and Red Hat have certainly thrown their hat into the ring, but do you trust them?

Lorenc is certainly right when he states this can’t be left to “a dozen competing groups filing noisy tickets” and instead needs “one coordinated effort that maintainers recognize and trust, so their reports get bubbled to the top of every inbox.” He cites Project Glasswing’s current performance as a warning sign, writing that “Glasswing has managed to get about 6% of its findings upstreamed” and estimating that “we can get normal coordinated disclosure working, under hard time crunches, for maybe 50% of projects at best.”

Plan B: a “maintainer of last resort.”

For everything that Plan A can’t reach, Lorenc says the ecosystem needs a fallback: “For all of those, and for the projects where maintainers can’t or won’t patch at all, we need a maintainer of last resort.” He anchors this in the traditional FOSS right to fork: “Open source gives you the right to fork. To take a project, assume stewardship, and keep it alive independently.”

What’s different, he argues, is scale: “We’re not talking about forking one project. We’re talking about building the infrastructure to fork, maintain, and distribute thousands of them. Under time pressure, with real adversaries on the other side. That’s the hardest fork any of us has ever had to make.”

That is the role he positions Chainguard as helping to fill, leveraging AI to make this kind of “maintainer of last resort” function viable. In a comment, Lorenc adds, “We’re not going to be the maintainer of last resort, we’re just going to help with it.”

Three futures for open source

Looking further ahead, Lorenc lays out three possible futures he calls “forks in the road”: “The naive one,” “The chaotic one,” and “The hard fork.”

In the naive scenario, he writes, “you do nothing and hope,” and imagines a world where “Glasswing patches everything upstream” and “every maintainer responds to every disclosure within 24 hours” — a world he says plainly, “We do not live in.”

Indeed, we already live in that one, and you may have noticed that not a day goes by that there’s not another new open-source supply chain incident. Just ask Red Hat with its spectacular npm breach. Yes, there is more than a little irony here.

In “the chaotic one,” he warns that “every major cloud provider forks its own versions of critical libraries, each with its own patch sets,” while “three different security vendors ship competing forks of the same logging framework.” That, he says, is “the default if we do nothing.”

I really, really hope that won’t be the case, but I find it all too easy to see it happening. It’s everything that’s wrong about proprietary code with an open-source wrapper.

The third path is “the hard fork: a deliberate, coordinated, painful decision to build new trust infrastructure for open-source consumption, including “one disclosure pipeline that works at scale” and “one trusted place for maintained forks.”

Lorenc closes his essay with a mix of realism and dark humor: “Is any of this actually going to work? I honestly have no idea. But we have to start, and as the Programmer’s Credo says, ‘We do this not because it is easy, but because we thought it would be easy when we started.’ This one doesn’t even feel easy at the start.”

No, no, it doesn’t.

June 2, 2026
Open Source Contribution is About More Than Just Altruism

Open source software is a foundational pillar of modern technology. From operating systems and databases to cloud infrastructure and developer tooling, it is embedded across nearly every layer of the stack. Most organizations rely on it in meaningful ways, often without fully accounting for how central it has become to their ability to build, scale, and operate

And yet, for all its ubiquity, contribution to open source remains uneven. Many organizations still treat open source as something to consume rather than something to participate in. It is pulled into internal systems, adapted, and relied upon, but the relationship often stops there. A new report by the Linux Foundation found that 28% of organizations say they use but do not contribute to open source software at all—that’s over a quarter of all organizations that are not contributing whatsoever. And for those who do, the degree to which they contribute may vary significantly.

Within the open source world, that dynamic is often framed as a matter of responsibility. If you benefit from open source, the thinking goes, you should give back. But that framing only goes so far. There is no requirement to contribute, and for many organizations, there is no immediate penalty for staying on the sidelines.

But there are penalties, even if organizations don’t realize them. Contribution is not some moral gesture, but a practical way to operate more effectively inside the ecosystems your organization already depends on. Seen this way, contributing to open source is less about altruism and more about building resilience, influence, and long-term advantage.

The Economic Case for Contribution

To understand the value of open source software, you simply need to ask, “What would it cost to replace it?” According to the same report by the Linux Foundation, if open source software did not exist, organizations would spend on average $3.5 million per year to build or license proprietary alternatives to achieve the same functionality.

But for those who skimp on contributions, there’s even more value left on the table. Nearly half maintain private forks of open source projects, averaging 86 forks per organization and requiring more than 5,000 hours of labor per release cycle to maintain. Instead of working with the project, companies are working around it, duplicating efforts and carrying unnecessary maintenance burdens forward.

Accordingly, as organizations fork and move downstream, they are falling out of sync with the communities building the software. That results in lost visibility where organizations are spending an average of $670,000 annually building internal workarounds for features or fixes that are not aligned with open source roadmaps. Contributors, by contrast, operate with a clear advantage, receiving at least two months of advance notice on important changes.

And the benefits for contributors simply compound from there. In fact, organizations that contribute report 2x to 5x returns on their investment, alongside tangible operational gains like faster maintainer response times, easier hiring and talent retention, and development speeds that increase by an average of 10%. So while contribution does require some time, attention and occasional spend, the investment results in far more significant returns. Meanwhile, passive consumption often cultivates recurring costs.

The Cost of Staying on the Sidelines

Those numbers point clearly to the issue at hand. When organizations treat open source purely as something to consume, they create distance between themselves and the systems they depend on. They are using the software, but are not part of the conversations that shape its direction.

Roadmaps are evolving without their input, design decisions are debated elsewhere, and important context is living in community discussions they are not part of. Over time, teams find themselves reacting to change instead of influencing it, often discovering shifts only after they have already impacted their own systems.

It also changes how problems get solved. Without engagement, organizations default to solving issues internally, causing knowledge to be siloed and work to be repeated across multiple teams or companies. What could have been a shared solution becomes an isolated effort, increasing complexity without improving the underlying project.

The result is inefficiency, reduced awareness, and limited flexibility. When the software changes, organizations that are disconnected from the community have fewer options. They can adapt, but they cannot easily shape outcomes or anticipate them in advance.

What You Gain by Participating Upstream

Participation changes that dynamic by bringing organizations closer to the source of change. Instead of reacting to decisions, contributors are part of the discussions that lead to them. That proximity provides earlier visibility into what is happening and why, and makes it easier to align internal priorities with the direction of the project.

It also improves how organizations interact with the software itself. When teams contribute, they develop a deeper understanding of how the system works, from architecture to release cycles to tradeoffs made by maintainers. That knowledge leads to better implementation decisions and faster troubleshooting when issues arise.

Contribution also strengthens feedback loops. By engaging with maintainers and other contributors, organizations develop a more direct line of communication, where questions, bugs, and ideas can be shared with context. While it does not guarantee immediate outcomes, it creates a more productive environment for resolving issues and improving the software over time.

From Consumption to Participation

Open source has already reshaped how software is built and delivered. But organizations must continue to evolve in how they engage with it. Consumption provides access, but unlocking the full value of open source requires contribution.

And contribution isn’t only about writing code. Documentation, testing, issue reporting, translation and community support all play invaluable roles in sustaining open source projects. These forms of participation are often more accessible and can still provide meaningful impact, both for the project and for the organizations involved.

By participating in the communities behind the software they depend on, organizations gain a more active role in shaping their own technical future. They reduce reliance on reactive fixes, strengthen the ecosystems they depend on, and create the conditions for more sustainable innovation. Open source is already a valuable foundation for countless organizations, but with contributions, that value begins to compound.

May 11, 2026
OpenSSF Defines Baseline for Securing Open Source Software

The Open Source Security Foundation (OpenSSF) has launched an initiative to provide maintainers of open source software projects with a set of baseline security requirements that can be realistically attained and maintained by small teams.

The Open Source Project Security Baseline (OSPS Baseline) provides a structured set of security requirements based on recognized international cybersecurity frameworks, standards, and regulations.

Ben Cotton, an OSPS co-maintainer and open source community lead for Kusari, said, unlike existing frameworks designed for large enterprise the OSPS Baseline provides open source maintainers with a more streamlined set of best practices that can be implemented by small teams. The OpenSSF plans to regularly update this framework as the tactics and techniques used by cybercriminals to compromise software supply chains continue to evolve, he added.

That approach will have a more meaningful impact on improving the overall security of open source software, which today can be found in nearly every enterprise IT environment, said Cotton.

The overall goal is to increase the level of confidence enterprise IT organizations have in open source software, especially when it was developed by a small team that doesn’t have the resources of, for example, the community that works on the Linux operating system, he noted.

That’s critical, because much of the innovation that occurs in software stems from the efforts of small teams that are initially experimenting with a new use case that is later adopted by larger enterprises, he added.

It’s not clear to what degree large enterprises in the wake of Heartbleed, Log4j and XZ incidents are pulling back on reliance on open source software that isn’t developed by a large community capable of reviewing security and, when needed, promptly developing a patch. The OSPS Baseline is intended to alleviate the concerns by enabling maintainers to self-attest that certain best practices have been followed, said Cotton,

Of course, the alacrity at which maintainers of open source software will develop a patch when a new vulnerability is discovered is naturally going to vary, especially if they are not being compensated for those efforts. However, most open source maintainers are trying to responsibly develop software with the OSPS Baseline now providing a core set of guidelines, said Cotton.

There is no silver bullet when it comes to resolving open source vulnerability issues, but, going forward, there is an opportunity through education to reduce the number being created. There may even come a day soon when contributors to open source projects are regularly using artificial intelligence (AI) tools to review code that they wrote or may have been generated by a machine. The issue, of course, is the amount of flawed open source code being generated might exponentially increase because many of the AI tools created code were trained using software that already contained vulnerable code.

Ultimately, enterprise IT organizations need to assume there are known and unknown vulnerabilities in the open source software that has already been deployed. The challenge, of course, is finding vulnerable code in a sea of open source software that has been distributed across an entire enterprise, remains all too exceedingly difficult.

March 3, 2025
Scarf Integrates Platform for Tracking Open Source Software Usage With Salesforce

Scarf today at the KubeCon + CloudNativeCon 2024 conference revealed it has integrated its platform for tracking consumption of open source software with the Salesforce customer relationship management (CRM) platform, at a time when the debate over what open source constitutes remains heated.

The platform has also been updated to add an ability to directly correct and flag event data for improved accuracy in company matching and attribution and enhanced data filtering options for exporting data.

The Scarf platform is primarily used by IT vendors to identify organizations that are consuming open-source software at a level of scale that might warrant additional support. Alternatively, some vendors may have developed commercial add-ons to an open-source tool or platform that they are trying to encourage organizations to license.

The Scarf platform ties usage data and attributes such as internet addresses to specific organizations that have downloaded a significant amount of software from an open-source software repository. In total, the Scarf gateway has tracked more than seven billion events.

Scarf CEO Avi Press said the company works in partnership with consortiums such as The Linux Foundation to help ensure the open-source software ecosystem remains economically viable. In the absence of those insights there would not be as many IT vendors sponsoring open source software projects, he noted.

There is, of course, a lot of contention within the open-source community that often results in forks being created, because an IT vendor that originally created one project or another has decided to change its licensing terms. Usually, that change is attributed to cloud service providers that wind up benefiting more financially from the open-source software than the vendor that created it.

When those changes are made to licensing terms, however, it’s usually not too long before disaffected members of a community, sometimes with the help of a cloud service provider, create a fork of that original project that is made available under the same licensing terms as the previous project.

That level of friction, however, could be avoided if it was simpler for IT vendors that sponsor open-source projects to find opportunities to add additional commercial value in a more targeted way, said Press. In fact, many of those organizations are more likely to respond positively to such inquiries than a generic cold call from a salesperson, he added. Those types of customer engagements ensure the open-source software ecosystem remains healthy, said Press.

There are, of course, strident open-source software advocates who are generally suspicious of any project sponsored by IT vendors. However, many of the contributions to those projects are made by software engineers who work for IT vendors.

Arguments over open-source licensing models have been occurring for decades. Most recently, the community has been arguing over what constitutes an open-source AI model, many of which don’t make available how the weights were applied to train the underlying large language model (LLM). It’s not likely any of these issues will be resolved any time soon, however, ultimately each organization will need to decide for itself what definition of open source it wants to embrace and support.

November 13, 2024
White House to Spend $11 Million to Study Open Source Software Use

Hardening the security around open source software has been a key part of the White House’s larger cybersecurity efforts since President Biden released his executive order for improving the United States’ security posture in May 2021, only months after taking office.

Now the Biden Administration and the Department of Homeland Security (DHS) are putting $11 million to launch a program aimed at assessing the use of open source software in critical infrastructure environments and how to better protect it.

Speaking at the Def-Con show late last week in Las Vegas, National Cyber Director Harry Coker Jr. announced the plan to launch the government’s Open Source Software Prevalence Initiative, which includes participation by the country’s National Laboratories.

“We know that open-source underlies our digital infrastructure, and it’s vital that, as a government, we contribute back to the community as part of our broader infrastructure efforts,” Coker said at the conference.

He added that while the government is creating the initiative and putting money behind it, it will need the participation of cybersecurity professionals.

“These policy proposals rely on the dedication of researchers and their willingness to freely share their findings in order to work,” Coker said. “In our conversations on developing a software liability regime, too, we are increasingly aiming to leverage this unique community as part of novel policy solutions.”

A key part of the Biden Administration’s cybersecurity push to improve the country’s cybersecurity is to shift the responsibility away from technology’s users and toward its creators through such efforts as its Secure By Design software message. Coker reiterated that during his talk, telling the audience of cybersecurity experts of the need for “more of the responsibility for cybersecurity to fall upon the more capable actors in the ecosystem. That means technology producers, yes, and certainly the Federal Government. But it also means all of you.… I know that the same value set that drives responsible vulnerability disclosure will lead you to continue to step up for the protection of the internet.”

Collaboration is Key

The government’s reach is only so long, he said. The president can’t solve problems by simply issuing an order. Coker noted that the government and tech industry has known for decades about security flaws in the Border Gateway Protocol, yet still much of the U.S. internet traffic is vulnerable to being hijacked. The same goes for using memory-safe programming languages like Rust and Go to eliminate a large percentage of vulnerabilities found in today’s software.

“Still, critical software that underlies our society is written in C, simply because that’s what’s convenient,” he said. “The ‘tragedy of the commons’ around open-source software development is a well-understood phenomenon; still, vital packages are maintained by tiny bands of volunteers operating on a less-than shoestring budget.”

Wait and See

Katie Teitler-Santullo, cybersecurity strategist with OX Security, said how effective a program like the Open Source Software Prevalence Initiative can be is uncertain.

“On the one hand, initiatives like this coming down from the White House and DHS signal to private industry that increased scrutiny is coming,” said Teitler-Santullo, whose company offers an application security posture management platform. “Given the growing reliance on open-source software – and the open-source components in most software – businesses must have a better understanding of the software, at all stages of its lifecycle.”

Still, government programs like this don’t come with feasibility or impact guarantees. A lot of organizations have trouble monitoring and triaging what she called the “long tail of software” and app security and development teams have trouble keeping pace with the rapid evolution of the open source ecosystem.

“What’s not in question is the importance of organizations, public and private, to understand and act on open source vulnerabilities as well as custom software built on top of open-source components,” Teitler-Santullo said. “Understanding your code at multiple levels and all throughout the software development lifecycle … is not a nice-to-have anymore. One small vulnerability could cause widespread damage.”

Marching Orders

Coker’s remarks at Def-Con came a day after the White House released a summary of responses to its request for information regarding what should be among the government’s long-term priorities for open source software security.

The creation of the Open-Source Software Prevalence Initiative is one of the government’s responses to what it heard from those who responded to the request for information.

The report called for the administration to leverage federal agencies to accelerate open source security. These include expanded development of software bill of materials as well as establishing a U.S. Government Open Source Program Office. According to the summary, the responses focused on a number of steps, including promoting the expanded use of software bills-of-materials (SBOMs), strengthening the software supply chain, and securing package repositories, which have been targets for bad actors looking to spread their malicious codes through organizations inadvertently installing and executing what appears to be legitimate software.

Memory-Safe Languages a Priority

They also recommended the government offer more incentives to use memory-safe languages.

“There was also consensus that implementing memory-safe programming would be significantly easier for new projects than for legacy projects,” according to the summary’s authors. “For the latter, many respondents supported using a tiered and prioritized approach as a way to optimize resources while focusing on the most critically important projects.”

The recent launch by DARPA (Defense Advanced Research Project Agency) of its TRACTOR (Translating All C to Rust) program for automating many of the tasks needed to rewrite C and C++ code into Rust is an example.

Other recommendations included funding the development of tools and libraries for securing the open source software ecosystem, creating private-public partnerships within the community, helping expand the developer talent pool, expanding international cooperation, and researching the use of AI, large-language models, and machine learning techniques.

August 16, 2024
ForAllSecure Adds Free Testing Tools for OSS

ForAllSecure is investing to make open source software (OSS) more secure and is making available free, personal-use versions of its Mayhem application security testing tools infused with artificial intelligence (AI) capabilities to anyone using GitHub repositories.

Company CEO David Brumley said anyone who integrates Mayhem into a qualified GitHub repository being used to build open source software will receive $1,000 as part of the company’s Mayhem Heroes program.

There are now two free, personal-use editions of Mayhem that can be used to analyze code or application programming interfaces (APIs). Those tools are based on fuzz testing technology, which randomly injects data into applications to detect vulnerabilities as part of an effort to automate DevSecOps processes.

In the wake of the discovery of zero-day vulnerabilities in open source software that have impacted enterprise IT organizations, more attention is being paid to how open source software is created, maintained and secured. Many of the developers who build and maintain open source software don’t typically have a lot of cybersecurity expertise, and don’t have the time and resources required to continually remediate vulnerabilities as they are discovered. The Mayhem application security testing tools are designed to make it faster to discover vulnerabilities using AI technologies to reduce the number of false-positive alerts.

It’s too early to say how quickly open source software might be made more secure, but tons of resources are being made available. 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 spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software used inside (and outside) government agencies by expanding compliance mandates. The White House is also trying to encourage IT vendors and larger enterprises to contribute more to the effort to secure open source software.

The pressure is rising on both developers and consumers of open source software to make sure open source software is secure. However, many open source projects are maintained by a small number of programmers who contribute their time and effort to build components that others are free to use. Many of them argue it is the responsibility of the organizations that deploy that software to ensure the software is secure Many IT vendors and large enterprise IT organizations that rely on that code aren’t contributing anything meaningful back to the project, in terms of either financing or just helping open source maintainers find and remediate vulnerabilities. The irony is many of those same organizations are now assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions.

April 18, 2022
Fixing Spring4Shell Starts With Software Supply Chain Management

Spring4Shell is the latest call to action for radically improved software supply chain integrity. While Spring4Shell investigations continue, one conclusion is indisputable: We must holistically rethink the way we continuously inventory and manage the complex landscape of interrelated software and its sources.

Whether or not Spring4Shell surpasses the breadth of impact of Log4j, there’s still massive potential for severe consequences to software and API security across the open source infrastructure, frameworks and application software stacks.

That’s because, as we saw with Log4j, this attack could impact most enterprise Java applications globally. It seems the root cause is a vulnerability in the widely used, free, community-developed, open source programming framework Spring Core.

The Spring framework is the foundation for most enterprise Java applications—as many as 74%, according to some data. Specifically, Spring serves as the foundation for enterprise Java apps so that teams can focus on application-level business logic without being locked into specific deployment environments.

Spring Core’s ubiquity introduces significant potential for widespread impact due to its use across enterprise software, cloud services, third-party software and service products as well as internally managed software. This is another call-to-action to improve the way we approach software supply chain security and supply chain management. Thankfully, there’s already a place to start.

Every infrastructure and software team can begin addressing this vulnerability by leveraging resources from The Linux Foundation’s Software Bill Of Materials (SBOM) project. The 2021 initiative included an SBOM readiness survey, a Generating Software Bill Of Materials training course and an SBOM generator tool based on the SPDX standard (ISO/IEC 5962:2021).

The Linux Foundation’s SBOM contributions provided all of us a head start to begin addressing issues with software supply chain management. With widespread adoption, SBOM equips software projects and users to assess and address Spring4Shell as well as any other as-yet-unknown vulnerabilities and prepare us for what is undoubtedly a season of high-impact infrastructure software vulnerabilities.

For more Spring4Shell resources, please visit: https://www.contrastsecurity.com/security-influencers/new-spring4shell-vulnerability-confirmed-what-it-is-and-how-to-be-prepared

April 1, 2022
IDC Tech Spotlight: Making Open Source Work for You

Starting from remarkably humble beginnings over three decades ago, open source software is the story of a better mousetrap that wins over the world. Originally, the intent of open source projects was to create software that system administrators and developers could use without having to pay licensing fees – but it has become much, much more. This IDC Technology Spotlight takes a deeper look at the value proposition associated with using commercially supported open source software in mission-critical environments, like IBM Z.

To read more, please visit: IDC Tech Spotlight: Making Open Source Work for You: Achieving Optimum Value, Security, and Productivity

September 28, 2021