Google Online Security Blog

KEMBAR78

Google Online Security Blog: Open Source

Improving Interoperability Between Rust and C++

February 5, 2024

Posted by Lars Bergstrom – Director, Android Platform Tools & Libraries and Chair of the Rust Foundation Board Back in 2021, we announced that Google was joining the Rust Foundation. At the time, Rust was already in wide use across Android and other Google products. Our announcement emphasized our commitment to improving the security reviews of Rust code and its interoperability with C++ code. Rust is one of the strongest tools we have to address memory safety security issues. Since that announcement, industry leaders and government agencies have echoed our sentiment. We are delighted to announce that Google has provided a grant of $1 million to the Rust Foundation to support efforts that will improve the ability of Rust code to interoperate with existing legacy C++ codebases. We’re also furthering our existing commitment to the open-source Rust community by aggregating and publishing audits for Rust crates that we use in open-source Google projects. These contributions, along with our previous interoperability contributions, have us excited about the future of Rust.“Based on historical vulnerability density statistics, Rust has proactively prevented hundreds of vulnerabilities from impacting the Android ecosystem. This investment aims to expand the adoption of Rust across various components of the platform.” – Dave Kleidermacher, Google Vice President of Engineering, Android Security & Privacy While Google has seen the most significant growth in the use of Rust in Android, we’re continuing to grow its use across more applications, including clients and server hardware. “While Rust may not be suitable for all product applications, prioritizing seamless interoperability with C++ will accelerate wider community adoption, thereby aligning with the industry goals of improving memory safety.” – Royal Hansen, Google Vice President of Safety & Security The Rust tooling and ecosystem already support interoperability with Android and with continued investment in tools like cxx, autocxx, bindgen, cbindgen, diplomat, and crubit, we are seeing regular improvements in the state of Rust interoperability with C++. As these improvements have continued, we’ve seen a reduction in the barriers to adoption and accelerated adoption of Rust. While that progress across the many tools continues, it is often only expanded incrementally to support the particular needs of a given project or company. In order to accelerate both Rust adoption at Google as well as more broadly across the industry, we are eager to invest in and collaborate on any needed ABI changes, tooling and build system support, wrapper libraries, or other areas identified. We are excited to support this work through the Rust Foundation’s Interop Initiative and in collaboration with the Rust project to ensure that any additions made are suitable and address the challenges of Rust adoption that projects using C++ face. Improving memory safety across the software industry is one of the key technology challenges of our time, and we invite others across the community and industry to join us in working together to secure the open source ecosystem for everyone. Learn more about the Rust Foundation’s Interop Initiative by reading their recent announcement.

Introducing the Secure Open Source Pilot Program

October 1, 2021

Posted by Meder Kydyraliev and Kim Lewandowski, Google Open Source Security Team
Over the past year we have made a number of investments to strengthen the security of critical open source projects, and recently announced our $10 billion commitment to cybersecurity defense including $100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities.

Today, we are excited to announce our sponsorship for the Secure Open Source (SOS) pilot program run by the Linux Foundation. This program financially rewards developers for enhancing the security of critical open source projects that we all depend on. We are starting with a $1 million investment and plan to expand the scope of the program based on community feedback.

Why SOS?
SOS rewards a very broad range of improvements that proactively harden critical open source projects and supporting infrastructure against application and supply chain attacks. To complement existing programs that reward vulnerability management, SOS’s scope is comparatively wider in the type of work it rewards, in order to support project developers.

What projects are in scope?
Since there is no one definition of what makes an open source project critical, our selection process will be holistic. During submission evaluation we will consider the guidelines established by the National Institute of Standards and Technology’s definition in response to the recent Executive Order on Cybersecurity along with criteria listed below:

The impact of the project:

How many and what types of users will be affected by the security improvements?
Will the improvements have a significant impact on infrastructure and user security?
If the project were compromised, how serious or wide-reaching would the implications be?

The project’s rankings in existing open source criticality research:

Is the project included in the Havard 2 Census Study of most-used packages, or does it have a score of 0.6 or above in the OpenSSF Critically Score project?

What security improvements qualify?
The program is initially focused on rewarding the following work:

Software supply chain security improvements including hardening CI/CD pipelines and distribution infrastructure. The SLSA framework suggests specific requirements to consider, such as basic provenance generation and verification.
Adoption of software artifact signing and verification. One option to consider is Sigstore's set of utilities (e.g. cosign).
Project improvements that produce higher OpenSSF Scorecard results. For example, a contributor can follow remediation suggestions for the following Scorecard checks:

