Who We Are
Prossimo is an Internet Security Research Group (ISRG) project.
ISRG couldn't do it alone though. We have a strong community of developers, maintainers, advisors, and funders helping us out!
Goals
Our first goal is to move the Internet's security-sensitive software infrastructure to memory safe code. Many of the most critical software vulnerabilities are memory safety issues in C and C++ code. While there are ways to reduce the risk, including fuzzing and static analysis, such mitigations do not eliminate the risk and they consume a lot of resources on an ongoing basis. Using memory safe languages eliminates the entire class of issues. We recognize the amount of work it will take to move significant portions of the Internet’s C and C++ software infrastructure to memory safe code, but the Internet will be around for a long time. There is time for ambitious efforts to pay off. By being smart about our initial investments, focusing on the most critical components, we can start seeing significant returns within 1-2 years.
Our second goal is to change the way people think about memory safety. Today it’s considered perfectly normal and acceptable to deploy software written in languages that aren't memory safe, like C and C++, on a network edge, despite the overwhelming evidence for how dangerous this is. Our hope is that we can get people to fully recognize the risk and view memory safety as a requirement for software in security-sensitive roles.
Prossimo's Role
We view ISRG's role as providing strategic planning, facilitation, and communication. We identify high impact projects, build and maintain relationships with maintainers and funders, help develop plans, and coordinate the work. This includes raising the necessary funds and getting them to the right people (often maintainers). We communicate with the public regarding progress and momentum in order to build support for the project and the ideas behind it.
We believe we have a strong competency in identifying work that is both high impact and efficiently achievable. Our aim is for funding entrusted to us to provide a strong return on investment in terms of making the Internet’s software infrastructure safer for everyone.
Identifying Risk
When we're thinking about what software we want to invest in we think primarily about four risk criteria:
- Very widely used (nearly every server and/or client)
- On a network boundary
- Performing a critical function
- Written in languages that are not memory safe (e.g. C, C++, asm)
We're primarily concerned with investing in software that meets all four of these criteria. This means we aren't going to be working on a lot of software - we are focused only on the most critical components of the Internet ecosystem.
Identifying Opportunity
We prioritize the software we'd like to improve by thinking about the following opportunity criteria:
- Is this a library or component that can be used in many different projects?
- Can we efficiently replace key components with existing memory safe libraries?
- Are funders willing to fund the work?
- Are the maintainers on board and cooperative?
The more criteria are met here the more likely it is that we will make investments.
Working With Maintainers
We prefer working with existing maintainers whenever possible.
Maintainers have valuable knowledge and the ability to ship memory safety updates to their existing users. Building alternative software and getting users to switch, while sometimes necessary, is much more difficult. By working with maintainers, and funding them when it makes sense, we can get safer software into the hands of users more quickly.
Funding maintainers for the work helps to create buy-in and alleviates resource concerns.
Preferring a Modular Approach
We encourage projects to replace libraries or modular functionality with memory safe libraries, rather than embark upon ground-up rewrites. This allows us to break up the work into manageable pieces and deliver value incrementally.
It also allows for build-time configuration to select implementations when existing users need the ability to opt-in to the older unsafe versions, either because their environment does not support the new language or because there is a functionality difference. This addresses the concern many maintainers have about abandoning certain specialized users.
Since many projects will end up using the same memory safe libraries, this approach also allows us to invest and build confidence in a particular set of libraries. Investments in a library for one project will add value across multiple projects. For example - the curl project will use the Hyper and Rustls libraries. The work we do to build excellent C API wrappers and improve the integration experience will help with many projects that will use the libraries in the future.
Building Trust Over Time
Some maintainers are understandably hesitant to make fundamental changes to how their projects work, such as adding a new language or replacing important libraries with new ones. It’s on us to make the case, and we will do that by building up a corpus of success stories and continuing to engage with maintainers about how their concerns can be addressed.
We will start by working with more progressive maintainers that need less convincing. As those projects succeed and get positive feedback, other maintainers will come to trust the model that we advocate. Our hope is that over time we can convince more conservative maintainers that moving to memory safe code, with our support, is a worthwhile endeavor.