Jay Jacobs and I recently delivered an RSA presentation called Quantifying the Probability of Flaws in Open Source. Since many people didn’t get a chance to see it, I thought I’d summarize some of the findings here for posterity. The question we investigated was simple, at least conceptually: what are the red flags of an open-source repository? Are there characteristics of a given open source library that would reliably indicate it was safer than others?

On July 1, 2024, OpenSSH released fixes for CVE-2024-6387, a vulnerability in OpenSSH’s server (sshd) on glibc-based Linux systems allowing for potential Remote Code Execution (RCE). OpenSSH is a widely-used suite of secure networking tools based on the SSH protocol, providing encryption for secure communication and file transfers, and is essential for remote management on Unix systems. CVE-2024-6387 is a signal handler race condition that allows unauthenticated Remote Code Execution (RCE) as root.

Calico policies are a way to enforce network security at the pod level. This blog post will provide a comprehensive overview of Calico policies for Calico OS (Open Source) users. We will cover the basics of Calico policies, including what they are, how they work, and how to use them. We will also provide best practices for using Calico policies and examples of how they can be used in real-world scenarios.

Only about 35 percent of the models on Hugging Face bear any license at all. Of those that do, roughly 60 percent fall under traditional open source licenses. But while the majority of licensed AI models may be open source, some very large projects–including Midjourney, BLOOM, and LLaMa—fall under that remaining 40 percent category. So let’s take a look at some of the top AI model licenses on Hugging Face, including the most popular open source and not-so-open source licenses.

In August 2021 we launched Kubescape with a mission to make Kubernetes security open source, simple, and available for everyone, even non-security engineers. Since then we have been working on adding new capabilities to Kubescape, while building a strong community around it. The acceptance of Kubescape by the CNCF, as a sandbox project, was an important milestone for ARMO’s open-source journey with Kubescape.

You’re confident in your development chops—confident enough to know the apps you’ve built aren’t completely free of security and configuration flaws. You’ve also researched the deep ecosystem of scanning tools available and perhaps got overwhelmed by the sheer volume of choice. What’s the right “portfolio” of open-source app security tools to identify vulnerabilities in your dependencies, Infrastructure as Code (IaC) configurations, containers, and more?

The last time we wrote about open source software (OSS) for security, we explored how community-driven innovation addresses security problems stemming from the rapid pace of business-driven technological advancements. We posed the question: Can open source security solutions adequately secure and protect the OSS that modern businesses depend on?

Foresiet, your trusted cybersecurity advisor, brings attention to the recent addition of a security flaw impacting Apache Flink to the Known Exploited Vulnerabilities catalog by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Tracked as CVE-2020-17519, this vulnerability poses a significant risk due to its potential for active exploitation. Understanding the Vulnerability.

Using open-source code exposes organizations to a tremendous amount of risk, yet this point is treated like a dirty little secret that nobody talks about. So, let’s live on the edge and take a minute to talk about the problem. Open-source code is an oddity. Generally, open-source code is often placed in small packets tucked inside massive programs that corporations use to run their most important processes or it is adopted as a whole program and tasked with running some part of a business.