Code-Review
Branch-Protection
Pinned-Dependencies
Dependency-Update-Tool
Fuzzing

Use of OpenSSF Allstar and remediation of discovered issues.
Earning a CII Best Practice Badge (which also improves the Scorecard results).

We'll continue adding to the above list, so check our FAQ for updates. You may also submit improvements not listed above, if you provide justification and evidence to help us understand the complexity and impact of the work.

Only work completed after October 1, 2021 qualifies for SOS rewards.

Upfront funding is available on a limited case by case basis for impactful improvements of moderate to high complexity over a longer time span. Such requests should explain why funding is required upfront and provide a detailed plan of how the improvements will be landed.
How to participate
Review our FAQ and fill out this form to submit your application.

Please include as much data or supporting evidence as possible to help us evaluate the significance of the project and your improvements.

Reward amounts
Reward amounts are determined based on complexity and impact of work:

$10,000 or more for complicated, high-impact and lasting improvements that almost certainly prevent major vulnerabilities in the affected code or supporting infrastructure.
$5,000-$10,000 for moderately complex improvements that offer compelling security benefits.
$1,000-$5,000 for submissions of modest complexity and impact.
$505 for small improvements that nevertheless have merit from a security standpoint.

Looking Ahead
The SOS program is part of a broader effort to address a growing truth: the world relies on open source software, but widespread support and financial contributions are necessary to keep that software safe and secure. This $1 million investment is just the beginning—we envision the SOS pilot program as the starting point for future efforts that will hopefully bring together other large organizations and turn it into a sustainable, long-term initiative under the OpenSSF. We welcome community feedback and interest from others who want to contribute to the SOS program. Together we can pool our support to give back to the open source community that makes the modern internet possible.

Distroless Builds Are Now SLSA 2

September 22, 2021

Posted by Priya Wadhwa and Appu Goundan, Google Open Source Security Team
signing all distroless images with cosignSLSA 2security framework

SLSA 2 Requirement	Distroless
Source - Version controlled	Source code in Github
Build - Scripted build	Build script exists as a Tekton Pipeline, invoked as a Google Cloud Build step
Build - Build service	All steps run on Kubernetes with Tekton
Provenance - Available	Provenance is available in the rekor transparency log as an in-toto attestation
Provenance - Authenticated	Provenance is signed with the distroless GCP KMS key
Provenance - Service generated	Provenance is generated by Tekton Chains from a Tekton TaskRun

Achieving SLSA 2 required some changes to the distroless build pipeline: we set up Tekton Pipelines and Tekton Chains in a GKE cluster to automate building images and generating provenance. Every time a pull request is merged to the distroless Github repo, a Tekton Pipeline is triggered. This Pipeline builds the distroless images, and Tekton Chains is responsible for generating signed provenance for each image. Tekton Chains stores the signed provenance alongside the image in an OCI registry and also stores a record of the provenance in the rekor transparency log.

Don't trust us?

You can try the build yourself. Because distroless builds are reproducible, all the information to replicate the build is in the provenance, and you or a trusted third party can build the image yourselves and verify the build is correct by matching image digests.

You can verify an attestation for a distroless image with cosign and the distroless public key:

$ cosign verify-attestation -key cosign.pub gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91

Verification for gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91 --

The following checks were performed on each of these signatures:

- The cosign claims were validated

- The signatures were verified against the specified public key

- Any certificates were verified against the Fulcio roots.

...

And you can find the provenance for the image in the rekor transparency log with the rekor-cli tool. For example, you could find the provenance for the above image by using the image’s digest and running:

$ rekor-cli search --sha sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91

af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8

$ rekor-cli get --uuid af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8 --format json | jq -r .Attestation | base64 --decode | jq

{

"_type": "distroless-provenance",

"predicateType": "https://tekton.dev/chains/provenance",

"subject": [

{

"name": "gcr.io/distroless/base",

"digest": {

"sha256": "703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d"

}

{

"name": "gcr.io/distroless/base",

"digest": {

"sha256": "d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce"

}

{

"name": "gcr.io/distroless/base",

"digest": {

"sha256": "2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661"

}

{

"name": "gcr.io/distroless/base",

"digest": {

"sha256": "4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91"

}

{

"name": "gcr.io/distroless/base",

"digest": {

"sha256": "dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980"

}

{