text:
Gregarius » Items by Kaylin Trychon
Items by Kaylin Trychon
Google Online Security Blog
Apache Log4j Vulnerability
Posted: December 18th, 2021, 3:08am CET by Kaylin Trychon
Like many other companies, we're closely following the multiple CVEs regarding Apache Log4j 2. Our security teams are investigating any potential impact on Google products and services and are focused on protecting our users and customers.
We encourage anyone who manages environments containing Log4j 2 to update to the latest version.
Based on findings in our ongoing investigations, here is our list of product and service updates as of December 17th (CVE-2021-44228 & CVE-2021-45046):
Android is not aware of any impact to the Android Platform or Enterprise. At this time, no update is required for this specific vulnerability, but we encourage our customers to ensure that the latest security updates are applied to their devices.
Chrome OS releases and infrastructure are not using versions of Log4j affected by the vulnerability.
Chrome Browser releases, infrastructure and admin console are not using versions of Log4j affected by the vulnerability.
Google Cloud has a specific advisory dedicated to updating customers on the status of GCP and Workspace products and services.
Google Marketing Platform, including Google Ads is not using versions of Log4j affected by the vulnerability. This includes Display & Video 360, Search Ads 360, Google Ads, Analytics (360 and free), Optimize 360, Surveys 360 & Tag Manager 360.
YouTube is not using versions of Log4j affected by the vulnerability.
We will continue to update this advisory with the latest information.
Understanding the Impact of Apache Log4j Vulnerability
Posted: December 17th, 2021, 6:25pm CET by Kaylin Trychon
Posted by James Wetter and Nicky Ringland, Open Source Insights Team
The below numbers were calculated based on both log4j-core and log4j-api, as both were listed on the CVE. Since then, the CVE has been updated with the clarification that only log4j-core is affected.
The ecosystem impact numbers for just log4j-core, as of 19th December are over 17,000 packages affected, which is roughly 4% of the ecosystem. 25% of affected packages have fixed versions available.
The linked list, which continues to be updated, only includes packages which depend on log4j-core.
More than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities (1, 2), with widespread fallout across the software industry. The vulnerabilities allow an attacker to perform remote code execution by exploiting the insecure JNDI lookups feature exposed by the logging library log4j. This exploitable feature was enabled by default in many versions of the library.
This vulnerability has captivated the information security ecosystem since its disclosure on December 9th because of both its severity and widespread impact. As a popular logging tool, log4j is used by tens of thousands of software packages (known as artifacts in the Java ecosystem) and projects across the software industry. User's lack of visibility into their dependencies and transitive dependencies has made patching difficult; it has also made it difficult to determine the full blast radius of this vulnerability. Using Open Source Insights, a project to help understand open source dependencies, we surveyed all versions of all artifacts in the Maven Central Repository to determine the scope of the issue in the open source ecosystem of JVM based languages, and to track the ongoing efforts to mitigate the affected packages.
How widespread is the log4j vulnerability?
As far as ecosystem impact goes, 8% is enormous. The average ecosystem impact of advisories affecting Maven Central is 2%, with the median less than 0.1%.
What is the current progress in fixing the open source JVM ecosystem?
We counted an artifact as fixed if the artifact had at least one version affected and has released a greater stable version (according to semantic versioning) that is unaffected. An artifact affected by log4j is considered fixed if it has updated to 2.16.0 or removed its dependency on log4j altogether.
At the time of writing, nearly five thousand of the affected artifacts have been fixed. This represents a rapid response and mammoth effort both by the log4j maintainers and the wider community of open source consumers.
That leaves over 30,000 artifacts affected, many of which are dependent on another artifact to patch (the transitive dependency) and are likely blocked.
Why is fixing the JVM ecosystem hard?Most artifacts that depend on log4j do so indirectly. The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs. For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.
Another difficulty is caused by ecosystem-level choices in the dependency resolution algorithm and requirement specification conventions.
In the Java ecosystem, it's common practice to specify "soft" version requirements — exact versions that are used by the resolution algorithm if no other version of the same package appears earlier in the dependency graph. Propagating a fix often requires explicit action by the maintainers to update the dependency requirements to a patched version.
This practice is in contrast to other ecosystems, such as npm, where it's common for developers to specify open ranges for dependency requirements. Open ranges allow the resolution algorithm to select the most recently released version that satisfies dependency requirements, thereby pulling in new fixes. Consumers can get a patched version on the next build after the patch is available, which propagates up the dependencies quickly. (This approach is not without its drawbacks; pulling in new fixes can also pull in new problems.)
How long will it take for this vulnerability to be fixed across the entire ecosystem?
It's hard to say. We looked at all publicly disclosed critical advisories affecting Maven packages to get a sense of how quickly other vulnerabilities have been fully addressed. Less than half (48%) of the artifacts affected by a vulnerability have been fixed, so we might be in for a long wait, likely years.
But things are looking promising on the log4j front. After less than a week, 4,620 affected artifacts (~13%) have been fixed. This, more than any other stat, speaks to the massive effort by open source maintainers, information security teams and consumers across the globe.
Where to focus next?
Thanks and congratulations are due to the open source maintainers and consumers who have already upgraded their versions of log4j. As part of our investigation, we pulled together a list of 500 affected packages with some of the highest transitive usage. If you are a maintainer or user helping with the patching effort, prioritizing these packages could maximize your impact and unblock more of the community.
We encourage the open source community to continue to strengthen security in these packages by enabling automated dependency updates and adding security mitigations. Improvements such as these could qualify for financial rewards from the Secure Open Source Rewards program.
You can explore your package dependencies and their vulnerabilities by using Open Source Insights.
Improving OSS-Fuzz and Jazzer to catch Log4Shell
Posted: December 16th, 2021, 11:04pm CET by Kaylin Trychon
Posted by Jonathan Metzman, Google Open Source Security Team
The discovery of the Log4Shell vulnerability has set the internet on fire. Similar to shellshock and heartbleed, Log4Shell is just the latest catastrophic vulnerability in software that runs the internet. Our mission as the Google Open Source Security Team is to secure the open source libraries the world depends on, such as Log4j. One of our capabilities in this space is OSS-Fuzz, a free fuzzing service that is used by over 500 critical open source projects and has found more than 7,000 vulnerabilities in its lifetime.
We want to empower open source developers to secure their code on their own. Over the next year we will work on better automated detection of non-memory corruption vulnerabilities such as Log4Shell. We have started this work by partnering with the security company Code Intelligence to provide continuous fuzzing for Log4j, as part of OSS-Fuzz. Also as part of this partnership, Code-Intelligence improved their Jazzer fuzzing engine to make it capable of detecting remote JNDI lookups. We have awarded Code Intelligence $25,000 for this effort and will continue to work with them on securing the open source ecosystem.
Caption: OSS-Fuzz and Jazzer finding the Log4Shell Vulnerability
Vulnerabilities like Log4Shell are an eye-opener for the industry in terms of new attack vectors. With OSS-Fuzz and Jazzer, we can now detect this class of vulnerability so that they can be fixed before they become a problem in production code.
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.
We appreciate the maintainers, security engineers and incident responders that are working to mitigate Log4j and make our internet ecosystem safer.
Check out our documentation to get started using OSS-Fuzz.
Exploring Container Security: A Storage Vulnerability Deep Dive
Posted: December 2nd, 2021, 9:00pm CET by Kaylin Trychon
Posted by Fabricio Voznika and Mauricio Poppe, Google Cloud
Kubernetes Security is constantly evolving - keeping pace with enhanced functionality, usability and flexibility while also balancing the security needs of a wide and diverse set of use-cases.
Recently, the GKE Security team discovered a high severity vulnerability that allowed workloads to have access to parts of the host filesystem outside the mounted volumes boundaries. Although the vulnerability was patched back in September we thought it would be beneficial to write up a more in-depth analysis of the issue to share with the community.
We assessed the impact of the vulnerability as described in vulnerability management in open-source Kubernetes and worked closely with the GKE Storage team and the Kubernetes Security Response Committee to find a fix. In this post we'll give some background on how the subpath storage system works, an overview of the vulnerability, the steps to find the root cause and the fix, and finally some recommendations for GKE and Anthos users.
Kubernetes Filesystems: Intro to Volume Subpath
The vulnerability, CVE-2021-25741, was caused by a race condition during the creation of a subpath bind mount inside a container, and allowed an attacker to gain unauthorized access to the underlying node filesystem and its sensitive files. We'll describe how that system is supposed to work, and then talk about the vulnerability.
The volume subpath feature in Kubernetes enables sharing a volume in multiple containers inside a pod. For example, we could create a Pod with an InitContainer that creates directories with pre-populated data in a mounted filesystem volume. These directories can then be used by containers in the same Pod by mounting the same volume and optionally specifying a subpath field to limit what's visible inside the container.
While there are some great use cases for this feature, it's an area that has had vulnerabilities discovered in the past. The kubelet must be extra cautious when handling user-owned subpaths because it operates with privileges in the host. One vulnerability that has been previously discovered involved the creation of a malicious workload where an InitContainer would create a symlink pointing to any location in the host. For example, the InitContainer could mount a volume in /mnt and create a symlink /mnt/attack inside the container pointing to /etc. Later in the Pod lifecycle, another container would attempt to mount the same volume with subpath attack. While preparing the volumes for the container, the kubelet would end up following the symlink to the host's /etc instead of the container's /etc, unknowingly exposing the host filesystem to the container. A previous fix made sure that the subpath mount location is resolved and validated to point to a location inside the base volume and that it's not changeable by the user in between the time the path was validated and when the container runtime bind mounts it. This race condition is known as time of check to time of use (TOCTOU) where the subject being validated changes after it has been validated.
These validations and others are summarized in the following container lifecycle sequence diagram.
Volume subpath validations before the container startup
A New TOCTOU Vulnerability: CVE-2021-25741
The latest vulnerability was discovered by performing a symlink attack similar to the one explained above, with the difference being that it constantly swapped the symlink with a directory in a tight loop, using the RENAME_EXCHANGE option with renameat(2). If the timing is just right, the kubelet will see the path as a directory and pass the validation check. Then the mount utility may find that the path is a symlink pointing to the host and follow it, exposing the host filesystem to the container. This is visualized in the following diagram:
The expectation and the attack outcome
The GKE Security and Storage teams worked closely to revise the fix done previously to find a solution. The previous fix takes several steps to ensure that the directory being mounted is safely opened and validated. After the file is opened and validated, the kubelet uses the magic-link path under /proc/[pid]/fd directory for all subsequent operations to ensure the file remains unchanged. However, we found out that all of the efforts were undone by the mount(8) linux utility which was dereferencing the procfs magic-link by default. Once the problem was understood, the fix involved making sure that the mount utility doesn't dereference the magic-links by using the --no-canonicalize flag in the mount command.
Once the problem was well understood, we fixed it inside Kubernetes and quickly released the fix to GKE and Anthos. If GKE auto-upgrade is enabled in your clusters there's no action on your part for this vulnerability, your nodes have already been patched. We strongly recommend that customers utilize auto-upgrades. Auto-upgrade gives peace of mind that your clusters are running with the latest patches.
GKE released a Google Kubernetes Engine security bulletin on this vulnerability, which detailed what customers can do to immediately remediate this issue across GKE and Anthos. We also provided guidance to customers who manually manage their node versions, ensuring that fixed releases were available in every region for our Static and Release Channels.
Google continues to invest heavily in the security of GKE and Kubernetes. We encourage users interested in finding vulnerabilities to participate in the Kubernetes bug bounty program and in the Google Vulnerability Rewards Program (VRP) which was recently expanded to cover GKE vulnerabilities. For the latest guidance on security issues, please follow our GKE Security Bulletins.
ClusterFuzzLite: Continuous fuzzing for all
Posted: November 11th, 2021, 1:00pm CET by Kaylin Trychon
In recent years, continuous fuzzing has become an essential part of the software development lifecycle. By feeding unexpected or random data into a program, fuzzing catches bugs that would otherwise slip through the most thorough manual checks and provides coverage that would take staggering human effort to replicate. NIST's guidelines for software verification, recently released in response to the White House Executive Order on Improving the Nation's Cybersecurity, specify fuzzing among the minimum standard requirements for code verification.
Today, we are excited to announce ClusterFuzzLite, a continuous fuzzing solution that runs as part of CI/CD workflows to find vulnerabilities faster than ever before. With just a few lines of code, GitHub users can integrate ClusterFuzzLite into their workflow and fuzz pull requests to catch bugs before they are committed, enhancing the overall security of the software supply chain.
Since its release in 2016, over 500 critical open source projects have integrated into Google's OSS-Fuzz program, resulting in over 6,500 vulnerabilities and 21,000 functional bugs being fixed. ClusterFuzzLite goes hand-in-hand with OSS-Fuzz, by catching regression bugs much earlier in the development process.
Large projects including systemd and curl are already using ClusterFuzzLite during code review, with positive results. According to Daniel Stenberg, author of curl, "When the human reviewers nod and have approved the code and your static code analyzers and linters can't detect any more issues, fuzzing is what takes you to the next level of code maturity and robustness. OSS-Fuzz and ClusterFuzzLite help us maintain curl as a quality project, around the clock, every day and every commit."
With the release of ClusterFuzzLite, any project can integrate this essential testing standard and benefit from fuzzing. ClusterFuzzLite offers many of the same features as ClusterFuzz, such as continuous fuzzing, sanitizer support, corpus management, and coverage report generation. Most importantly, it's easy to set up and works with closed source projects, making ClusterFuzzLite a convenient option for any developer who wants to fuzz their software.
With ClusterFuzzLite, fuzzing is no longer just an idealized "bonus" round of testing for those who have access to it, but a critical must-have step that everyone can use continuously on every software project. By finding and preventing bugs before they enter the codebase we can build a more secure software ecosystem.
To learn more, check out the ClusterFuzzLite documentation. ClusterFuzzLite currently supports GitHub Actions, Google Cloud Build and Prow. We built this with CI system extensibility in mind, and adding support for other CI systems is straightforward. Please contact us if you're interested in contributing support, or have any questions, feedback or feature requests.
Trick & Treat! 🎃 Paying Leets and Sweets for Linux Kernel privescs and k8s escapes
Posted: November 1st, 2021, 5:30pm CET by Kaylin Trychon
Posted by Eduardo Vela, Google Bug Hunters Team
Starting today and for the next 3 months (until January 31 2022), we will pay 31,337 USD to security researchers that exploit privilege escalation in our lab environment with a patched vulnerability, and 50,337 USD to those that use a previously unpatched vulnerability, or a new exploit technique.
We are constantly investing in the security of the Linux Kernel because much of the internet, and Google—from the devices in our pockets, to the services running on Kubernetes in the cloud—depend on the security of it. We research its vulnerabilities and attacks, as well as study and develop its defenses.
But we know that there is more work to do. That's why we have decided to build on top of our kCTF VRP from last year and triple our previous reward amounts (for at least the next 3 months).
Our base rewards for each publicly patched vulnerability is 31,337 USD (at most one exploit per vulnerability), but the reward can go up to 50,337 USD in two cases:
If the vulnerability was otherwise unpatched in the Kernel (0day)
If the exploit uses a new attack or technique, as determined by Google
We hope the new rewards will encourage the security community to explore new Kernel exploitation techniques to achieve privilege escalation and drive quicker fixes for these vulnerabilities. It is important to note, that the easiest exploitation primitives are not available in our lab environment due to the hardening done on Container-Optimized OS. Note this program complements Android's VRP rewards, so exploits that work on Android could also be eligible for up to 250,000 USD (that's in addition to this program).
The mechanics are:
Connect to the kCTF VRP cluster, obtain root and read the flag (read this writeup for how it was done before, and this threat model for inspiration), and then submit your flag and a checksum of your exploit in this form.
(If applicable) report vulnerabilities to upstream.
We strongly recommend including a patch since that could qualify for an additional reward from our Patch Reward Program, but please report vulnerabilities upstream promptly once you confirm they are exploitable.
Report your finding to Google VRP once all patches are publicly available (we don't want to receive details of unpatched vulnerabilities ahead of the public.)
Provide the exploit code and the algorithm used to calculate the hash checksum.
A rough description of the exploit strategy is welcome.
Reports will be triaged on a weekly basis. If anyone has problems with the lab environment (if it's unavailable, technical issues or other questions), contact us on Discord in #kctf. You can read more details about the program here. Happy hunting!
Protecting your device information with Private Set Membership
Posted: October 28th, 2021, 7:00pm CEST by Kaylin Trychon
Posted by Kevin Yeo and Sarvar Patel, Private Computing Team
At Google, keeping you safe online is our top priority, so we continuously build the most advanced privacy-preserving technologies into our products. Over the past few years, we've utilized innovations in cryptographic research to keep your personal information private by design and secure by default. As part of this, we launched Password Checkup, which protects account credentials by notifying you if an entered username and password are known to have been compromised in a prior data breach. Using cryptographic techniques, Password Checkup can do this without revealing your credentials to anyone, including Google. Today, Password Checkup protects users across many platforms including Android, Chrome and Google Password Manager.
Another example is Private Join and Compute, an open source protocol which enables organizations to work together and draw insights from confidential data sets. Two parties are able to encrypt their data sets, join them, and compute statistics over the joint data. By leveraging secure multi-party computation, Private Join and Compute is designed to ensure that the plaintext data sets are concealed from all parties.
In this post, we introduce the next iteration of our research, Private Set Membership, as well as its open-source availability. At a high level, Private Set Membership considers the scenario in which Google holds a database of items, and user devices need to contact Google to check whether a specific item is found in the database. As an example, users may want to check membership of a computer program on a block list consisting of known malicious software before executing the program. Often, the set's contents and the queried items are sensitive, so we designed Private Set Membership to perform this task while preserving the privacy of our users.
Protecting your device information during enrollment
Beginning in Chrome 94, Private Set Membership will enable Chrome OS devices to complete the enrollment process in a privacy-preserving manner. Device enrollment is an integral part of the out-of-box experience that welcomes you when getting started with a Chrome OS device.
The device enrollment process requires checking membership of device information in encrypted Google databases, including checking if a device is enterprise enrolled or determining if a device was pre-packaged with a license. The correct end state of your Chrome OS device is determined using the results of these membership checks.
During the enrollment process, we protect your Chrome OS devices by ensuring no information ever leaves the device that may be decrypted by anyone else when using Private Set Membership. Google will never learn any device information and devices will not learn any unnecessary information about other devices. To our knowledge, this is the first instance of advanced cryptographic tools being leveraged to protect device information during the enrollment process.
A deeper look at Private Set Membership
Private Set Membership is built upon two cryptographic tools:
Homomorphic encryption is a powerful cryptographic tool that enables computation over encrypted data without the need for decryption. As an example, given the encryptions of values X and Y, homomorphic encryption enables computing the encryption of the sum of X and Y without ever needing to decrypt. This preserves privacy as the data remains concealed during the computation. Private Set Membership is built upon Google's open source homomorphic encryption library.
Oblivious hashing is a cryptographic technique that enables two parties to jointly compute a hash, H(K, x), where the sender holds the key, K, and the receiver holds the hash input, x. The receiver will obtain the hash, H(K, x), without learning the key K. At the same time, the input x will be hidden from the sender.
Take a look at how Private Set Membership utilizes homomorphic encryption and oblivious hashing to protect data below:
For a deeper look into the technology behind Private Set Membership, you can also access our open source code.
Privacy properties
By using Private Set Membership, the following privacy properties are obtained:
No data leaves the device when checking membership. We designed Private Set Membership using advanced cryptographic techniques to ensure that data never leaves the device in an unencrypted manner when performing membership checks. As a result, the data on your device will be concealed from everyone, including Google.
Devices learn only membership information and nothing else. Private Set Membership was designed to prevent devices from learning any unnecessary information about other devices when querying. For each query, devices learn only the results of the membership check and no other information.
Using Private Set Membership to solve more problems
Private Set Membership is a powerful tool that solves a fundamental problem in a privacy-preserving manner. This is just the beginning of what's possible using this technology. Private Set Membership can help preserve user privacy across a wide array of applications. For example:
Checking allow or block lists. In this setting, users check membership in an allow or block list to determine whether to proceed with the desired action. Private Set Membership enables this check without any information about the software leaving the device.
Control flows with conditional membership checks. Control flows are a common computer science concept that represent arbitrary computer programs with conditional branching. In many cases, the conditional branches require checking membership of sensitive data to determine the next step of the algorithm. By utilizing Private Set Membership, we enable execution of these algorithms while ensuring data never leaves the user's device.
We still have a ways to go before Private Set Membership is used for general membership checks by devices. At Google, we are exploring a number of potential use cases to protect your privacy using Private Set Membership. We are excited to continue advancing the state-of-the-art cryptographic research to keep you safe.
The work in this post is the result of a collaboration between a large group of current and former Google engineers, research scientists and others including: Amr Aboelkher, Asra Ali, Ghous Amjad, Yves Arrouye, Roland Bock, Xi Chen, Maksim Ivanov, Dennis Kalinichenko, Nirdhar Khazanie, Dawon Lee, Tancrède Lepoint, Lawrence Lui, Pavol Marko, Thiemo Nagel, Mariana Raykova, Aaron Segal, Joon Young Seo, Karn Seth, and Jason Wong.
Launching a collaborative minimum security baseline
Posted by Royal Hansen, Vice President, Security
According to an Opus and Ponemon Institute study, 59% of companies have experienced a data breach caused by one of their vendors or third parties. Outsourcing operations to third-party vendors has become a popular business strategy as it allows organizations to save money and increase operational efficiency. While these are positives for business operations, they do create significant security risks. These vendors have access to critical systems and customer data and so their security posture becomes equally as important.
Up until today, organizations of all sizes have had to design and implement their own security baselines for vendors that align with their risk posture. Unfortunately, this creates an impossible situation for vendors and organizations alike as they try to accommodate thousands of different requirements.
To solve this challenge, organizations across the industry teamed up to design Minimum Viable Secure Product or MVSP – a vendor-neutral security baseline that is designed to eliminate overhead, complexity and confusion during the procurement, RFP and vendor security assessment process by establishing minimum acceptable security baselines. With MVSP, the industry can increase clarity during each phase so parties on both sides of the equation can achieve their goals, and reduce the onboarding and sales cycle by weeks or even months.
MVSP was developed and is backed by companies across the industry, including Google, Salesforce, Okta, Slack and more. Our goal is to increase the minimum bar for security across the industry while simplifying the vetting process.
MVSP is a collaborative baseline focused on developing a set of minimum security requirements for business-to-business software and business process outsourcing suppliers. Designed with simplicity in mind, it contains only those controls that must, at a minimum, be implemented to ensure a reasonable security posture. MVSP is presented in the form of a minimum baseline checklist that can be used to verify the security posture of a solution.
How can MVSP help you?
Security teams measuring vendor offerings against a set of minimum security baselines
MVSP ensures that vendor selection and RFP include a minimum baseline that is backed by the industry. Communicating minimum requirements up front ensures everyone understands where they stand and that the expectations are clear.
Internal teams looking to measure your security against minimum requirements
MVSP provides a set of minimum security baselines that can be used as a checklist to understand gaps in the security of a product or service. This can be used to highlight opportunities for improvement and raise their visibility within the organization, with clearly defined benefits.
Procurement teams gathering information about vendor services
MVSP provides a single set of security-relevant questions that are publicly available and industry-backed. Aligning on a single set of baselines allows clearer understanding from vendors, resulting in a quicker and more accurate response.
Legal teams negotiating contractual controls
MVSP ensures expectations regarding minimum security controls are understood up front, reducing discussions of controls at the contract negotiation stage. Referencing an external baseline helps to simplify contract language and increases familiarity with the requirements.
Compliance teams documenting processes
MVSP provides an externally recognized and adopted set of security baselines on top of which to build your compliance efforts.
We welcome community feedback and interest from other organizations who want to contribute to the MVSP baseline. Together we can raise the minimum bar for security across the industry and make everyone safer.
The work in this post is the result of a collaboration between a large number of security practitioners across the industry including: Marat Vyshegorodtsev, Chris John Riley, Gabor Acs-Kurucz, Sebastian Oglaza, Gen Buckley, and Kevin Clark.
Google Protects Your Accounts – Even When You No Longer Use Them
Posted: October 5th, 2021, 3:00pm CEST by Kaylin Trychon
Posted by Sam Heft-Luthy, Product Manager, Privacy & Data Protection Office
What happens to our digital accounts when we stop using them? It's a question we should all ask ourselves, because when we are no longer keeping tabs on what's happening with old accounts, they can become targets for cybercrime.
In fact, quite a few recent high-profile breaches targeted inactive accounts. The Colonial Pipeline ransomware attack came through an inactive account that didn't use multifactor authentication, according to a consultant who investigated the incident. And in the case of the recent T-Mobile breach this summer, information from inactive prepaid accounts was accessed through old billing files. Inactive accounts can pose a serious security risk.
For Google users, Inactive Account Manager helps with that problem. You can decide when Google should consider your account inactive and whether Google should delete your data or share it with a trusted contact.
Here's How it WorksOnce you sign up for Inactive Account Manager, available in My Account settings, you are asked to decide three things:
When the account should be considered inactive: You can choose 3, 6, 12 or 18 months of inactivity before Google takes action on your account. Google will notify you a month before the designated time via a message sent to your phone and an email sent to the address you provide.
Who to notify and what to share: You can choose up to 10 people for Google to notify once your Google Account becomes inactive (they won't be notified during setup). You can also give them access to some of your data. If you choose to share data with your trusted contacts, the email will include a list of the selected data you wanted to share with them, and a link they can follow to download that data. This can include things like photos, contacts, emails, documents and other data that you specifically choose to share with your trusted contact. You can also choose to set up a Gmail AutoReply, with a custom subject and message explaining that you've ceased using the account.
If your inactive Google Account should be deleted: After your account becomes inactive, Google can delete all its content or send it to your designated contacts. If you've decided to allow someone to download your content, they'll be able to do so for 3 months before it gets deleted. If you choose to delete your Google Account, this will include your publicly shared data (for example, your YouTube videos, or blogs on Blogger). You can review the data associated with your account on the Google Dashboard. If you use Gmail with your account, you'll no longer be able to access that email once your account becomes inactive. You'll also be unable to reuse that Gmail username.
Setting up an Inactive Account plan is a simple step you can take to protect your data, secure your account in case it becomes inactive, and ensure that your digital legacy is shared with your trusted contacts in case you become unable to access your account. Our Privacy Checkup now reminds you to set up a plan for your account, and we'll send you an occasional reminder about your plan via email.
At Google, we are constantly working to keep you safer online. This October, as we celebrate Cybersecurity Awareness Month, we want to remind our users of the security and privacy controls they have at their fingertips. For more ways to enhance your security check out our top five safety tips and visit our Safety Center to learn all the ways Google helps keep you safer online, every day.
Introducing the Secure Open Source Pilot Program
Posted: October 1st, 2021, 4:22pm CEST by Kaylin Trychon
Posted by Meder Kydyraliev and Kim Lewandowski, Google Open Source Security Team
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:
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.
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.
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.
Announcing New Patch Reward Program for Tsunami Security Scanner
Posted: September 28th, 2021, 3:00pm CEST by Kaylin Trychon
Posted by Guoli Ma, Sebastian Lekies & Claudio Criscione, Google Vulnerability Management Team
One year ago, we published the Tsunami security scanner with the goal of detecting high severity, actively exploited vulnerabilities with high confidence. In the last several months, the Tsunami scanner team has been working closely with our vulnerability rewards program, Bug Hunters, to further improve Tsunami's security detection capabilities.
Today, we are announcing a new experimental Patch Reward Program for the Tsunami project. Participants in the program will receive patch rewards for providing novel Tsunami detection plugins and web application fingerprints. We hope this program will allow us to quickly extend the detection capabilities of the scanner to better benefit our users and uncover more vulnerabilities in their network infrastructure.
For this launch, we will accept two types of contributions:
Vulnerability detection plugins: In order to expand Tsunami scanner's detection capabilities, we encourage everyone who is interested in making contributions to this project to add new vulnerabilities detection plugins. All plugin contributions will be reviewed by our panel members in Google's Vulnerability Management team and the reward amount will be determined by the severity as well as the time sensitivity of the vulnerability.
Web application fingerprints: Several months ago, we added new web application fingerprinting capabilities to Tsunami that detect popular off-the-shelf web applications. It achieves this goal by matching application fingerprints against a database of known web application fingerprints. More fingerprint data is needed for this approach to support more web applications. You will be rewarded with a flat amount for each application added to the database.
As with other Security Reward Programs, rewards can be donated to charity—and we'll double your donation if you choose to do so. We'll run this program in iterations so that everyone interested has the opportunity to participate.
To learn more about this program, please check out our official rules and guidelines. And if you have any questions or suggestions for the program, feel free to contact us at tsunami-patch-rewards@google.com.
Distroless Builds Are Now SLSA 2
Posted: September 22nd, 2021, 6:00pm CEST by Kaylin Trychon
Posted by Priya Wadhwa and Appu Goundan, Google Open Source Security Team
A few months ago we announced that we started signing all distroless images with cosign, which allows users to verify that they have the correct image before starting the build process. Signing our images was our first step towards fully securing the distroless supply chain. Since then, we've implemented even more accountability in our supply chain and are excited to announce that distroless builds have achieved SLSA 2. SLSA is a security framework for increasing supply chain security, and Level 2 ensures that the build service is tamper resistant.
This means that in addition to a signature, each distroless image now has an associated signed provenance. This provenance is an in-toto attestation and includes information around how each image was built, what command was run, and what build system was used. It also includes any special parameters that were passed in, the exact commit the images were built at, and more. This provenance is a useful tool for builds that need to be audited in the future.
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",
"name": "gcr.io/distroless/base",
"digest": {
"sha256": "703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d"
"sha256": "d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce"
"sha256": "2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661"
"sha256": "4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91"
"sha256": "dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980"
"name": "gcr.io/distroless/base-debian10",
"sha256": "c9507268813f235b11e63a7ae01526b180c94858bd718d6b4746c9c0e8425f7a"
"name": "gcr.io/distroless/cc",
"sha256": "4af613acf571a1b86b1d3c50682caada0b82024e566c1c4c2fe485a70f3af47d"
"sha256": "2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb"
"name": "gcr.io/distroless/cc-debian10",
"name": "gcr.io/distroless/java",
"sha256": "deb41661be772c6256194eb1df6b526cc95a6f60e5f5b740dda2769b20778c51"
"name": "gcr.io/distroless/nodejs",
"sha256": "927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf"
"sha256": "f106757268ab4e650b032e78df0372a35914ed346c219359b58b3d863ad9fb58"
"name": "gcr.io/distroless/nodejs-debian10",
"name": "gcr.io/distroless/python3",
"sha256": "aa8a0358b2813e8b48a54c7504316c7dcea59d6ae50daa0228847de852c83878"
"name": "gcr.io/distroless/python3-debian10",
"name": "gcr.io/distroless/static",
"sha256": "9acfd1fdf62b26cbd4f3c31422cf1edf3b7b01a9ecee00a499ef8b7e3536914d"
"sha256": "e50641dbb871f78831f9aa7ffa59ec8f44d4cc33ae4ee992c9f4b046040e97f2"
"name": "gcr.io/distroless/static-debian10",
"predicate": {
"invocation": {
"MANIFEST_SUBSECTION={string 0 []}",
"CHAINS-GIT_COMMIT={string 976c1c9bc178ac0371d8888d69893145c3df09f0 []}",
"CHAINS-GIT_URL={string [https:] []}"
"recipe_uri": "task://distroless-provenance",
"event_id": "531c282f-806e-41e4-b3ad-b596c4283381",
"builder.id": "tekton-chains"
"recipe": {
"steps": [
"entryPoint": "#!/bin/sh\nset -ex\n\n# get the digests for a subset of images built, and store in the IMAGES result\ngo run provenance/provenance.go images $(params.MANIFEST_SUBSECTION) > $(results.IMAGES.path)\n",
"arguments": null,
"environment": {
"container": "provenance",
"image": "docker.io/library/golang@sha256:cb1a7482cb5cfc52527c5cdea5159419292360087d5249e3fe5472f3477be642"
"annotations": null
"buildStartedOn": "2021-09-16T00:03:04Z",
"buildFinishedOn": "2021-09-16T00:04:36Z"
"materials": [
"uri": "https://github.com/GoogleContainerTools/distroless",
"revision": "976c1c9bc178ac0371d8888d69893145c3df09f0"
As you might guess, our next step is getting distroless to SLSA 3, which will require adding non-falsifiable provenance and isolated builds to the distroless supply chain. Stay tuned for more!
Google Supports Open Source Technology Improvement Fund
Posted by Kaylin Trychon, Google Open Source Security Team
We recently pledged to provide $100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities. As part of this commitment, we are excited to announce our support of the Open Source Technology Improvement Fund (OSTIF) to improve security of eight open-source projects.
Google's support will allow OSTIF to launch the Managed Audit Program (MAP), which will expand in-depth security reviews to critical projects vital to the open source ecosystem. The eight libraries, frameworks and apps that were selected for this round are those that would benefit the most from security improvements and make the largest impact on the open-source ecosystem that relies on them. The projects include:
Git - de facto version control software used in modern DevOps.
Lodash - a modern JavaScript utility library with over 200 functions to facilitate web development, can be found in most environments that support JavaScript, which is most of the world wide web.
Laravel - a php web application framework that is used by many modern, full-stack web applications, including integrations with Google Cloud.
Slf4j - a logging facade for various Java logging frameworks.
Jackson-core & Jackson-databind - a JSON for Java, Streaming API, and extra shared components and the base for Jackson data-bind package.
Httpcomponents-core & [Httpcomponents-client] - these projects are responsible for creating and maintaining a toolset of low-level Java components focused on HTTP and associated protocols.
We are excited to help OSTIF build a safer open source environment for everyone. If you are interested in getting involved or learning more please visit the OSTIF blog.
Updates on our continued collaboration with NIST to secure the Software Supply Chain
Posted: August 26th, 2021, 7:47pm CEST by Kaylin Trychon
Posted by Eric Brewer and Dan Lorenc
Yesterday, we were honored to participate in President Biden's White House Cyber Security Summit where we shared recommendations to advance the administration's cybersecurity agenda. This included our commitment to invest $10 billion over the next five years to expand zero-trust programs, help secure the software supply chain, and enhance open-source security.
At Google, we've long advocated for securing the software supply chain both through our internal best practices and industry efforts that enhance the integrity and security of software. That's why we're thrilled to collaborate with the U.S. Department of Commerce's National Institute of Standards and Technology (NIST) to support and develop a new framework that will help to improve the security and integrity of the technology supply chain.
This builds on our previous work in June of this year, where we submitted four statements in response to the National Telecommunications and Information Administration (NTIA) and NIST's call for position papers to help guide adoption of new software supply chain security standards and guidelines that fulfill components of the Executive Order on Improving the Nation's Cybersecurity.
The papers lay out concrete ways to increase the nation's cybersecurity, based on Google's experience building secure by design systems for our users and enterprise customers. Each of the suggestions are enactable solutions for software supply chain security, and were drawn from Google's research and innovations in engineering away entire classes of vulnerabilities.
NIST and NTIA also released their guidelines in July for several of the Executive Order's target areas (SBOM Minimum Elements, Critical Software Guidelines, Developer Verification of Software), incorporating specific recommendations from Google. Below are summaries of each of Google's position papers, and background on our contributions and impact in each area.
High-Confidence, Scalable Secure Development
Instead of being reactive to vulnerabilities, we should eliminate them proactively with secure languages, platforms, and frameworks that stop entire classes of bugs.
Preventing problems before they leave the developer's keyboard is safer and more cost effective than trying to fix vulnerabilities and their fallout. (Consider the enormous impact of the SolarWinds attack, which is predicted to take $100 billion to remediate.) Google promotes designs that are secure by default and impervious to simple errors that can lead to security vulnerabilities.
We want to see secure systems used as widely as possible, so we have invested in initiatives such as getting Rust into the Linux Kernel, published research papers, and shared guidance on secure frameworks.
Security Measures for Critical Software
Critical software does not exist in a vacuum; we must also harden the broader systems and run environments. Our paper outlines a list of actionable steps for critical software's configuration, the privileges with which it runs, and the network(s) to which it is connected.
Our suggestions are based on practices that have withstood the tests of time and scale, such as in our Google Cloud Products, built on one of the industry's most trusted clouds.
Google contributes to open-source tools that help maintainers adopt these practices, such as gVisor for sandboxing, and GLOME for authentication and authorization. Additionally, to share the knowledge we have gained securing systems that serve billions of users, we released our book Building Secure and Reliable Systems, a resource for any organization that wants to design systems that are fundamentally secure, reliable, and scalable.
Software Source Code Testing
Continuous fuzzing is indispensable for identifying bugs and catching vulnerabilities before attackers do. We also suggest securing dependencies using automated tools such as Scorecards, Dependabot, and OSV.
Google has made huge contributions to the field of fuzzing, and has found tens of thousands of bugs with tools like libFuzzer and ClusterFuzz.
We have made continuous fuzzing available to all developers through OSS-Fuzz, and are funding integration costs and fuzzing internships. We are leading a shift in industry support: on top of bug bounties, which are rewards programs for finding bugs, we have also added patch rewards, money that can help fund maintainers remediate uncovered bugs.
Software Supply Chain Integrity
Google strongly encourages adoption of SLSA, an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. Four "SLSA Levels" provide incrementally adoptable guidelines that each raise the bar on security standards for open-source software.
SLSA is based on Google's internal framework Binary Authorization for Borg (BAB) that ensures that all software packages used by the company meet high integrity standards. Given BAB's success, we have adapted the framework to work for systems beyond Google and released it as SLSA to help protect other organizations and platforms.
We have shared many of Google's practices for security and reliability in our Site Reliability Engineering book. Following our recent introduction of SLSA to the wider public, we are looking forward to making improvements in response to community feedback.
Minimum Requirements for SBOMs
Google submitted an additional paper in response to the NTIA's request for comments on creating SBOMs, which will give users information about a software package's contents. Modern development requires different approaches than classic packaged software, which means SBOMs must also deal with intermediate artifacts like containers and library dependencies.
SBOMs need a reasonable signal-to-noise ratio: if they contain too much information, they won't be useful, so we urge the NTIA to establish both minimum and maximum requirements on granularity and depth for specific use-cases. We also recommend considerations for the creation of trustworthy SBOMs, such as using verifiable data generation methods to capture metadata, and preparing for the automation and tooling technologies that will be key for widespread SBOM adoption.
Improving Everyone's Security
We are committed to helping advance collective cybersecurity. We also realize that too many guidelines and lists of best practices can become overwhelming, but any incremental changes in the right direction make a real difference. We encourage companies and maintainers to start evaluating today where they stand on the most important security postures, and to make improvements with the guidance of these papers in the areas of greatest risk. No single entity can fix the problems we all face in this area, but by being open about our practices and sharing our research and tools, we can all help raise the standards for our collective security.
AllStar: Continuous Security Policy Enforcement for GitHub Projects
Posted by Mike Maraya, Google Open Source Security Team
As an active member of the open source software (OSS) community, Google recognizes the growing threat of software supply chain attacks against OSS we use and develop. Building on our efforts to improve OSS security with an end-to-end framework (SLSA), metrics (Scorecards), and coordinated vulnerability disclosure (guide), we are excited to announce Allstar.
Allstar is a GitHub app that continuously enforces security policy settings through selectable automated enforcement actions. Allstar is already filing and closing security issues">[https%3A%2F%2Fgithub.com%2Fossf%2Fallstar%22&type=issues">issues] for Envoy and GoogleContainerTools, with more organizations and repositories lined up.
See the OpenSSF announcement for more information on Allstar.
Simplifying Titan Security Key options for our users
Posted: August 9th, 2021, 6:00pm CEST by Kaylin Trychon
Posted by Christiaan Brand, Product Manager, Google Cloud
Today we are excited to announce some changes to our lineup of Titan Security Keys on the Google Store which provide a simpler experience and make choosing the right security key for you even easier. We will now offer only two types of Titan Security Keys: a USB-A and a USB-C version. Both of these keys have Near Field Communication (NFC) functionality, which allows you to use it with most mobile devices by simply tapping it on the back of your mobile device in order to sign in securely. These keys will be available for all users starting tomorrow, August 10.
In 2018, Google introduced the Titan Security Key as a direct defense against credential phishing. Phishing occurs when an attacker tries to trick you into giving them your username and password, and it remains one of the easiest and most successful ways of breaching accounts online. Paired with our Advanced Protection Program and its industry-leading automatic protections, the Titan Security Key remains one of the best ways to keep your Google Account safe.
Introducing new Titan Security Key options
Since NFC functionality is now supported by a wide range of Android phones and iPhones, we are discontinuing the Bluetooth Titan Security Key and focusing on the easier and more widely available NFC capability. However, for existing users with our Bluetooth Titan Security Keys, these will continue to work with Bluetooth and will continue to work as an NFC key on most modern mobile devices. Applicable warranties for existing Bluetooth Titan Security Keys will continue to be honored per their terms. All Titan Security Keys are built with a hardware secure element chip that includes firmware engineered by Google to verify the key's integrity.
If you have a computer with USB-A ports, we recommend you get the USB-A + NFC security key:
If you have a computer with USB-C ports, we recommend you get the USB-C + NFC security key:
If you have an iPad with a USB-C connector you can use the USB-C Titan Security Key. If you have an iPad with a lightning connector, it's recommended to get a USB-A Titan Security Key with an Apple Lightning adapter:
To purchase a Titan Security Key, visit the Google Store. The USB-A+NFC key,which includes a USB-A to USB-C adapter, is available for $30 and the USB-C+NFC key retails for $35.
To learn more about how security keys can help protect you against phishing, visit the Titan Security Key product page.
Linux Kernel Security Done Right
Posted: August 3rd, 2021, 6:00pm CEST by Kaylin Trychon
Posted by Kees Cook, Software Engineer, Google Open Source Security Team
To borrow from an excellent analogy between the modern computer ecosystem and the US automotive industry of the 1960s, the Linux kernel runs well: when driving down the highway, you're not sprayed in the face with oil and gasoline, and you quickly get where you want to go. However, in the face of failure, the car may end up on fire, flying off a cliff.
As we approach its 30th Anniversary, Linux still remains the largest collaborative development project in the history of computing. The huge community surrounding Linux allows it to do amazing things and run smoothly. What's still missing, though, is sufficient focus to make sure that Linux fails well too. There's a strong link between code robustness and security: making it harder for any bugs to manifest makes it harder for security flaws to manifest. But that's not the end of the story. When flaws do manifest, it's important to handle them effectively.
Rather than only taking a one-bug-at-a-time perspective, preemptive actions can stop bugs from having bad effects. With Linux written in C, it will continue to have a long tail of associated problems. Linux must be designed to take proactive steps to defend itself from its own risks. Cars have seat belts not because we want to crash, but because it is guaranteed to happen sometimes.
Even though everyone wants a safe kernel running on their computer, phone, car, or interplanetary helicopter, not everyone is in a position to do something about it. Upstream kernel developers can fix bugs, but have no control over what a downstream vendor chooses to incorporate into their products. End users get to choose their products, but don't usually have control over what bugs are fixed nor what kernel is used (a problem in itself). Ultimately, vendors are responsible for keeping their product's kernels safe.
The statistics of tracking and fixing distinct bugs are sobering. The stable kernel releases ("bug fixes only") each contain close to 100 new fixes per week. Faced with this high rate of change, a vendor can choose to ignore all the fixes, pick out only "important" fixes, or face the daunting task of taking everything.
Fix nothing?
With the preponderance of malware, botnets, and state surveillance targeting flawed software, it's clear that ignoring all fixes is the wrong "solution." Unfortunately this is the very common stance of vendors who see their devices as just a physical product instead of a hybrid product/service that must be regularly updated.
Fix important flaws?Between the dereliction of doing nothing and the assumed burden of fixing everything, the traditional vendor choice has been to cherry-pick only the "important" fixes. But what constitutes "important" or even relevant? Just determining whether to implement a fix takes developer time.
The prevailing wisdom has been to choose vulnerabilities to fix based on the Mitre CVE list, presuming all important flaws (and therefore fixes) would have an associated CVE. However, given the volume of flaws and their applicability to a particular system, not all security flaws have CVEs assigned, nor are they assigned in a timely manner. Evidence shows that for Linux CVEs, more than 40% had been fixed before the CVE was even assigned, with the average delay being over three months after the fix. Some fixes went years without having their security impact recognized. On top of this, product-relevant bugs may not even classify for a CVE. Finally, upstream developers aren't actually interested in CVE assignment; they spend their limited time actually fixing bugs.
A vendor relying on cherry-picking is all but guaranteed to miss important vulnerabilities that others are actively fixing, which is almost worse than doing nothing since it creates the illusion that security updates are being appropriately handled.
Fix everything!So what is a vendor to do? The answer is simple, if painful: continuously update to the latest kernel release, either major or stable. Tracking major releases means gaining security improvements along with bug fixes, while stable releases are bug fixes only. For example, although modern Android phones ship with kernels that are based on major releases from almost two to four years earlier, Android vendors do now, thankfully, track stable kernel releases. So even though the features being added to newer major kernels will be missing, all the latest stable kernel fixes are present.
Performing continuous kernel updates (major or stable) understandably faces enormous resistance within an organization due to fear of regressions—will the update break the product? The answer is usually that a vendor doesn't know, or that the update frequency is shorter than their time needed for testing. But the problem with updating is not that the kernel might cause regressions; it's that vendors don't have sufficient test coverage and automation to know the answer. Testing must take priority over individual fixes.Make it happenOne question remains: how to possibly support all the work continuous updates require? As it turns out, it's a simple resource allocation problem, and is more easily accomplished than might be imagined: downstream redundancy can be moved into greater upstream collaboration.
More engineers for fixing bugs earlierWith vendors using old kernels and backporting existing fixes, their engineering resources are doing redundant work. For example, instead of 10 companies each assigning one engineer to backport the same fix independently, those developer hours could be shifted to upstream work where 10 separate bugs could be fixed for everyone in the Linux ecosystem. This would help address the growing backlog of bugs. Looking at just one source of potential kernel security flaws, the syzkaller dashboard shows the number of open bugs is currently approaching 900 and growing by about 100 a year, even with about 400 a year being fixed.
More engineers for code reviewBeyond just squashing bugs after the fact, more focus on upstream code review will help stem the tide of their introduction in the first place, with benefits extending beyond just the immediate bugs caught. Capable code review bandwidth is a limited resource. Without enough people dedicated to upstream code review and subsystem maintenance tasks, the entire kernel development process bottlenecks.
Long-term Linux robustness depends on developers, but especially on effective kernel maintainers. Although there is effort in the industry to train new developers, this has been traditionally justified only by the "feature driven" jobs they can get. But focusing only on product timelines ultimately leads Linux into the Tragedy of the Commons. Expanding the number of maintainers can avoid it. Luckily the "pipeline" for new maintainers is straightforward.
Maintainers are built not only from their depth of knowledge of a subsystem's technology, but also from their experience with mentorship of other developers and code review. Training new reviewers must become the norm, motivated by making upstream review part of the job. Today's reviewers become tomorrow's maintainers. If each major kernel subsystem gained four more dedicated maintainers, we could double productivity.
More engineers for testing and infrastructureAlong with more reviewers, improving Linux's development workflow is critical to expanding everyone's ability to contribute. Linux's "email only" workflow is showing its age, but the upstream development of more automated patch tracking, continuous integration, fuzzing, coverage, and testing will make the development process significantly more efficient.
Additionally, instead of testing kernels after they're released, it's more effective to test during development. When tests are performed against unreleased kernel versions (e.g. linux-next) and reported upstream, developers get immediate feedback about bugs. Fixes can be developed before a flaw is ever actually released; it's always easier to fix a bug earlier than later.
This "upstream first" approach to product kernel development and testing is extremely efficient. Google has been successfully doing this with Chrome OS and Android for a while now, and is hardly alone in the industry. It means feature development happens against the latest kernel, and devices are similarly tested as close as possible to the latest upstream kernels, all avoiding duplicated "in-house" effort.
More engineers for security and toolchain developmentBesides dealing reactively to individual bugs and existing maintenance needs, there is also the need to proactively eliminate entire classes of flaws, so developers cannot introduce these types of bugs ever again. Why fix the same kind of security vulnerability 10 times a year when we can stop it from ever appearing again?
Over the last few years, various fragile language features and kernel APIs have been eliminated or replaced (e.g. VLAs, switch fallthrough, addr_limit). However, there is still plenty more work to be done. One of the most time-consuming aspects has been the refactoring involved in making these usually invasive and context-sensitive changes across Linux's 25 million lines of code.
Beyond kernel code itself, the compiler and toolchain also need to grow more defensive features (e.g. variable zeroing, CFI, sanitizers). With the toolchain technically "outside" the kernel, its development effort is often inappropriately overlooked and underinvested. Code safety burdens need to be shifted as much as possible to the toolchain, freeing humans to work in other areas. On the most progressive front, we must make sure Linux can be written in memory-safe languages like Rust.
Don't wait another minuteIf you're not using the latest kernel, you don't have the most recently added security defenses (including bug fixes). In the face of newly discovered flaws, this leaves systems less secure than they could have been. Even when mediated by careful system design, proper threat modeling, and other standard security practices, the magnitude of risk grows quickly over time, leaving vendors to do the calculus of determining how old a kernel they can tolerate exposing users to. Unless the answer is "just abandon our users," engineering resources must be focused upstream on closing the gap by continuously deploying the latest kernel release.
Based on our most conservative estimates, the Linux kernel and its toolchains are currently underinvested by at least 100 engineers, so it's up to everyone to bring their developer talent together upstream. This is the only solution that will ensure a balance of security at reasonable long-term cost.
A new chapter for Google's Vulnerability Reward Program
Posted: July 27th, 2021, 3:00pm CEST by Kaylin Trychon
Posted by Jan Keller, Technical Program Manager, Google VRP
A little over 10 years ago, we launched our Vulnerability Rewards Program (VRP). Our goal was to establish a channel for security researchers to report bugs to Google and offer an efficient way for us to thank them for helping make Google, our users, and the Internet a safer place. To recap our progress on these goals, here is a snapshot of what VRP has accomplished with the community over the past 10 years:
Total bugs rewarded: 11,055
Number of rewarded researchers: 2,022
Representing 84 different countries
Total rewards: $29,357,516
To celebrate our anniversary and ensure the next 10 years are just as (or even more) successful and collaborative, we are excited to announce the launch of our new platform, bughunters.google.com.
This new site brings all of our VRPs (Google, Android, Abuse, Chrome and Play) closer together and provides a single intake form that makes it easier for bug hunters to submit issues. Other improvements you will notice include:
More opportunities for interaction and a bit of healthy competition through gamification, per-country leaderboards, awards/badges for certain bugs and more!
A more functional and aesthetically pleasing leaderboard. We know a lot of you are using your achievements in the VRP to find jobs (we're hiring!) and we hope this acts as a useful resource.
A stronger emphasis on learning: Bug hunters can improve their skills through the content available in our new Bug Hunter University
Streamlined publication process: we know the value that knowledge sharing brings to our community. That's why we want to make it easier for you to publish your bug reports.
Swag will now be supported for special occasions (we heard you loud and clear!)
We also want to take a moment to shine a light on some aspects of the VRP that are not yet well-known, such as:
Submitting patches to open-source software is eligible for a reward
We have rewards for research papers on the security of open source
Your open-source software might be eligible for a subsidy
When we launched our very first VRP, we had no idea how many valid vulnerabilities - if any - would be submitted on the first day. Everyone on the team put in their estimate, with predictions ranging from zero to 20. In the end, we actually received more than 25 reports, taking all of us by surprise.
Since its inception, the VRP program has not only grown significantly in terms of report volume, but the team of security engineers behind it has also expanded – including almost 20 bug hunters who reported vulnerabilities to us and ended up joining the Google VRP team.
That is why we are thrilled to bring you this new platform, continue to grow our community of bug hunters and support the skill development of up-and-coming vulnerability researchers.
Thanks again to the entire Google bug hunter community for making our vulnerability rewards program successful. As you continue to play around with the new site and reporting system, tell us about it - we would love to hear your feedback. Until next time, keep on finding those bugs!
Advancing an inclusive, diverse security industry
Posted by Sarah Morales, Community Outreach Manager, Security
It's no secret that lack of diversity in corporate America is a well-documented problem and improvements have been slow. To help improve female representation in the cybersecurity industry, Google teamed up with Women in Cybersecurity (WiCyS) and SANS Institute a year ago to establish the Security Training Scholarship Program.
The multi-stage security training program set participants on a path to launch and advance their careers in cybersecurity through skills development, introducing them to fundamental cybersecurity concepts with interactive challenges like Capture the Flag (CTF) and the SANS CyberStart Game, which introduces topics such as Linux, web attacks, programming, forensics, and more. Mentors and peers guide the participants through each stage of the program and top qualifiers then graduate and receive access to the SANS foundational security training courses, which readies and prepares these women for their first roles in the security industry. The goal is to get them employed in cybersecurity within the next 1.5 years and to create a powerful network of women in the field – in essence, drawing more women to the industry and helping to close the talent gap.
As the inaugural program comes to an end, we are proud to report that its overall impact includes:
112 people received training-based scholarship
15 Full Scholarship Recipients received the full course training, which includes:
CyberStart Game and SANS BootUp CTF
SANS SEC275 Foundations & Exam
SANS 401 Security Essentials Bootcamp and GSEC
Elective - SANS SEC504/GCIH, SEC488/GCLD, SEC560/GPEN, or SEC548/GWAPT
24 certifications earned to date with 100% pass rate, with average score on GSEC 90%
Since 2013, only 2 people have scored 99% on GIAC Certified Incident Handler (GCIH) one is a WiCyS Scholarship Recipient
1/3 of students were employed in direct information security roles before the program ended
100% of Full Scholarship Recipients intend to have long term careers in information security (15+ years)
Participants praise the program's strong networking component where they can support one another, share best practices, ask questions from SANS security experts and receive industry insight from members across Google's security team. As Lynn Dohm, executive director of WiCyS, told us, "You cannot put a price tag on the power of community, and last year's WiCyS Security Training Program proved just that."
Here at Google, we are inspired by the dedication and passion the scholarship recipients have shown throughout the program and are eager to see what they accomplish throughout their careers.
Elizabeth Beattie, who was part of the inaugural program told us, "I learned that, as part of my scholarship program with WiCyS, SANS Institute and Google, I've been awarded a scholarship to attend the WiCyS 2021 conference in September. In fact, I've volunteered to co-author a panel there with some of my amazing fellow recipients. And the crowning achievement? Tonight, I passed my first GIAC certification (GSEC)!"
Despite these great results, we know there is still a lot of work to be done to help educate and develop a more inclusive information security workforce. So this year we are expanding the Security Trainings Scholarship Program to help us reach even more women and generate a steady stream of talent in the field of information security. This expansion would not have been possible without the added support of Facebook and Bloomberg, who have come on board this year to boost this important program.
"We are thrilled to scale the program this year, powered by scholarships from Google, Bloomberg, and Facebook," said Dohm. "Now, more WiCyS members will be able to dive deep and change the trajectory of their career in less than a year, all within a cohort setting with extensive support and resources provided by mentors and colleagues. That's what empowerment looks like, and we are thrilled that these three incredible strategic partners of WiCyS can make this happen for not only the WiCyS community, but also for the sake of the cybersecurity workforce at large."
The next round of scholarships is open through August 2, 2021. To learn more and apply, please visit the WiCyS application page. We can't wait to meet the next cohort of recipients.
Verifiable design in modern systems
Posted by Ryan Hurst, Production Security Team
The way we design and build software is continually evolving. Just as we now think of security as something we build into software from the start, we are also increasingly looking for new ways to minimize trust in that software. One of the ways we can do that is by designing software so that you can get cryptographic certainty of what the software has done.
In this post, we'll introduce the concept of verifiable data structures that help us get this cryptographic certainty. We'll describe some existing and new applications of verifiable data structures, and provide some additional resources we have created to help you use them in your own applications.
A verifiable data structure is a class of data structure that lets people efficiently agree, with cryptographic certainty, that the data contained within it is correct.
Merkle Trees are the most famous of these and have been used for decades because they can enable efficient verification that a particular piece of data is included among many records - as a result they also form the basis of most blockchains.
Although these verifiable data structures are not new, we now have a new generation of developers who have discovered them and the designs they enable -- further accelerating their adoption.
These verifiable data structures enable building a new class of software that have elements of verifiability and transparency built into the way they operate. This gives us new ways to defend against coercion, introduce accountability to existing and new ecosystems, and make it easier to demonstrate compliance to regulators, customers and partners.
Certificate Transparency is a great example of a non-blockchain use of these verifiable data structures at scale to secure core internet infrastructure. By using these patterns, we have been able to introduce transparency and accountability to an existing system used by everyone without breaking the web.
Unfortunately, despite the capabilities of verifiable data structures and the associated patterns, there are not many resources developers can use to design, build, and deploy scalable and production-quality systems based on them.
To address this gap we have generalized the platform we used to build Certificate Transparency so it can be applied to other classes of problems as well. Since this infrastructure has been used for years as part of this ecosystem it is well understood and can be deployed confidently in production systems.
This is why we have seen solutions in areas of healthcare, financial services, and supply chain leverage this platform. Beyond that, we have also applied these patterns to bring these transparency and accountability properties to other problems within our own products and services.
To this end, in 2019, we used this platform to bring supply chain integrity to the Go language ecosystem via the Go Checksum Database. This system allows developers to have confidence that the package management systems supporting the Go ecosystem can't intentionally, arbitrarily, or accidentally start giving out the wrong code without getting caught. The reproducibility of Go builds makes this particularly powerful as it enables the developer to ensure what is in the source repository matches what is in the package management system. This solution delivers a verifiable chaiin all the way from the source repositories to the final compiled artifacts.
Another example of using these patterns is our recently announced partnership with the Linux Foundation on Sigstore. This project is a response to the ever-increasing influx of supply chain attacks on the Open Source ecosystem.
Supply chain attacks have been possible because there are weaknesses at every link in the chain. Components like build systems, source code management tools, and artifact repositories all need to be treated as critical production environments, because they are. To address this, we first need to make it possible to verify provenance along the entire chain and the goal of the Sigstore effort is to enable just that.
We are now working on using these patterns and tools to enable hardware-enforced supply chain integrity for device firmware, which we hope will discourage supply chain attacks on the devices, like smartphones, that we rely on every day by bringing transparency and accountability to their firmware supply chain.
In all of the above examples, we are using these verifiable data structures to ensure the integrity of artifacts in the supply chain. This enables customers, auditors, and internal security teams to be confident that each actor in the supply chain has lived up to their responsibilities. This helps earn the trust of those that rely on the supply chain, discourages insiders from using their position as it increases the chance they will get caught, introduces accountability, and enables proving the associated systems continually meet their compliance obligations.
When using these patterns the most important task is defining what data should be logged. This is why we put together a taxonomy and modeling framework which we have found to be helpful in designing verifiability into the systems we discussed above, and which we hope you will find valuable too.
Please take a look at the transparency.dev website to learn about these verifiable data structures, and the tools and guidance we have put together to help use them in your own applications.
Measuring Security Risks in Open Source Software: Scorecards Launches V2
Posted: July 1st, 2021, 3:00pm CEST by Kaylin Trychon
Posted by Kim Lewandowski, Azeem Shaikh, Laurent Simon, Google Open Source Security Team
Contributors to the Scorecards project, an automated security tool that produces a "risk score" for open source projects, have accomplished a lot since our launch last fall. Today, in collaboration with the Open Source Security Foundation community, we are announcing Scorecards v2. We have added new security checks, scaled up the number of projects being scored, and made this data easily accessible for analysis.
With so much software today relying on open-source projects, consumers need an easy way to judge whether their dependencies are safe. Scorecards helps reduce the toil and manual effort required to continually evaluate changing packages when maintaining a project's supply chain. Consumers can automatically assess the risks that dependencies introduce and use this data to make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.
Identifying Risks
Since last fall, Scorecards' coverage has grown; we've added several new checks, following the Know, Prevent, Fix framework proposed by Google earlier this year, to prioritize our additions:
Malicious contributors
Contributors with malicious intent or compromised accounts can introduce potential backdoors into code. Code reviews help mitigate against such attacks. With the new Branch-Protection check, developers can verify that the project enforces mandatory code review from another developer before code is committed. Currently, this check can only be run by a repository admin due to GitHub API limitations. For a third-party repository, use the less informative Code-Review check instead.
Vulnerable code
Despite best efforts by developers and peer reviews, vulnerable code can enter source control and remain undetected. That's why it's important to enable continuous fuzzing and static code analysis to catch bugs early in the development lifecycle. We have added checks to detect if a project uses Fuzzing and SAST tools as part of their CI/CD system.
Build system compromise
A common CI/CD solution used by GitHub projects is GitHub Actions. A danger with these action workflows is that they may handle untrusted user input. Meaning, an attacker can craft a malicious pull request to gain access to the privileged GitHub token, and with it the ability to push malicious code to the repo without review. To mitigate this risk, Scorecard's Token-Permissions prevention check now verifies that the GitHub workflows follow the principle of least privilege by making GitHub tokens read-only by default.
Bad dependencies
Any software is as secure as its weakest dependency. This may sound obvious, but the first step to knowing our dependencies is simply to declare them... and have our dependencies declare them too. Once we have this provenance information, we can assess the risks of our software and mitigate those risks. Unfortunately, there are several widely-used anti-patterns that break this provenance principle. The first of these anti-patterns is checked-in binaries -- as there's no way to easily verify or check the contents of the binary in the project. Scorecards provides Binary-Artifacts check for testing this.
Another anti-pattern is the use of curl | bash in scripts which dynamically pulls dependencies. Cryptographic hashes let us pin our dependencies to a known value: if this value ever changes, the build system will detect it and refuse to build. Pinning dependencies is useful everywhere we have dependencies: not just during compilation, but also in Dockerfiles, CI/CD workflows, etc. Scorecards checks for these anti-patterns with the Frozen-Deps check. This check is helpful for mitigating against malicious dependency attacks such as the recent CodeCov attack.
Even with hash-pinning, hashes need to be updated once in a while when dependencies patch vulnerabilities. Tools like dependabot or renovatebot give us the opportunity to review and update the hashes. The Scorecards Automated-Dependency-Update check verifies that developers rely on such tools to update their dependencies.
It is important to know vulnerabilities in a project before uptaking it as a dependency. Scorecards can provide this information via the new Vulnerabilities check, without the need to subscribe to a vulnerability alert system.
Scaling the impact
To date, the Scorecards project has scaled up to evaluate security criteria for over 50,000 open source projects. In order to scale this project, we undertook a massive redesign of our architecture and used a PubSub model which achieved horizontal scalability and higher throughput. This fully automated tool periodically evaluates critical open source projects and exposes the Scorecards check information through a public BigQuery dataset which is refreshed weekly.
This data can be retrieved using the bq command line tool. The following example shows how to export data for the Kubernetes project. Substitute the url for the repo to export data from a different project:
$ bq query --nouse_legacy_sql 'SELECT Repo, Date, Checks FROM openssf.scorecardcron.scorecard_latest WHERE Repo="github.com/kubernetes/kubernetes"'
To export the latest data on all analyzed projects, see instructions here.
How does the internet measure up?Scorecards data for available projects is now included in the recently announced Google Open Source Insights project and also showcased in OpenSSF Security Metrics project. The data on these sites shows that there are still important security gaps to fill, even in widely used packages like Kubernetes.
We also analyzed Scorecards data through Google Data Studio -- one of our data analysis and visualization tools.The diagram below shows a breakdown of the checks that were run and the pass/fail outcome for the 50,000 repositories:
As we can see, a lot needs to be done to improve the security of these critical projects. A large number of these projects are not continuously fuzzed, do not define a security policy for reporting vulnerabilities, and do not pin dependencies, to name just a few common problems. We all need to come together as an industry to drive awareness of these widespread security risks, and to make improvements that will benefit everyone.
Scorecards in ActionSeveral large projects have adopted Scorecards and are keeping us updated on their experiences with it. Below are some examples of Scorecards in action:
Early on we talked about how the Envoy maintainers adopted Scorecards for their project and integrated it within their policy on introducing new dependencies. Since then, pull requests introducing new dependencies to Envoy must get approval from a dependency maintainer who uses Scorecards to evaluate the dependency against a set of criteria.
In addition, Envoy also got right to work in improving its own security health metrics according to its own Scorecards evaluation, and is now pinning C++ dependencies and requiring pip hashes for python dependencies. Github actions are also pinned in the continuous integration flow.
Previously, Envoy had created a tool that outputs Scorecards data on its dependencies as a CSV that can be used to generate a table of results:
Now with more project data, Envoy is able to automatically generate up-to-date Scorecard information about its dependencies and publish it in documentation, like the following:
We improved our own score for the Scorecards! For example, we are now pinning our own dependencies by hash (e.g. docker dependencies, workflow dependencies) to prevent CodeCov style attacks. We've also included a Security Policy based on this recommended template.
Get involvedWe look forward to continuing to grow the Scorecards community. The project now has contributions from 23 developers. Thank you to Azeem, Naveen, Laurent, Asra and Chris for their work building these new features and scaling Scorecards.
If you would like to join the fun, check out these good first timer issues.
If you would like us to help you run Scorecards on specific projects, please submit a GitHub pull request to add those projects here.
Last but not least, we have a lot of ideas and many more checks we'd like to add, but we want to hear from you. Tell us which checks you would like to see in the next version of Scorecards.
There are a couple of big enhancements we're especially excited about:
Scorecards Badges - GitHub badges to show off compliance
Integration with CI/CD and GitHub Code Scanning Results
Integration with Allstar project - GitHub App for enforcing security policies
Thanks again to the entire Scorecards community and the OpenSSF for making this project successful. If you're adopting and improving the score of the projects you maintain, tell us about it. Until next time, keep on improving those scores!
Announcing a unified vulnerability schema for open source
Posted: June 24th, 2021, 3:00pm CEST by Kaylin Trychon
Posted by Oliver Chang, Google Open Source Security team and Russ Cox, Go team
In recent months, Google has launched several efforts to strengthen open-source security on multiple fronts. One important focus is improving how we identify and respond to known security vulnerabilities without doing extensive manual work. It is essential to have a precise common data format to triage and remediate security vulnerabilities, particularly when communicating about risks to affected dependencies—it enables easier automation and empowers consumers of open-source software to know when they are impacted and make security fixes as soon as possible.
We released the Open Source Vulnerabilities (OSV) database in February with the goal of automating and improving vulnerability triage for developers and users of open source software. This initial effort was bootstrapped with a dataset of a few thousand vulnerabilities from the OSS-Fuzz project. Implementing OSV to communicate precise vulnerability data for hundreds of critical open-source projects proved the success and utility of the format, and garnered feedback to help us improve the project; for example, we dropped the Cloud API key requirement, making the database even easier to access by more users. The community response also showed that there was broad interest in extending the effort further.
Today, we're excited to announce a new milestone in expanding OSV to several key open-source ecosystems: Go, Rust, Python, and DWF. This expansion unites and aggregates four important vulnerability databases, giving software developers a better way to track and remediate the security issues that affect them. Our effort also aligns with the recent US Executive Order on Improving the Nation's Cybersecurity, which emphasized the need to remove barriers to sharing threat information in order to strengthen national infrastructure. This expanded shared vulnerability database marks an important step toward creating a more secure open-source environment for all users.
A simple, unified schema for describing vulnerabilities precisely
As with open source development, vulnerability databases in open source follow a distributed model, with many ecosystems and organizations creating their own database. Since each uses their own format to describe vulnerabilities, a client tracking vulnerabilities across multiple databases must handle each completely separately. Sharing of vulnerabilities between databases is also difficult.
The Google Open Source Security team, Go team, and the broader open-source community have been developing a simple vulnerability interchange schema for describing vulnerabilities that's designed from the beginning for open-source ecosystems. After starting work on the schema a few months ago, we requested public feedback and received hundreds of comments. We have incorporated the input from readers to arrive at the current schema:
"id": string,
"modified": string,
"published": string,
"withdrawn": string,
"aliases": [ string ],
"related": [ string ],
"ecosystem": string,
"purl": string,
"summary": string,
"details": string,
"affects": [ {
"ranges": [ {
"type": string,
"repo": string,
"introduced": string,
"fixed": string
"versions": [ string ]
"references": [ {
"url": string
"ecosystem_specific": { see spec },
"database_specific": { see spec },
This new vulnerability schema aims to address some key problems with managing vulnerabilities in open source. We found that there was no existing standard format which:
Enforces version specification that precisely matches naming and versioning schemes used in actual open source package ecosystems. For instance, matching a vulnerability such as a CVE to a package name and set of versions in a package manager is difficult to do in an automated way using existing mechanisms such as CPEs.
Can be used to describe vulnerabilities in any open source ecosystem, while not requiring ecosystem-dependent logic to process them.
Is easy to use by both automated systems and humans.
With this schema we hope to define a format that all vulnerability databases can export. A unified format means that vulnerability databases, open source users, and security researchers can easily share tooling and consume vulnerabilities across all of open source. This means a more complete view of vulnerabilities in open source for everyone, as well as faster detection and remediation times resulting from easier automation.
The vulnerability schema spec has gone through several iterations, and we are inviting further feedback as it gets closer to finalized. A number of public vulnerability databases today are already exporting this format, with more in the pipeline:
Go vulnerability database for Go packages
Rust advisory database for Cargo packages
Python advisory database for PyPI packages
DWF database for vulnerabilities in the Linux kernel and other popular software
OSS-Fuzz database for vulnerabilities in C/C++ software found by OSS-Fuzz
The OSV service has also aggregated all of these vulnerability databases, which are viewable at our web UI. They can also be queried with a single command via the same existing APIs:
curl -X POST -d \
'{"commit": "a46c08c533cfdf10260e74e2c03fa84a13b6c456"}' \
"https://api.osv.dev/v1/query"
'{"version": "2.4.1", "package": {"name": "jinja2", "ecosystem": "PyPI"}}' \
Automating vulnerability database maintenance
Producing quality vulnerability data is also difficult. In addition to OSV's existing automation, we built more automation tools for vulnerability database maintenance, and used these tools to bootstrap the community Python advisory database. This automation takes existing feeds, accurately matches them to packages, and generates entries containing precise, validated version ranges with minimal human intervention. We plan to extend this tooling to other ecosystems for which there is no existing vulnerability database, or little support for ongoing database maintenance.
Thank you to all the open source developers who have provided feedback and adopted this format. We're continuing to work with open source communities to develop this further and earn more widespread adoption in all ecosystems. If you are interested in adopting this format, we'd appreciate any feedback on our public spec.
Get ready for the 2021 Google CTF
Posted by Kristoffer Janke, Information Security Engineer
Are you ready for no sleep, no chill and a lot of hacking? Our annual Google CTF is back!
The competition kicks off on Saturday July 17 00:00:01 AM UTC and runs through Sunday July 18 23:59:59 UTC. Teams can register at [goo.gle] .
Just like last year, the top 16 teams will qualify for our Hackceler8 speed run and the chance to take home a total of $30,301.70 in prize money.
As we reminisce on last years event, we'd be remiss if we didn't recognize our 2020 winning teams:
Plaid Parliament of Pwning
I Use Bing
The Flat Network Society
We are eager to see if they can defend their leet status. For those interested, we have published all 2020 Hackceler8 videos for your viewing pleasure here.
Whether you're a seasoned CTF player or just curious about cyber security and ethical hacking, we want you to join us. Sign up to learn skills, meet new friends in the security community and even watch the pros in action. For the latest announcements, see g.co/ctf, subscribe to our mailing list or follow us on @GoogleVRP. See you there!
P.S. Curious about last year's Google CTF challenges? We open-sourced them here.
Introducing SLSA, an End-to-End Framework for Supply Chain Integrity
Posted Kim Lewandowski, Google Open Source Security Team & Mark Lodato, Binary Authorization for Borg Team
Supply chain integrity attacks—unauthorized modifications to software packages—have been on the rise in the past two years, and are proving to be common and reliable attack vectors that affect all consumers of software. The software development and deployment supply chain is quite complicated, with numerous threats along the source ➞ build ➞ publish workflow. While point solutions do exist for some specific vulnerabilities, there is no comprehensive end-to-end framework that both defines how to mitigate threats across the software supply chain, and provides reasonable security guarantees. There is an urgent need for a solution in the face of the eye-opening, multi-billion dollar attacks in recent months (e.g. SolarWinds, Codecov), some of which could have been prevented or made more difficult had such a framework been adopted by software developers and consumers.
Our proposed solution is Supply chain Levels for Software Artifacts (SLSA, pronounced "salsa"), an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. It is inspired by Google's internal "Binary Authorization for Borg" which has been in use for the past 8+ years and is mandatory for all of Google's production workloads. The goal of SLSA is to improve the state of the industry, particularly open source, to defend against the most pressing integrity threats. With SLSA, consumers can make informed choices about the security posture of the software they consume.
How SLSA helps
SLSA helps to protect against common supply chain attacks. The following image illustrates a typical software supply chain and includes examples of attacks that can occur at every link in the chain. Each type of attack has occured over the past several years and, unfortunately, is increasing as time goes on.
Known example
How SLSA could have helped
Submit bad code to the source repository
Linux hypocrite commits: Researcher attempted to intentionally introduce vulnerabilities into the Linux kernel via patches on the mailing list.
Two-person review caught most, but not all, of the vulnerabilities.
Compromise source control platform
PHP: Attacker compromised PHP's self-hosted git server and injected two malicious commits.
A better-protected source code platform would have been a much harder target for the attackers.
Build with official process but from code not matching source control
Webmin: Attacker modified the build infrastructure to use source files not matching source control.
A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering.
Compromise build platform
SolarWinds: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build.
Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence.
Use bad dependency (i.e. A-H, recursively)
event-stream: Attacker added an innocuous dependency and then updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (i.e. attack F).
Applying SLSA recursively to all dependencies would have prevented this particular vector, because the provenance would have indicated that it either wasn't built from a proper builder or that the source did not come from GitHub.
Upload an artifact that was not built by the CI/CD system
CodeCov: Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly.
Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo.
Compromise package repository
Attacks on Package Mirrors: Researcher ran mirrors for several popular package repositories, which could have been used to serve malicious packages.
Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo.
Trick consumer into using bad package
Browserify typosquatting: Attacker uploaded a malicious package with a similar name as the original.
SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions.
What is SLSA
In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus. In its final form, SLSA will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give "SLSA certification" to a particular package or build platform. SLSA is designed to be incremental and actionable, and to provide security benefits at every step. Once an artifact qualifies at the highest level, consumers can have confidence that it has not been tampered with and can be securely traced back to source—something that is difficult, if not impossible, to do with most software today.
SLSA consists of four levels, with SLSA 4 representing the ideal end state. The lower levels represent incremental milestones with corresponding incremental integrity guarantees. The requirements are currently defined as follows.
SLSA 1 requires that the build process be fully scripted/automated and generate provenance. Provenance is metadata about how an artifact was built, including the build process, top-level source, and dependencies. Knowing the provenance allows software consumers to make risk-based security decisions. Though provenance at SLSA 1 does not protect against tampering, it offers a basic level of code source identification and may aid in vulnerability management.
SLSA 2 requires using version control and a hosted build service that generates authenticated provenance. These additional requirements give the consumer greater confidence in the origin of the software. At this level, the provenance prevents tampering to the extent that the build service is trusted. SLSA 2 also provides an easy upgrade path to SLSA 3.
SLSA 3 further requires that the source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance, respectively. We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross-build contamination.
SLSA 4 is currently the highest level, requiring two-person review of all changes and a hermetic, reproducible build process. Two-person review is an industry best practice for catching mistakes and deterring bad behavior. Hermetic builds guarantee that the provenance's list of dependencies is complete. Reproducible builds, though not strictly required, provide many auditability and reliability benefits. Overall, SLSA 4 gives the consumer a high degree of confidence that the software has not been tampered with.
More details on these proposed levels can be found in the GitHub repository, including the corresponding Source and Build/Provenance requirements. We are open to feedback and suggestions for changes on these requirements.
Today, we are releasing a proof of concept for SLSA 1 provenance generator (repo, marketplace). This will allow a user to create and upload provenance alongside their build artifacts, thereby achieving SLSA 1. To use it, add the following snippet to your workflow:
- name: Generate provenance
uses: slsa-framework/github-actions-demo@v0.1
artifact_path: <path-to-artifact/directory>
Going forward, we plan to work with popular source, build, and packaging platforms to make it as easy as possible to reach higher levels of SLSA. These plans include generating provenance automatically in build systems, propagating provenance natively in package repositories, and adding security features across the major platforms. Our long-term goal is to raise the security bar across the industry so that the default expectation is higher-level SLSA security standards, with minimal effort on the part of software producers.
SLSA is a practical framework for end-to-end software supply chain integrity, based on a model proven to work at scale in one of the world's largest software engineering organizations. Achieving the highest level of SLSA for most projects may be difficult, but incremental improvements recognized by lower SLSA levels will already go a long way toward improving the security of the open source ecosystem.
We look forward to working with the community on refining the levels as we begin adopting SLSA for our own open source projects. If you are a project maintainer and interested in trying to adopt and provide feedback on SLSA, please reach out or come join the discussions taking place in the OpenSSF Digital Identity Attestation Working Group.
Check out the Know, Prevent, Fix post to read more about Google's overall approach to open source security.
Verifiable Supply Chain Metadata for Tekton
Posted: June 8th, 2021, 6:02pm CEST by Kaylin Trychon
Posted by Dan Lorenc, Priya Wadhwa, Open Source Security Team
If you've been paying attention to the news at all lately, you've probably noticed that software supply chain attacks are rapidly becoming a big problem. Whether you're trying to prevent these attacks, responding to an ongoing one or recovering from one, you understand that knowing what is happening in your CI/CD pipeline is critical.
Fortunately, the Kubernetes-native Tekton project – an open-source framework for creating CI/CD systems – was designed with security in mind from Day One, and the new Tekton Chains project is here to help take it to the next level. Tekton Chains securely captures metadata for CI/CD pipeline executions. We made two really important design decisions early on in Tekton that make supply chain security easy: declarative pipeline definitions and explicit state transitions. This next section will explain what these mean in practice and how they make it easy to build a secure delivery pipeline.
Definitions or "boxes and arrows"
Just like everything in your high school physics class, a CI/CD pipeline can be modeled as a series of boxes. Each box has some inputs, some outputs, and some steps that happen in the middle. Even if you have one big complicated bash script that fetches dependencies, builds programs, runs tests, downloads the internet and deploys to production, you can draw boxes and arrows to represent this flow. The boxes might be really big, but you can do it.
Since the initial whiteboard sketches, the Pipeline and Task CRDs in Tekton were designed to allow users to define each step of their pipeline at a granular level. These types include support for mandatory declared inputs, outputs, and build environments. This means you can track exactly what sources went into a build, what tools were used during the build itself and what artifacts came out at the end. By breaking up a large monolithic pipeline into a series of smaller, reusable steps, you can increase visibility into the overall system. This makes it easier to understand your exposure to supply chain attacks, detect issues when they do happen and recover from them after.
Explicit transitions
After a pipeline is defined, there are a few approaches to orchestrating it: level-triggered and edge-triggered. Like most of the Kubernetes ecosystem, Tekton is designed to operate in a level-triggered fashion. This means steps are executed explicitly by a central orchestrator which runs one task, waits for completion, then decides what to do next. In edge-based systems, a pipeline definition would be translated into a set of events and listeners. Each step fires off events when it completes, and these events are then picked up by listeners which run the next set of steps.
Event-based or edge-triggered systems are easy to reason about, but can be tricky to manage at scale. They also make it much harder to track an artifact as it flows through the entire system. Each step in the pipeline only knows about the one immediately before it; no step is responsible for tracking the entire execution. This can become problematic when you try to understand the security posture of your delivery pipeline.
Tekton was designed with the opposite approach in mind - level-triggered. Instead of a Rube-Goldberg machine tied together with duct tape and clothespins, Tekton is more like an explicit assembly-line. Level-triggered systems like Tekton move from state-to-state in a calculated manner by a central orchestrator. They require more explicit-design up front, but they are easier to observe and reason about after. Supply chains that use systems like Tekton are more secure.
Secure delivery pipeline through chains and provenance
So how do these two design decisions combine to make supply chain security easier? Enter Tekton Chains.
By observing the execution of a Task or a Pipeline and paying careful attention to the inputs, outputs, and steps along the way, we can make it easier to track down what happened and why later on. This "observer" can be run in a separate trust domain and cryptographically sign all of this captured metadata as it's stored, leaving a tamper-proof activity ledger. This technique is called "verifiable builds." This securely generated metadata can be used in a number of ways, from audit logging to recovering from security breaches to pre-deployment policy enforcement.
You can install Chains into any Tekton-enabled cluster and configure it to generate this cryptographically-signed supply chain metadata for your builds. Chains supports pluggable signature systems like PGP, x509 and Cloud KMS's. Payloads can be generated in a few different industry-standard formats like the RedHat Simple-Signing and the In-Toto Provenance specifications. The full documentation is available here, but you can get started quickly with something like this:
For this tutorial, you'll need access to a GKE Kubernetes cluster and a GCR registry with push credentials. The cluster should already have Tekton Pipelines installed.
Install Tekton Chains into your cluster:
$ kubectl apply --filename [https:]
Next, you'll set up registry authentication for the Tekton Chains controller, so that it can push OCI image signatures to your registry. To set up authentication, you'll create a Service Account and download credentials:
$ export PROJECT_ID=<GCP Project ID>
$ gcloud iam service-accounts create tekton-chains
$ gcloud iam service-accounts keys create credentials.json --iam-account=tekton-chains@${PROJECT_ID}.iam.gserviceaccount.com
Now, create a Kubernetes Secret from your credentials file so the Chains controller can access it:
$ kubectl create secret docker-registry registry-credentials \
--docker-server=gcr.io \
--docker-username=_json_key \
--docker-email=tekton@chains.com \
--docker-password="$(cat credentials.json)" \
-n tekton-chains
$ kubectl patch serviceaccount tekton-chains-controller \
-p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n tekton-chains
We can use cosign to generate a keypair as a Kubernetes secret, which the Chains controller will use for signing. Cosign will ask for a password, which will be stored in the secret:
$ cosign generate-key-pair -k8s tekton-chains/signing-secrets
Next, you'll need to set up authentication to your GCR registry for the kaniko task as another Kubernetes Secret.
$ export CREDENTIALS_SECRET=kaniko-credentials
$ kubectl create secret generic $CREDENTIALS_SECRET --from-file credentials.json
Now, we'll create a kaniko-chains task which will build and push a container image to your registry. Tekton Chains will recognize that an image has been built, and sign it automatically.
$ kubectl apply -f [https:]
$ cat <<EOF | kubectl apply -f -
apiVersion: tekton.dev/v1beta1
kind: TaskRun
name: kaniko-run
taskRef:
name: kaniko-gcp
- name: IMAGE
value: gcr.io/${PROJECT_ID}/kaniko-chains
workspaces:
- name: source
emptyDir: {}
- name: credentials
secretName: ${CREDENTIALS_SECRET}
Wait for the TaskRun to complete, and give the Tekton Chains controller a few seconds to sign the image and store the signature. You should be able to verify the signature with cosign and your public key:
$ cosign verify -key cosign.pub gcr.io/${PROJECT_ID}/kaniko-chains
Congratulations! You've successfully signed and verified an OCI image with Tekton Chains and cosign.
Within Chains, we'll be improving integration with other supply-chain security projects. This includes support for Binary Transparency and Verifiable Builds through integrations with the Sigstore and In-Toto projects. We'll also be improving and providing a set of well-designed, highly secure Tasks and Pipeline definitions in the TektonCD Catalog.
In Tekton Pipelines, we plan on finishing up TEP-0025 (Hermekton) to enable the support for hermetic build execution. If you want to play around with it now, hermekton can be run as an alpha feature in experimental mode. When hermekton is enabled, a build runs in a locked-down environment without network connectivity. Hermetic builds guarantee all inputs have been explicitly declared ahead-of-time, providing for a more auditable supply-chain. Hermetic builds and Chains align well, because the hermeticity build property is contained in the full build provenance captured by Chains. Chains can generate and attest to metadata specifying exactly which sections of a build had network access.
This means policy can be defined around exactly which build tools are allowed to access the network and which ones are not. This metadata can be used in policies at build time (banning compilers with security vulnerabilities) or stored and used by policy engines at deploy time (only code-reviewed and verifiably built containers are allowed to run).
We believe supply-chain security must be built-in and by default. No task orchestrator can promise perfect supply-chain security, but TektonCD was designed with unique features in mind that make it easier to do the right thing. We're always looking for feedback on the design, goals and requirements. You can reach out on GitHub or the #chains Slack channel.
Announcing New Abuse Research Grants Program
Posted by Anna Hupa, Marc Henson, and Martin Straka, Google VRP Team
Our Abuse Bug Bounty program has proved tremendously successful in the past three years since its introduction – thanks to our incredibly engaged community of researchers. Their contributions resulted in +1,000 valid bugs, helping us raise the bar in combating product abuse.
As a result of this continued success, today we are announcing a new experimental Abuse Research Grants Program in addition to the already existing Vulnerability Research Grants. Similar to other Research Grant Programs, these grants are up-front awards that our top researchers will receive before they ever submit a bug.
Last year, we increased our rewards to recognize the important work of our community. The growth of this program would not have been possible without partners like David (@xdavidhu), Zohar (ehpus.com), and Ademar (@nowaskyjr) who, on top of becoming our top research experts in Product Abuse, regularly contribute to transparency by sharing their work, further inspiring and influencing our community of researchers.
Despite the growth and success of this program, there remains more work to be done.
With our new Abuse Research Grants Program, we hope to bring even more awareness to product abuse by connecting more closely with our experienced researchers – so we can all work together to overcome these challenges, prevent product abuse and keep our users safe. Here's how the program works:
We invite our top abuse researchers to the program.
We award grants immediately before research begins, no strings attached.
Bug Hunters apply for the targets we share with them and start their research.
On top of the grant, researchers are eligible for regular rewards for the bugs they discover in scope of our Bug Bounty program.
To learn more about this and other grant programs, visit our rules page.
Introducing Half-Double: New hammering technique for DRAM Rowhammer bug
Posted: May 25th, 2021, 5:59pm CEST by Kaylin Trychon
Research Team: Salman Qazi, Yoongu Kim, Nicolas Boichat, Eric Shiu & Mattias Nissler
Today, we are sharing details around our discovery of Half-Double, a new Rowhammer technique that capitalizes on the worsening physics of some of the newer DRAM chips to alter the contents of memory.
Rowhammer is a DRAM vulnerability whereby repeated accesses to one address can tamper with the data stored at other addresses. Much like speculative execution vulnerabilities in CPUs, Rowhammer is a breach of the security guarantees made by the underlying hardware. As an electrical coupling phenomenon within the silicon itself, Rowhammer allows the potential bypass of hardware and software memory protection policies. This can allow untrusted code to break out of its sandbox and take full control of the system.
Rowhammer was first discussed in a paper in 2014 for what was then the mainstream generation of DRAM: DDR3. The following year, Google's Project Zero released a working privilege-escalation exploit. In response, DRAM manufacturers implemented proprietary logic inside their chips that attempted to track frequently accessed addresses and reactively mitigate when necessary.
As DDR4 became widely adopted, it appeared as though Rowhammer had faded away thanks in part to these built-in defense mechanisms. However, in 2020, the TRRespass paper showed how to reverse-engineer and neutralize the defense by distributing accesses, demonstrating that Rowhammer techniques are still viable. Earlier this year, the SMASH research went one step further and demonstrated exploitation from JavaScript, without invoking cache-management primitives or system calls.
Traditionally, Rowhammer was understood to operate at a distance of one row: when a DRAM row is accessed repeatedly (the "aggressor"), bit flips were found only in the two adjacent rows (the "victims"). However, with Half-Double, we have observed Rowhammer effects propagating to rows beyond adjacent neighbors, albeit at a reduced strength. Given three consecutive rows A, B, and C, we were able to attack C by directing a very large number of accesses to A, along with just a handful (~dozens) to B. Based on our experiments, accesses to B have a non-linear gating effect, in which they appear to "transport" the Rowhammer effect of A onto C. Unlike TRRespass, which exploits the blind spots of manufacturer-dependent defenses, Half-Double is an intrinsic property of the underlying silicon substrate. This is likely an indication that the electrical coupling responsible for Rowhammer is a property of distance, effectively becoming stronger and longer-ranged as cell geometries shrink down. Distances greater than two are conceivable.
Google has been working with JEDEC, an independent semiconductor engineering trade organization, along with other industry partners, in search of possible solutions for the Rowhammer phenomenon. JEDEC has published two documents about DRAM and system-level mitigation techniques (JEP 300-1 and JEP301-1).
We are disclosing this work because we believe that it significantly advances the understanding of the Rowhammer phenomenon, and that it will help both researchers and industry partners to work together, to develop lasting solutions. The challenge is substantial and the ramifications are industry-wide. We encourage all stakeholders (server, client, mobile, automotive, IoT) to join the effort to develop a practical and effective solution that benefits all of our users.
Making the Internet more secure one signed container at a time
Posted: May 6th, 2021, 3:00pm CEST by Kaylin Trychon
Posted by Priya Wadhwa, Jake Sanders, Google Open Source Security Team
With over 16 million pulls per month, Google's `distroless` base images are widely used and depended on by large projects like Kubernetes and Istio. These minimal images don't include common tools like shells or package managers, making their attack surface (and download size!) smaller than traditional base images such as `ubuntu` or `alpine`. Even with this additional protection, users could still fall prey to typosquatting attacks, or receive a malicious image if the distroless build process was compromised – making users vulnerable to accidentally using a malicious image instead of the actual distroless image. This problem isn't unique to distroless images – until now, there just hasn't been an easy way to verify that images are what they claim to be.
Introducing Cosign
Cosign simplifies signing and verifying container images, aiming to make signatures invisible infrastructure – basically, it takes over the hard part of signing and verifying software for you.
We developed cosign in collaboration with the sigstore project, a Linux Foundation project and a non-profit service that seeks to improve the open source software supply chain by easing the adoption of cryptographic software signing, backed by transparency log technologies.
We're excited to announce that all of our distroless images are now signed by cosign! This means that all users of distroless can verify that they are indeed using the base image they intended to before kicking off image builds, making distroless images even more trustworthy. In fact, Kubernetes has already begun performing this check in their builds.
As we look to the future, Kubernetes SIG Release's vision is to establish a consumable, introspectable, and secure supply chain for the project. By collaborating with the sigstore maintainers (who are fellow Kubernetes contributors) to integrate signing and transparency into our supply chain, we hope to be an exemplar for standards in the cloud native (and wider) tech industry, said Stephen Augustus, co-chair for Kubernetes SIG Release.
To start signing distroless we integrated cosign into the distroless CI system, which builds and pushes images via Cloud Build. Signing every distroless image was as easy as adding an additional Cloud Build step to the Cloud Build job responsible for building and pushing the images. This additional step uses the cosign container image and a key pair stored in GCP KMS to sign every distroless image. With this additional signing step, users can now verify that the distroless image they're running was built in the correct CI environment.
Right now, cosign can be run as an image or as a CLI tool. It supports:
Hardware and KMS signing
Bring-your-own PKI
Our free OIDC PKI (Fulcio)
Built-in binary transparency and timestamping service (Rekor)
Signing distroless with cosign is just the beginning, and we plan to incorporate other sigstore technologies into distroless to continue to improve it over the next few months. We also can't wait to integrate sigstore with other critical projects. Stay tuned here for updates! To get started verifying your own distrolesss images, check out the distroless README and to learn more about sigstore, check out sigstore.dev.
Google, HTTPS, and device compatibility
Posted: March 15th, 2021, 2:00pm CET by Kaylin Trychon
Posted by Ryan Hurst, Product Management, Google Trust Services
Encryption is a fundamental building block when you're on a mission to organize the world's information and make it universally accessible with strong security and privacy. This is why a little over four years ago we created Google Trust Services—our publicly trusted Certificate Authority (CA).
The road to becoming a publicly trusted certificate authority is a long one - especially if the certificates you issue will be used by some of the most visited sites on the internet.
When we started on this journey, our goal was that within five years our root certificates would be embedded in enough devices that we could do a single transition to our long-term root certificates.
There are still a large number of active used devices that have not been updated with our root certificates.
To ensure as many clients as possible continue to have secure connections when using Google Trust Services certificates, we needed to obtain a cross-sign. A cross-sign allows a certificate authority that is already trusted by a device to extend its device compatibility to another certificate authority.
The rules governing public CA operations require that the CA being cross-signed meet the same strict operational, technological, and audit criteria as the certificate authority providing this cross-sign. Google Trust Services is already a publicly trusted CA that is operated to the highest standards and is in all major browser trust stores, so we already met the requirements for a cross-sign from another CA.. The key was to find one that is already trusted by the devices we wanted to be able to validate our certificates. We worked with GMO GlobalSign for this cross sign because they operate one of the oldest root certificates in wide use today.
Why are we telling you about this now? On December 15, 2021, the primary root certificate we use today (GlobalSign R2 which is owned and operated by Google Trust Services) will expire.
To ensure these older devices continue to work smoothly with the certificates we issue we will start sending a new cross-signed certificate to services when we issue new certificates.
The good news is that users shouldn't notice the change. This is because the cross-certificate (GTS Root R1 Cross) we're deploying was signed by a root certificate created and trusted by most devices over 20 years ago.
In summary, when you use certificates from Google Trust Services, you and your customers will continue to get the benefit of the best device compatibility in the industry.
We know you might have some questions about this change. Here are our answers to the most frequent ones:
I am a developer or ISV that uses a Google API. What do I need to do?
Certificate Authorities change which root CA certificates they use from time to time, so we have always provided a list of certificates that we currently use or may use in the future. Anybody using this list won't have to change anything. If you have not been using this list and updating it based on our published guidance, you will need to update your application to use these roots and regularly update the list you use so future changes go smoothly for your users.
I am a website operator that uses Google Trust Services certificates. Do I need to change anything?
You do not! Google Trust Services offers certificates to Alphabet products and services including many Google Cloud services. This means that those services are the ones responsible for configuring and managing TLS for you.
When will this change go into effect?
We will begin rolling out certificate chains that use this cross-certificate in March 2021. We will slowly roll these changes out throughout the rest of the year and will complete them before December 15, 2021.
I use a service or product that uses Google Trust Services. Is there anything I need to change? No, this change should be invisible to all end users.
How can I test to see if my devices will trust certificates that rely on this cross-sign?
We operate a test site that uses the cross-certificate that you can visit here. If you see "Google Trust Services Demo Page - Expected Status: good" and some additional certificate information, the new certificate chain works correctly on your device. If you get an error, the list of trusted roots for the device you're testing needs to be updated.
When does this cross-certificate expire and what happens when it does?
The cross-certificate expires January 28th, 2028. Sometime between now and when it looks like it is no longer needed for broad device compatibility, we will stop providing this extra certificate to certificate requesters, as it will no longer be needed.
I use an old device and it does not trust the cross-sign. What should I do?
Many devices handle root certificate updates as part of their security patching process. If you are running one of these devices, you should make sure you apply all relevant security updates. It is also possible the manufacturer no longer provides security updates for your device. If this is the case you may want to contact your provider or consider replacing your device.
Does this mean you are no longer using the Google Trust Services roots? We are still using the Google Trust Services roots, they are simply cross-signed. When it is no longer necessary to use the cross-sign, we will no longer distribute the cross-sign to certificate requestors.
To learn more, visit Google Trust Services.
A Spectre proof-of-concept for a Spectre-proof web
Posted by Stephen Röttger and Artur Janc, Information Security Engineers
Three years ago, Spectre changed the way we think about security boundaries on the web. It quickly became clear that flaws in modern processors undermined the guarantees that web browsers could make about preventing data leaks between applications. As a result, web browser vendors have been continuously collaborating on approaches intended to harden the platform at scale. Nevertheless, this class of attacks still remains a concern and requires web developers to deploy application-level mitigations.
In this post, we will share the results of Google Security Team's research on the exploitability of Spectre against web users, and present a fast, versatile proof-of-concept (PoC) written in JavaScript which can leak information from the browser's memory. We've confirmed that this proof-of-concept, or its variants, function across a variety of operating systems, processor architectures, and hardware generations.
By sharing our findings with the security community, we aim to give web application owners a better understanding of the impact Spectre vulnerabilities can have on the security of their users' data. Finally, this post describes the protections available to web authors and best practices for enabling them in web applications, based on our experience across Google.
The Spectre vulnerability, disclosed to the public in January 2018, makes use of a class of processor (CPU) design vulnerabilities that allow an attacker to change the intended program control flow while the CPU is speculatively executing subsequent instructions. For example, the CPU may speculate that a length check passes, while in practice it will access out-of-bounds memory. While the CPU state is rolled back once the misprediction is noticed, this behavior leaves observable side effects which can leak data to an attacker.
In 2019, the team responsible for V8, Chrome's JavaScript engine, published a blog post and whitepaper concluding that such attacks can't be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.
In parallel, browser vendors and standards bodies developed security mechanisms to protect web users from these classes of attacks. This included both architectural changes which offer default protections enabled in some browser configurations (such as Site Isolation, out-of-process iframes, and Cross-Origin Read Blocking), as well as broadly applicable opt-in security features that web developers can deploy in their applications: Cross-Origin Resource Policy, Cross-Origin Opener Policy, Cross-Origin Embedder Policy, and others.
These mechanisms, while crucially important, don't prevent the exploitation of Spectre; rather, they protect sensitive data from being present in parts of the memory from which they can be read by the attacker. To evaluate the robustness of these defenses, it's therefore important to develop security tools that help security engineers understand the practical implications of speculative execution attacks for their applications.
Demonstrating Spectre in a web browser
Today, we're sharing proof-of-concept (PoC) code that confirms the practicality of Spectre exploits against JavaScript engines. We use Google Chrome to demonstrate our attack, but these issues are not specific to Chrome, and we expect that other modern browsers are similarly vulnerable to this exploitation vector. We have developed an interactive demonstration of the attack available at https://leaky.page/; the code and a more detailed writeup are published on Github here.
The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.
While experimenting, we also developed other PoCs with different properties. Some examples include:
A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.
We chose to release the current PoC since it has a negligible setup time and works in the absence of high precision timers, such as SharedArrayBuffer.
The main building blocks of the PoC are:
A Spectre gadget: code that triggers attacker-controlled transient execution.
A side-channel: a way to observe side effects of the transient execution.
1. The gadget
For the published PoC, we implemented a simple Variant 1 gadget: a JavaScript array is speculatively accessed out of bounds after training the branch predictor that the compiler-inserted length check will succeed. This particular gadget can be mitigated at the software level; however, Chrome's V8 team concluded that this is not the case for other gadgets: "we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software."
We invite the security community to extend our research and develop code that makes use of other Spectre gadgets.
2. The side-channel
A common way to leak secret data via speculative execution is to use a cache side-channel. By observing if a certain memory location is present in the cache or not, we can infer if it has been accessed during the speculative execution. The challenge in JavaScript is to find a high resolution timer allowing to distinguish cache from memory accesses, as modern browsers have reduced the timer granularity of the performance.now() API and disabled SharedArrayBuffers in contexts without cross-origin isolation to prevent timing attacks.
Already in 2018, the V8 team shared their observation that reduced timer granularity is not sufficient to mitigate Spectre, since attackers can arbitrarily amplify timing differences. The presented amplification technique was based on reading secret data multiple times which can, however, reduce the effectiveness of the attack if the information leak is probabilistic.
In our PoC, we developed a new technique that overcomes this limitation. By abusing the behavior of the Tree-PLRU cache eviction strategy commonly found in modern CPUs, we were able to significantly amplify the cache timing with a single read of secret data. This allowed us to leak data efficiently even with low precision timers. For technical details, see the demonstration at [https:]] .
While we don't believe this particular PoC can be re-used for nefarious purposes without significant modifications, it serves as a compelling demonstration of the risks of Spectre. In particular, we hope it provides a clear signal for web application developers that they need to consider this risk in their security evaluations and take active steps to protect their sites.
Deploying web defenses against Spectre
The low-level nature of speculative execution vulnerabilities makes them difficult to fix comprehensively, as a proper patch can require changes to the firmware or hardware on the user's device. While operating system and web browser developers have implemented important built-in protections where possible (including Site Isolation with out-of-process iframes and Cross-Origin Read Blocking in Google Chrome, or Project Fission in Firefox), the design of existing web APIs still makes it possible for data to inadvertently flow into an attacker's process.
With this in mind, web developers should consider more robustly isolating their sites by using new security mechanisms that actively deny attackers access to cross-origin resources. These protections mitigate Spectre-style hardware attacks and common web-level cross-site leaks, but require developers to assess the threat these vulnerabilities pose to their applications and understand how to deploy them. To assist in that evaluation, Chrome's web platform security team has published Post-Spectre Web Development and Mitigating Side-Channel Attacks with concrete advice for developers; we strongly recommend following their guidance and enabling the following protections:
Cross-Origin Resource Policy (CORP) and Fetch Metadata Request Headers allow developers to control which sites can embed their resources, such as images or scripts, preventing data from being delivered to an attacker-controlled browser renderer process. See resourcepolicy.fyi and web.dev/fetch-metadata.
Cross-Origin Opener Policy (COOP) lets developers ensure that their application window will not receive unexpected interactions from other websites, allowing the browser to isolate it in its own process. This adds an important process-level protection, particularly in browsers which don't enable full Site Isolation; see web.dev/coop-coep.
Cross-Origin Embedder Policy (COEP) ensures that any authenticated resources requested by the application have explicitly opted in to being loaded. Today, to guarantee process-level isolation for highly sensitive applications in Chrome or Firefox, applications must enable both COEP and COOP; see web.dev/coop-coep.
In addition to enabling these isolation mechanisms, ensure your application also enables standard protections, such as the X-Frame-Options and X-Content-Type-Options headers, and uses SameSite cookies. Many Google applications have already deployed, or are in the process of deploying these mechanisms, providing a defense against speculative execution bugs in situations where default browser protections are insufficient.
It's important to note that while all of the mechanisms described in this article are important and powerful security primitives, they don't guarantee complete protection against Spectre; they require a considered deployment approach which takes behaviors specific to the given application into account. We encourage security engineers and researchers to use and contribute to our Spectre proof-of-concept to review and improve the security posture of their sites.
Tip: To help you protect your website from Spectre, the Google Security Team has created Spectroscope, a prototype Chrome extension that scans your application and finds resources which may require enabling additional defenses. Consider using it to assist with your deployments of web isolation features.
#ShareTheMicInCyber: Brooke Pearson
Posted by Parisa Tabriz, Head of Chrome Product, Engineering and UX
In an effort to showcase the breadth and depth of Black+ contributions to security and privacy fields, we've launched a profile series that aims to elevate and celebrate the Black+ voices in security and privacy we have here at Google.
Brooke Pearson manages the Privacy Sandbox program at Google, and her team's mission is to, "Create a thriving web ecosystem that is respectful of users and private by default." Brooke lives this mission and it is what makes her an invaluable asset to the Chrome team and Google.
In addition to her work advancing the fields of security and privacy, she is a fierce advocate for women in the workplace and for elevating the voices of her fellow Black+ practitioners in security and privacy. She has participated and supported the #ShareTheMicInCyber campaign since its inception.
Brooke is passionate about delivering privacy solutions that work and making browsing the web an inherently more private experience for users around the world.
Why do you work in security or privacy?
I work in security and privacy to protect people and their personal information. It's that simple. Security and privacy are two issues that are core to shaping the future of technology and how we interact with each other over the Internet. The challenges are immense, and yet the ability to impact positive change is what drew me to the field.
Tell us a little bit about your career journey to Google
My career journey into privacy does not involve traditional educational training in the field. In fact, my background is in public policy and communications, but when I transitioned to the technology industry, I realized that the most pressing policy issues for companies like Google surround the nascent field of privacy and the growing field of security.
After I graduated from college at Azusa Pacific University, I was the recipient of a Fulbright scholarship to Macau, where I spent one year studying Chinese and teaching English. I then moved to Washington D.C. where I initially worked for the State Department while finishing my graduate degree in International Public Policy at George Washington University. I had an amazing experience in that role and it afforded me some incredible networking opportunities and the chance to travel the world, as I worked in Afghanistan and Central Asia.
After about five years in the public sector, I joined Facebook as a Program Manager for the Global Public Policy team, initially focused on social good programs like Safety Check and Charitable Giving. Over time, I could see that the security team at Facebook was focused on fighting the proliferation of misinformation, and this called to me as an area where I could put my expertise in communication and geopolitical policy to work. So I switched teams and I've been in the security and privacy field ever since, eventually for Uber and now with Google's Chrome team.
At Google, privacy and security are at the heart of everything we do. Chrome is tackling some of the world's biggest security and privacy problems, and everyday my work impacts billions of people around the world. Most days, that's pretty daunting, but every day it's humbling and inspiring.
What is your security or privacy "soapbox"?
If we want to encourage people to engage in more secure behavior, we have to make it easy to understand and easy to act on. Every day we strive to make our users safer with Google by implementing security and privacy controls that are effective and easy for our users to use and understand.
As a program manager, I've learned that it is almost always more effective to offer a carrot than a stick, when it comes to security and privacy hygiene. I encourage all of our users to visit our Safety Center to learn all the ways Google helps you stay safe online, every day.
If you are interested in following Brooke's work here at Google and beyond, please follow her on Twitter @brookelenet. We will be bringing you more profiles over the coming weeks and we hope you will engage with and share these with your network.
If you are interested in participating or learning more about #ShareTheMicInCyber, click here.
Fuzzing Java in OSS-Fuzz
OSS-Fuzz, Google's open source fuzzing service, now supports fuzzing applications written in Java and other Java Virtual Machine (JVM) based languages (e.g. Kotlin, Scala, etc.). Open source projects written in JVM based languages can add their project to OSS-Fuzz by following our documentation.
The Google Open Source Security team partnered with Code Intelligence to integrate their Jazzer fuzzer with OSS-Fuzz. Thanks to their integration, open source projects written in JVM-based languages can now use OSS-Fuzz for continuous fuzzing.
OSS-Fuzz has found more than 25,000 bugs in open source projects using fuzzing. We look forward to seeing how this technique can help secure and improve code written in JVM-based languages.
What can Jazzer do?
Jazzer allows users to fuzz code written in JVM-based languages with libFuzzer, as they already can for code written in C/C++. It does this by providing code coverage feedback from JVM bytecode to libFuzzer. Jazzer already supports important libFuzzer features such as:
FuzzedDataProvider for fuzzing code that doesn't accept an array of bytes.
Evaluation of code coverage based on 8-bit edge counters.
Value profile.
Minimization of crashing inputs.
The intent for Jazzer is to support all libFuzzer features eventually.
What Does Jazzer Support?
Jazzer supports all languages that compile to JVM bytecode, since instrumentation is done on the bytecode level. This includes:
Jazzer can also provide coverage feedback from native code that is executed through JNI. This can uncover interesting memory corruption vulnerabilities in memory unsafe native code.
Why Fuzz Java/JVM-based Code?
As discussed in our post on Atheris, fuzzing code written in memory safe languages, such as JVM-based languages, is useful for finding bugs where code behaves incorrectly or crashes. Incorrect behavior can be just as dangerous as memory corruption. For example, Jazzer was used to find CVE-2021-23899 in json-sanitizer which could be exploited for cross-site scripting (XSS). Bugs causing crashes or incorrect exceptions can sometimes be used for denial of service. For example, OSS-Fuzz recently found a denial of service issue that could have been used to take "a major part of the ethereum network offline".
When fuzzing memory safe code, you can use the same classic approach for fuzzing memory unsafe code: passing mutated input to code and waiting for crashes. Or you can take a more unit test like approach where your fuzzer verifies that the code is behaving correctly (example).
Another way fuzzing can find interesting bugs in JVM-based code is through differential fuzzing. With differential fuzzing, your fuzzer passes mutated input from the fuzzer to multiple library implementations that should have the same functionality. Then it compares the results from each library to find differences.
Check out our documentation to get started. We will explore this more during our OSS-Fuzz talk at FuzzCon Europe.
Introducing sigstore: Easy Code Signing & Verification for Supply Chain Integrity
Posted: March 9th, 2021, 10:14pm CET by Kaylin Trychon
Posted by Kim Lewandowski & Dan Lorenc, Google Open Source Security Team
One of the fundamental security issues with open source is that it's difficult to know where the software comes from or how it was built, making it susceptible to supply chain attacks. A few recent examples of this include dependency confusion attack and malicious RubyGems package to steal cryptocurrency.
Today we welcome the announcement of sigstore, a new project in the Linux Foundation that aims to solve this issue by improving software supply chain integrity and verification.
Installing most open source software today is equivalent to picking up a random thumb-drive off the sidewalk and plugging it into your machine. To address this we need to make it possible to verify the provenance of all software - including open source packages. We talked about the importance of this in our recent Know, Prevent, Fix post.
The mission of sigstore is to make it easy for developers to sign releases and for users to verify them. You can think of it like Let's Encrypt for Code Signing. Just like how Let's Encrypt provides free certificates and automation tooling for [HTTPS,] sigstore provides free certificates and tooling to automate and verify signatures of source code. Sigstore also has the added benefit of being backed by transparency logs, which means that all the certificates and attestations are globally visible, discoverable and auditable.
Sigstore is designed with open source maintainers, for open source maintainers. We understand long-term key management is hard, so we've taken a unique approach of issuing short-lived certificates based on OpenID Connect grants. Sigstore also stores all activity in Transparency Logs, backed by Trillian so that we can more easily detect compromises and recover from them when they do occur. Key distribution is notoriously difficult, so we've designed away the need for them by building a special Root CA just for code signing, which will be made available for free.
We have a working prototype and proof of concepts that we're excited to share for feedback. Our goal is to make it seamless and easy to sign and verify code:
It has been fun collaborating with the folks from Red Hat and the open source community on this project. Luke Hinds, one of the lead developers on sigstore and Security Engineering Lead at Red Hat says, "I am very excited about sigstore and what this means for improving the security of software supply chains. sigstore is an excellent example of an open source community coming together to collaborate and develop a solution to ease the adoption of software signing in a transparent manner." We couldn't agree more.
Mike Malone, the CEO of Smallstep, helped with the overall design of sigstore. He adds, "In less than a generation, open source has grown from a niche community to a critical ecosystem that powers our global economy and institutions of society and culture. We must ensure the security of this ecosystem without undermining the open, decentralized collaboration that makes it work. By building on a clever composition of existing technologies that respect privacy and work at scale, sigstore is the core infrastructure we need to solve this fundamental problem. It's an ambitious project with potential for global impact. I'm impressed by the rapid progress that's been made by Google, Red Hat, and Linux Foundation over the past few months, and I'm excited to hear feedback from the broader community."
While we are happy with the progress that has been made, we know there is still work to be done before this can be widely relied upon. Upcoming plans for sigstore include: hardening the system, adding support for other OpenID Connect providers, updating documentation and responding to community feedback.
Sigstore is in its early days, but we're really excited about its future. Now is a great time to provide feedback, try out the tooling and get involved with the project as design details are still being refined.
#ShareTheMicInCyber: Rob Duhart
Posted: March 1st, 2021, 6:07pm CET by Kaylin Trychon
Posted by Matt Levine, Director, Risk Management
In an effort to showcase the breadth and depth of Black+ contributions to security and privacy fields, we've launched a series in support of #ShareTheMicInCyber that aims to elevate and celebrate the Black+ voices in security and privacy we have here at Google.
Today, we will hear from Rob Duhart, he leads a cross functional team at Google that aims to enable and empower all of our products, like Chrome, Android and Maps, to mature their security risk journey.
Rob's commitment to making the internet a safer place extends far beyond his work at Google, he is a member of the Cyber Security Executive Education Advisory Board of Directors at Washington University in St. Louis, where he helps craft the future of cyber security executive education globally. Rob also sits on the board of the EC-Council and has founded chapters of the International Consortium of Cybersecurity Professionals (ICMCP) across the country.
Rob is passionate about securing the digital world and supporting Black+, women, and underrepresented minorities across the technology landscape.
I have been in the cyber world long enough to know how important it is for security and privacy to be top of mind and focus for organizations of all shapes and sizes. My passion lies in keeping users and Googlers safe. One of the main reasons I joined Google is its commitment to security and privacy.
Tell us a little bit about your career journey to Google...
I was fortunate to begin my cybersecurity career in the United States Government working at the Department of Energy, FBI, and the Intelligence Community. I transitioned to the private sector in 2017 and have been fortunate to lead talented security teams at Cardinal Health and Ford Motor Company.
My journey into cybersecurity was not traditional. I studied Political Science at Washington University in St. Louis, completed graduate education at George Mason University and Carnegie Mellon University. I honed my skills and expertise in this space through hands on experience and with the support of many amazing mentors. It has been the ride of a lifetime and I look forward to what is next.
To those thinking about making a career change or are just starting to get into security, my advice is don't be afraid to ask for help.
At Google, we implement a model known as Federated Security, where our security teams partner across our Product Areas to enable security program maturity Google wide. Our Federated Security team believes in harnessing the power of relationship, engagement, and community to drive maturity into every product. Security and privacy are team sports – it takes business leaders and security leaders working together to secure and protect our digital and physical worlds.
If you are interested in following Rob's work here at Google and beyond, please follow him on Twitter @RobDuhart. We will be bringing you more profiles over the coming weeks and we hope you will engage with and share these with your network.
Celebrating the influence and contributions of Black+ Security & Privacy Googlers
Posted: February 25th, 2021, 6:00pm CET by Kaylin Trychon
Black History Month may be coming to a close, but our work to build sustainable equity for Google's Black+ community, and externally is ongoing. Currently, Black Americans make up less than 12% of information security analysts in the U.S. In an industry that consistently requires new ideas to spark positive change and stand out against the status quo, it is necessary to have individuals who think, speak, and act in diverse ways. Diverse security teams are more innovative, produce better products and enhance an organization's ability to defend against cyber threats.
In an effort to amplify the contributions of the Black+ community to security and privacy fields, we'll be sharing profiles of Black+ Googlers working on innovative privacy and security solutions over the coming weeks, starting with Camille Stewart, Google's Head of Security Policy for Google Play and Android.
Camille co-founded #ShareTheMicInCyber, an initiative that pairs Black security practitioners with prominent allies, lending their social media platforms to the practitioners for the day. The goal is to break down barriers, engage the security community, and promote sustained action. The #ShareTheMicInCyber campaign will highlight Black women in the security and privacy sector on LinkedIn and Twitter on March 19, 2021 and throughout March 2021 in celebration of Women's History Month. Follow the #ShareTheMicInCyber on March 19th to support and amplify Black women in security and privacy.
Read more about Camille's story below ↓
#ShareTheMicInCyber: Camille Stewart
Today, we will hear from Camille Stewart, she leads security, privacy, election integrity, and dis/misinformation policy efforts for Google's mobile business. She also spearheads a cross-Google security initiative that sets the strategic vision and objectives for Google's engagement on security and privacy issues.
In her (not so) spare time, Camille is co-founder of the #ShareTheMicInCyber initiative – which aims to elevate the profiles, work, and lived experiences of Black cyber practitioners. This initiative has garnered national and international attention and has been a force for educating and bringing awareness to the challenges Black security practitioners face in industry. Camille is also a cybersecurity fellow at Harvard University, New America and Truman National Security Project. She sits on the board of the International Foundation for Electoral Systems and of Girl Security, an organization that is working to close the gender gap in national security through learning, training, and mentoring support for girls.
I work in this space to empower people in and through technology by translating and solving the complex challenges that lie at the intersection of technology, security, society, and the law.
Before life at Google, I managed cybersecurity, election security, tech innovation, and risk issues at Deloitte. Prior to that, I was appointed by President Barack Obama to be the Senior Policy Advisor for Cyber Infrastructure & Resilience Policy at the Department of Homeland Security. I was the Senior Manager of Legal Affairs at Cyveillance, a cybersecurity company after working on Capitol Hill.
Right now, I have a few. Users being intentional about their digital security similar to their physical security especially with their mobile devices and apps. As creators of technology, we need to be more intentional about how we educate our users on safety and security. At Google, security is core to everything we do and build, it has to be. We recently launched our Safer With Google campaign which I believe is a great resource for helping users better understand their security and privacy journey.
As an industry, we need to make meaningful national and international progress on digital supply chain transparency and security.
Lastly, the fact that systemic racism is a cybersecurity threat. I recently penned a piece for the Council on Foreign Relations that explores how racism influences cybersecurity and what we must do as an industry to address it.
If you are interested in following Camille's work here at Google and beyond, please follow her on Twitter @CamilleEsq. We will be bringing you more profiles over the coming weeks and we hope you will engage with and share these with your network.
Mitigating Memory Safety Issues in Open Source Software
Posted by Dan Lorenc, Infrastructure Security Team
Memory-safety vulnerabilities have dominated the security field for years and often lead to issues that can be exploited to take over entire systems.
A recent study found that "~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues." Another analysis on security issues in the ubiquitous `curl` command line tool showed that 53 out of 95 bugs would have been completely prevented by using a memory-safe language.
Software written in unsafe languages often contains hard-to-catch bugs that can result in severe security vulnerabilities, and we take these issues seriously at Google. That's why we're expanding our collaboration with the Internet Security Research Group to support the reimplementation of critical open-source software in memory-safe languages. We previously worked with the ISRG to help secure the Internet by making TLS certificates available to everyone for free, and we're looking forward to continuing to work together on this new initiative.
It's time to start taking advantage of memory-safe programming languages that prevent these errors from being introduced. At Google, we understand the value of the open source community and in giving back to support a strong ecosystem.
To date, our free OSS-Fuzz service has found over 5,500 vulnerabilities across 375 open source projects caused by memory safety errors, and our Rewards Program helps encourage adoption of fuzzing through financial incentives. We've also released other projects like Syzkaller to detect bugs in operating system kernels, and sandboxes like gVisor to reduce the impact of bugs when they are found.
The ISRG's approach of working directly with maintainers to support rewriting tools and libraries incrementally falls directly in line with our perspective here at Google.
The new Rust-based HTTP and TLS backends for curl and now this new TLS library for Apache [httpd] are an important starting point in this overall effort. These codebases sit at the gateway to the internet and their security is critical in the protection of data for millions of users worldwide.
We'd like to thank the maintainers of these projects for working on such widely-used and important infrastructure, and for participating in this effort.
We're happy to be able to support these communities and the ISRG to make the Internet a safer place. We appreciate their leadership in this area and we look forward to expanding this program in 2021.
Open source security is a collaborative effort. If you're interested in learning more about our efforts, please join us in the Securing Critical Projects Working Group of the Open Source Security Foundation.