Prossimo continues to advance the functionality and scalability of the Rustls TLS library and the Rust for Linux effort thanks to $530,000 in funding from the OpenSSF’s Alpha-Omega project. This funding will further Prossimo’s efforts to bring memory safety to critical components of the Internet and further OpenSSF’s Alpha-Omega project’s mission to protect society by improving the security of open source software.
Early adopters of SBOM have proposed new standards as well as updates to existing standards to specify the status of each vulnerability alongside the SBOM itself. In this context, existing practices such as VDR, CSAF, and emerging standards VEX and OpenVEX are playing a key role.
Securing the open source ecosystem isn’t a passive act. It calls for proactive participation through regular code reviews, vulnerability assessments, or simply staying updated with the latest security protocols. Every user, every developer, and every enthusiast has a role to play.
If you’re not using automation to monitor the security risks from your dependency tree, chances are your project is vulnerable. Although these vulnerabilities may not be malicious, they can still allow malicious actors to target your users or their data.
At Open Source Summit North America earlier this year as a 10th grader, Nathan Naveen, gave a talk about OpenSSF Criticality Score. Nathan takes a look at why understanding tools like the Criticality Score is a valuable skill for anyone involved in open source contributions, no matter your age.
While many in the industry realize the value of having a software bill of materials, creators still need to generate high-fidelity SBOMs, and software consumers must ingest and enforce actions based on a given SBOM for it to be a useful endeavor. Otherwise, we’re just adding more to the pile of potentially useful but not entirely actionable data that plagues many cybersecurity programs. As the supply chain for software continues to grow in complexity, and as attacks on those components grow, SBOMs will provide the groundwork to manage how those assets get protected at scale.
Fuzz Introspector is an open source tool that at its core provides insights and suggestions for improvements on how a given project is being fuzzed. In this blog post we present background information and updates on Fuzz Introspector, which is developed in a collaboration between OpenSSF and Google’s OSS-Fuzz.
SBOMs enable organizations to identify vulnerabilities, track open-source usage, and ensure compliance with numerous licensing obligations. Having a “single source of truth” for security and licensing information helps everyone. Let’s take a look at why SBOM Generators need to accurately represent Open Source Licenses.
Let’s get it out of the way early: it’s not always clear how you can best plug into organizations like OpenSSF. That’s why I’m writing this guest blog post as an “outsider.” I’m just your average tech employee who has become progressively more involved since my company, Sonatype, became members of OpenSSF. If you’re connecting for your first time, the recommended engagement path is effectively “choose your adventure!”
It’s important to distinguish the term “source” (any source of a good or service) from the term “vendor” (a source who is paid and has a contractual relationship), especially when discussing software. Here’s why.
