Category Archives: Online Security Blog

The latest news and insights from Google on security and safety on the Internet

Protect and manage browser extensions using Chrome Browser Cloud Management

Posted by Anuj Goyal, Product Manager, Chrome Browser

Browser extensions, while offering valuable functionalities, can seem risky to organizations. One major concern is the potential for security vulnerabilities. Poorly designed or malicious extensions could compromise data integrity and expose sensitive information to unauthorized access. Moreover, certain extensions may introduce performance issues or conflicts with other software, leading to system instability. Therefore, many organizations find it crucial to have visibility into the usage of extensions and the ability to control them. Chrome browser offers these extension management capabilities and reporting via Chrome Browser Cloud Management. In this blog post, we will walk you through how to utilize these features to keep your data and users safe.

Visibility into Extensions being used in your environment

Having visibility into what and how extensions are being used enables IT and security teams to assess potential security implications, ensure compliance with organizational policies, and mitigate potential risks. There are three ways you can get critical information about extensions in your organization:

1. App and extension usage reporting

Organizations can gain visibility into every Chrome extension that is installed across an enterprise’s fleet in Chrome App and Extension Usage Reporting.

2. Extension Risk Assessment

CRXcavator and Spin.AI Risk Assessment are tools used to assess the risks of browser extensions and minimize the risks associated with them. We are making extension scores via these two platforms available directly in Chrome Browser Cloud Management, so security teams can have an at-a-glance view of risk scores of the extensions being used in their browser environment.

3. Extension event reporting

Extension installs events are now available to alert IT and security teams of new extension usage in their environment.

Organizations can send critical browser security events to their chosen solution providers, such as Splunk, Crowdstrike, Palo Alto Networks, and Google solutions, including Chronicle, Cloud PubSub, and Google Workspace, for further analysis. You can also view the event logs directly in Chrome Browser Cloud Management.

Extension controls for added security

By having control over extensions, organizations can maintain a secure and stable browsing environment, safeguard sensitive data, and protect their overall digital infrastructure. There are several ways IT and security teams can set and enforce controls over extensions:

1. Extension permission

Organizations can control whether users can install apps or extensions based on the information an extension can access—also known as permissions. For example, you might want to prevent users from installing any extension that wants permission to see a device location.

2. Extension workflow

Extension workflow allows end users to request extensions for review. From there, IT can either approve or deny them. This is a great approach for teams that want to control the extensions in their environment, but allow end users to have some say over the extensions they use.

We recently added a prompt for business justification for documenting why users are requesting the extension. This gives admins more information as to why the extension may or may not be helpful for their workforce, and can help speed approvals for business users.

3. Force install/block extensions

In the requests tab, you can select a requested extension, and approve that extension request and force install it, so the extension shows up automatically on all the managed browsers in that specific Organizational Unit or group.

Admins also have the ability to block extensions in their browser environment.

4. Extension version pinning

Admins have the ability to pin extensions to specific versions. As a result, the pinned extensions will not be upgraded unless the admin explicitly changes the version. This gives organizations the ability to evaluate new extension versions before they decide to allow them in their environment.

Extensions play a huge role in user productivity for many organizations, and Chrome is committed to help enterprises securely take advantage of them. If you haven’t already, you can sign up for Chrome Browser Cloud Management and start managing extensions being used in your organizations at no additional cost.

If you’re already using Chrome Browser Cloud Management, but want to see how you can get the most out of it, check out our newly released Beyond Browsing demo series where Chrome experts share demos on some of our frequently asked management questions.

Bringing Transparency to Confidential Computing with SLSA

Asra Ali, Razieh Behjati, Tiziano Santoro, Software Engineers


Every day, personal data, such as location information, images, or text queries are passed between your device and remote, cloud-based services. Your data is encrypted when in transit and at rest, but as potential attack vectors grow more sophisticated, data must also be protected during use by the service, especially for software systems that handle personally identifiable user data.




Toward this goal, Google’s Project Oak is a research effort that relies on the confidential computing paradigm to build an infrastructure for processing sensitive user data in a secure and privacy-preserving way: we ensure data is protected during transit, at rest, and while in use. As an assurance that the user data is in fact protected, we’ve open sourced Project Oak code, and have introduced a transparent release process to provide publicly inspectable evidence that the application was built from that source code. 




This blog post introduces Oak's transparent release process, which relies on the SLSA framework to generate cryptographic proof of the origin of Oak’s confidential computing stack, and together with Oak’s remote attestation process, allows users to cryptographically verify that their personal data was processed by a trustworthy application in a secure environment. 




Integrity and transparency with SLSA  

Project Oak recently collaborated with the SLSA community to create a new container-based builder that produces Supply-chain Levels for Software Artifacts (SLSA) Build Level 3 provenance. This new container-based builder generates non-forgeable provenance statements that capture details about build process information that allow users to perform automated, rigorous provenance verification.




With this enhanced provenance generated by the container-based builder, you can answer questions like:

  • Was the artifact built with a toolchain that I know and trust?

  • Was the artifact built with a command that I trust?

  • Did the build command use a tool that was affected by a vulnerability?

  • How can I recreate the artifact?




Project Oak is particularly interested in answering these questions about every layer of the confidential computing stack. For instance, to be sure that a released binary was built using a trusted build process (e.g., the build command did not use any potentially malicious tool), the Oak release process compares the build command against a set of allow-listed tokens. Similarly, we can verify that the builder was not tampered with. 



Transparent releases: an added layer of trust

Project Oak develops a secure runtime and a remote attestation protocol—ways to detect potential adversaries on remote servers and to protect workloads while they are running. Now, with the addition of the container-based SLSA builder, we are able to complete our transparent release process to protect against software supply chain attacks and provide an automated process for verifying the integrity and trustworthiness of a remote server, before sending sensitive information to it. 




Specifically, for each released version of the Oak secure runtime, the Oak team generates and signs an endorsement statement for the binary, using a key accessible only to the Oak team. The endorsement statement can only be generated if the provenance statement passes verification checks, ensuring that a potential malicious attacker cannot forge the statement.




When the client establishes a connection to the server, the client must verify the endorsement statement and the proof of its inclusion in a transparency log, and check that the binary identities in the attestation report and the endorsement statement are the same. This, together with signature verification for the endorsement statement, guarantees three important points of trust for the overall process: that the client is interacting with the same publicly endorsed version of the Oak secure runtime that all other clients interact with; the Oak secure runtime is open source; and that it has a publicly published non-forgeable SLSA v1.0 provenance with adherence to SLSA Build Track 3. For a more technical explanation of the process, see Project Oak’s transparent release process.





Visualization of an Oak application, with attestation verification 




Try it out

We encourage you to check out the transparent release project as a use case for SLSA. Please reach out to us via our slack channel to explore ideas related to Oak secure runtimes and remote attestation.




You don’t need to use Project Oak to take advantage of the new SLSA builder tool. If your project is open source, try one of the SLSA builders to generate non-forgeable provenance for your binaries. We encourage you to containerize your build and try the container-based SLSA 3 builder! Using a container image for your builds improves the reproducibility of your binaries. We also recommend adding the instructions for building your container image (e.g., a Dockerfile) to your GitHub repository, which improves auditability and transparency of your build process, and thus the security of your software supply chain.

Learnings from kCTF VRP’s 42 Linux kernel exploits submissions

Tamás Koczka, Security Engineer


In 2020, we integrated kCTF into Google's Vulnerability Rewards Program (VRP) to support researchers evaluating the security of Google Kubernetes Engine (GKE) and the underlying Linux kernel. As the Linux kernel is a key component not just for Google, but for the Internet, we started heavily investing in this area. We extended the VRP's scope and maximum reward in 2021 (to $50k), then again in February 2022 (to $91k), and finally in August 2022 (to $133k). In 2022, we also summarized our learnings to date in our cookbook, and introduced our experimental mitigations for the most common exploitation techniques.


In this post, we'd like to share our learnings and statistics about the latest Linux kernel exploit submissions, how effective our mitigations are against them, what we do to protect our users, and, finally, how we are changing our program to align incentives to the areas we are most interested in.



Learnings and Statistics



Since its inception, the program has rewarded researchers with a total of 1.8 million USD, and in the past year, there has been a clear trend: 60% of the submissions exploited the io_uring component of the Linux kernel (we paid out around 1 million USD for io_uring alone). Furthermore, io_uring vulnerabilities were used in all the submissions which bypassed our mitigations.






 

Limiting io_uring

To protect our users, we decided to limit the usage of io_uring in Google products: 



While io_uring brings performance benefits, and promptly reacts to security issues with comprehensive security fixes (like backporting the 5.15 version to the 5.10 stable tree), it is a fairly new part of the kernel. As such, io_uring continues to be actively developed, but it is still affected by severe vulnerabilities and also provides strong exploitation primitives. For these reasons, we currently consider it safe only for use by trusted components.



Transparency

Currently, we make vulnerability details public on our spreadsheet (which now also includes CVE details), and we have summarized different exploitation techniques in our cookbook. In the future, to make our efforts more transparent and give faster feedback to the community, we will ask researchers to open-source their submissions, including the code they used.



Introducing kernelCTF

To better align incentives with our areas of interest, we are shifting our focus from GKE and kCTF to the latest stable kernel and our mitigations. As a result, starting today we will handle kernel exploit submissions under a new name, "kernelCTF," with its own reward structure and submission process. The maximum total payout for kernelCTF is still $133,337 per submission. While the specific GKE kernel configuration is still covered by the new kernelCTF, exploits affecting non-kernel components like the full GKE stack (including Kubernetes), the container runtime, and GKE itself, are now separately eligible for vulnerability rewards under the kCTF VRP which is returning to its original reward amounts and conditions.


Conclusion

Our goal remains the same: we are building a pipeline to analyze, experiment, measure, and build security mitigations to make the Linux kernel as safe as possible, with the help of the security community. We hope that over time, we will be able to implement security mitigations that make it more difficult to exploit Linux kernel vulnerabilities.

With the name change, we have moved our communication channel to #kernelctf on Discord, with a separate #kernelctf-announcements channel. Please join us there for the latest updates regarding kernelCTF.

Announcing the Chrome Browser Full Chain Exploit Bonus

Amy Ressler, Chrome Security Team on behalf of the Chrome VRP

For 13 years, a key pillar of the Chrome Security ecosystem has included encouraging security researchers to find security vulnerabilities in Chrome browser and report them to us, through the Chrome Vulnerability Rewards Program.

Starting today and until 1 December 2023, the first security bug report we receive with a functional full chain exploit, resulting in a Chrome sandbox escape, is eligible for triple the full reward amount. Your full chain exploit could result in a reward up to $180,000 (potentially more with other bonuses).

Any subsequent full chains submitted during this time are eligible for double the full reward amount!

We have historically put a premium on reports with exploits – “high quality reports with a functional exploit” is the highest tier of reward amounts in our Vulnerability Rewards Program. Over the years, the threat model of Chrome browser has evolved as features have matured and new features and new mitigations, such a MiraclePtr, have been introduced. Given these evolutions, we’re always interested in explorations of new and novel approaches to fully exploit Chrome browser and we want to provide opportunities to better incentivize this type of research. These exploits provide us valuable insight into the potential attack vectors for exploiting Chrome, and allow us to identify strategies for better hardening specific Chrome features and ideas for future broad-scale mitigation strategies.

The full details of this bonus opportunity are available on the Chrome VRP rules and rewards page. The summary is as follows:

  • The bug reports may be submitted in advance while exploit development continues during this 180-day window. The functional exploits must be submitted to Chrome by the end of the 180-day window to be eligible for the triple or double reward.
    • The first functional full chain exploit we receive is eligible for the triple reward amount.
  • The full chain exploit must result in a Chrome browser sandbox escape, with a demonstration of attacker control / code execution outside of the sandbox.
  • Exploitation must be able to be performed remotely and no or very limited reliance on user interaction.
  • The exploit must have been functional in an active release channel of Chrome (Dev, Beta, Stable, Extended Stable) at the time of the initial reports of the bugs in that chain. Please do not submit exploits developed from publicly disclosed security bugs or other artifacts in old, past versions of Chrome.

As is consistent with our general rewards policy, if the exploit allows for remote code execution (RCE) in the browser or other highly-privileged process, such as network or GPU process, to result in a sandbox escape without the need of a first stage bug, the reward amount for renderer RCE “high quality report with functional exploit” would be granted and included in the calculation of the bonus reward total.

Based on our current Chrome VRP reward matrix, your full chain exploit could result in a total reward of over $165,000 -$180,000 for the first full chain exploit and over $110,000 - $120,000 for subsequent full chain exploits we receive in the six month window of this reward opportunity.

We’d like to thank our entire Chrome researcher community for your past and ongoing efforts and security bug submissions! You’ve truly helped us make Chrome more secure for all users.

Happy Hunting!

Adding Chrome Browser Cloud Management remediation actions in Splunk using Alert Actions

Posted by Ashish Pujari, Chrome Security Team

Introduction

Chrome is trusted by millions of business users as a secure enterprise browser. Organizations can use Chrome Browser Cloud Management to help manage Chrome browsers more effectively. As an admin, they can use the Google Admin console to get Chrome to report critical security events to third-party service providers such as Splunk® to create custom enterprise security remediation workflows.

Security remediation is the process of responding to security events that have been triggered by a system or a user. Remediation can be done manually or automatically, and it is an important part of an enterprise security program.

Why is Automated Security Remediation Important?

When a security event is identified, it is imperative to respond as soon as possible to prevent data exfiltration and to prevent the attacker from gaining a foothold in the enterprise. Organizations with mature security processes utilize automated remediation to improve the security posture by reducing the time it takes to respond to security events. This allows the usually over burdened Security Operations Center (SOC) teams to avoid alert fatigue.

Automated Security Remediation using Chrome Browser Cloud Management and Splunk

Chrome integrates with Chrome Enterprise Recommended partners such as Splunk® using Chrome Enterprise Connectors to report security events such as malware transfer, unsafe site visits, password reuse. Other supported events can be found on our support page.

The Splunk integration with Chrome browser allows organizations to collect, analyze, and extract insights from security events. The extended security insights into managed browsers will enable SOC teams to perform better informed automated security remediations using Splunk® Alert Actions.

Splunk Alert Actions are a great capability for automating security remediation tasks. By creating alert actions, enterprises can automate the process of identifying, prioritizing, and remediating security threats.

In Splunk®, SOC teams can use alerts to monitor for and respond to specific Chrome Browser Cloud Management events. Alerts use a saved search to look for events in real time or on a schedule and can trigger an Alert Action when search results meet specific conditions as outlined in the diagram below.

Use Case

If a user downloads a malicious file after bypassing a Chrome “Dangerous File” message their managed browser/managed CrOS device should be quarantined.

Prerequisites

Setup

  1. Install the Google Chrome Add-on for Splunk App

    Please follow installation instructions here depending on your Splunk Installation to install the Google Chrome Add-on for Splunk App.

  2. Setting up Chrome Browser Cloud Management and Splunk Integration

    Please follow the guide here to set up Chrome Browser Cloud Management and Splunk® integration.

  3. Setting up Chrome Browser Cloud Management API access

    To call the Chrome Browser Cloud Management API, use a service account properly configured in the Google admin console. Create a (or use an existing) service account and download the JSON representation of the key.

    Create a (or use an existing) role in the admin console with all the “Chrome Management” privileges as shown below.

    Assign the created role to the service account using the “Assign service accounts” button.

  4. Setting up Chrome Browser Cloud Management App in Splunk®

    Install the App i.e. Alert Action from our Github page. You will notice that the Splunk App uses the below directory structure. Please take some time to understand the directory structure layout.

  5. Setting up a Quarantine OU in Chrome Browser Cloud Management

    Create a “Quarantine” OU to move managed browsers into. Apply restrictive policies to this OU which will then be applied to managed browsers and managed CrOS devices that are moved to this OU. In our case we set the below policies for our “Quarantine” OU called Investigate.These policies ensure that the quarantined CrOS device/browser can only open a limited set of approved URLS.

Configuration

  1. Start with a search for the Chrome Browser Cloud Management events in the Google Chrome Add-on for Splunk App. For our instance we used the below search query to search for known malicious file download events.
  2. Save the search as an alert. The alert uses the saved search to check for events. Adjust the alert type to configure how often the search runs. Use a scheduled alert to check for events on a regular basis. Use a real-time alert to monitor for events continuously. An alert does not have to trigger every time it generates search results. Set trigger conditions to manage when the alert triggers. Customize the alert settings as per enterprise security policies. For our example we used a real time alert with a per-result trigger. The setup we used is as shown below.

    3. As seen in the screenshot we have configured the Chrome Browser Cloud Management Remediation Alert Action App with

    • The OU Path of the Quarantine OU i.e. /Investigate
    • The Customer Id of the workspace domain
    • Service Account Key JSON value

    Test the setup

    Use the testsafebrowsing website to generate sample security events to test the setup.

    1. Open the testsafebrowsing website
    2. Click the link for line item 4 under the Desktop Download Warnings section i.e. “Should show an "uncommon" warning, for .exe”
    3. You will see a Dangerous Download blocked warning giving you two options to either Discard or Keep the downloaded file. Click on Keep
    4. This will trigger the alert action and move your managed browser or managed CrOS device to the “Quarantine” OU (OU name Investigate in our example) with restricted policies.

    Conclusion

    Security remediation is vital to any organization’s security program. In this blog we discussed configuring automated security remediation of Chrome Browser Cloud Management security events using Splunk alert actions. This scalable approach can be used to protect a company from online security threats by detecting and quickly responding to high fidelity Chrome Browser Cloud Management security events thereby greatly reducing the time to respond.

    Our team will be at the Gartner Security and Risk Management Summit in National Harbor, MD, next week. Come see us in action if you’re attending the summit.

Time to challenge yourself in the 2023 Google CTF!

Vincent Winstead, Technical Program Manager




It’s Google CTF time! Get your hacking toolbox ready and prepare your caffeine for rapid intake. The competition kicks off on June 23 2023 6:00 PM UTC and runs through June 25 2023 6:00 PM UTC. Registration is now open at g.co/ctf.





Google CTF gives you a chance to challenge your skillz, show off your hacktastic abilities, and learn some new tricks along the way. It consists of a set of computer security puzzles (or challenges) involving reverse-engineering, memory corruption, cryptography, web technologies, and more. Use obscure security knowledge to find exploits through bugs and creative misuse. With each completed challenge your team will earn points and move up through the ranks. 




The top 8 teams will qualify for our Hackceler8 competition taking place in Tokyo later this year. Hackceler8 is our experimental esport-style hacking game, custom-made to mix CTF and speedrunning. In the competition, teams need to find clever ways to abuse the game features to capture flags as quickly as possible. See the 2022 highlight reel to get a sense of what it’s like. The prize pool for this year’s event stands at more than $32,000!






Screenshot from Hackeler8 2022 speedrun competition




Itching to get started early? Want to learn more, or get a leg up on the competition? Review challenges from previous years, including previous Hackceler8 matches, all open-sourced here. Or gain inspiration by binge watching hours of Hackceler8 2020 videos!




If you are just starting out in this space, check out last year’s event H4CK1NG GOOGLE! It’s a great way to get acquainted with security. You can also get ready for this year’s Beginner’s Quest that’ll be launching later this summer which will be in the theme of Computer History, so get ready for some technology archaeology.




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 expand your skill set, 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 Twitter @GoogleVRP. Interested in bug hunting for Google? Check out bughunters.google.com. See you there!



Time to challenge yourself in the 2023 Google CTF!

Vincent Winstead, Technical Program Manager




It’s Google CTF time! Get your hacking toolbox ready and prepare your caffeine for rapid intake. The competition kicks off on June 23 2023 6:00 PM UTC and runs through June 25 2023 6:00 PM UTC. Registration is now open at g.co/ctf.




Google CTF gives you a chance to challenge your skillz, show off your hacktastic abilities, and learn some new tricks along the way. It consists of a set of computer security puzzles (or challenges) involving reverse-engineering, memory corruption, cryptography, web technologies, and more. Use obscure security knowledge to find exploits through bugs and creative misuse. With each completed challenge your team will earn points and move up through the ranks. 




The top 8 teams will qualify for our Hackceler8 competition taking place in Tokyo later this year. Hackceler8 is our experimental esport-style hacking game, custom-made to mix CTF and speedrunning. In the competition, teams need to find clever ways to abuse the game features to capture flags as quickly as possible. See the 2022 highlight reel to get a sense of what it’s like. The prize pool for this year’s event stands at more than $32,000!



Screenshot from Hackeler8 2022 speedrun competition




Itching to get started early? Want to learn more, or get a leg up on the competition? Review challenges from previous years, including previous Hackceler8 matches, all open-sourced here. Or gain inspiration by binge watching hours of Hackceler8 2020 videos!




If you are just starting out in this space, check out last year’s event H4CK1NG GOOGLE! It’s a great way to get acquainted with security. You can also get ready for this year’s Beginner’s Quest that’ll be launching later this summer which will be in the theme of Computer History, so get ready for some technology archaeology.




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 expand your skill set, 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 Twitter @GoogleVRP. Interested in bug hunting for Google? Check out bughunters.google.com. See you there!




Announcing the launch of GUAC v0.1

Brandon Lum and Mihai Maruseac, Google Open Source Security Team


Today, we are announcing the launch of the v0.1 version of Graph for Understanding Artifact Composition (GUAC). Introduced at Kubecon 2022 in October, GUAC targets a critical need in the software industry to understand the software supply chain. In collaboration with Kusari, Purdue University, Citi, and community members, we have incorporated feedback from our early testers to improve GUAC and make it more useful for security professionals. This improved version is now available as an API for you to start developing on top of, and integrating into, your systems.

The need for GUAC

High-profile incidents such as Solarwinds, and the recent 3CX supply chain double-exposure, are evidence that supply chain attacks are getting more sophisticated. As highlighted by the U.S. Executive Order on Cybersecurity, there’s a critical need for security professionals, CISOs, and security engineers to be able to more deeply link information from different supply chain ecosystems to keep up with attackers and prevent exposure. Without linking different sources of information, it’s impossible to have a clear understanding of the potential risks posed by the software components in an organization. 




GUAC aggregates software security metadata and maps it to a standard vocabulary of concepts relevant to the software supply chain. This data can be accessed via a GraphQL interface, allowing development of a rich ecosystem of integrations, command-line tools, visualizations, and policy engines. 




We hope that GUAC will help the wider software development community better evaluate the supply chain security posture of their organizations and projects. Feedback from early adopters has been overwhelmingly positive: 




“At Yahoo, we have found immense value and significant efficiency by utilizing the open source project GUAC. GUAC has allowed us to streamline our processes and increase efficiency in a way that was not possible before,” said Hemil Kadakia, Sr. Mgr. Software Dev Engineering, Paranoids, Yahoo.

The power of GUAC

Dynamic aggregation

GUAC is not just a static database—it is the first application that is continuously evolving the database pertaining to the software that an organization develops or uses. Supply chains change daily, and by aggregating your Software Bill of Materials (SBOMs) and Supply-chain Levels for Software Artifacts (SLSA) attestations with threat intelligence sources (e.g., OSV vulnerability feeds) and OSS insights (e.g., deps.dev), GUAC is constantly incorporating the latest threat information and deeper analytics to help paint a more complete picture of your risk profile. And by merging external data with internal private metadata, GUAC brings the same level of reasoning to a company’s first-party software portfolio.




Seamless integration of incomplete metadata

Because of the complexity of the modern software stack—often spanning languages and toolchains—we discovered during GUAC development that it is difficult to produce high-quality SBOMs that are accurate, complete, and meet specifications and intents. 




Following the U.S. Executive Order on Cybersecurity, there are now a large number of SBOM documents being generated during release and build workflows to explain to consumers what’s in their software. Given the difficulty in producing accurate SBOMs, consumers often face a situation where they have incomplete, inaccurate, or conflicting SBOMs. In these situations, GUAC can fill in the gaps in the various supply chain metadata: GUAC can link the documents and then use heuristics to improve the quality of data and guess at the correct intent. Additionally, the GUAC community is now working closely with SPDX to advance SBOM tooling and improve the quality of metadata. 

  





GUAC's process for incorporating and enriching metadata for organizational insight

Consistent interfaces

Alongside the boom in SBOM production, there’s been a rapid expansion of new standards, document types, and formats, making it hard to perform consistent queries. The multiple formats for software supply chain metadata often refer to similar concepts, but with different terms. To integrate these, GUAC defines a common vocabulary for talking about the software supply chain—for example, artifacts, packages, repositories, and the relationships between them. 




This vocabulary is then exposed as a GraphQL API, empowering users to build powerful integrations on top of GUAC’s knowledge graph. For example, users are able to query seamlessly with the same commands across different SBOM formats like SPDX and CycloneDX. 




According to Ed Warnicke, Distinguished Engineer at Cisco Systems, "Supply chain security is increasingly about making sense of many different kinds of metadata from many different sources. GUAC knits all of that information together into something understandable and actionable." 


Potential integrations

Based on these features, we envision potential integrations that users can build on top of GUAC in order to:


  • Create policies based on trust

  • Quickly react to security compromises 

  • Determine an upgrade plan in response to a security incident

  • Create visualizers for data explorations, CLI tools for large scale analysis and incident response, CI checks, IDE plugins to shift policy left, and more




Developers can also build data source integrations under GUAC to expand its coverage. The entire GUAC architecture is plug-and-play, so you can write data integrations to get:


  • Supply chain metadata from new sources like your preferred security vendors

  • Parsers to translate this metadata into the GUAC ontology

  • Database backends to store the GUAC data in either common databases or in organization-defined private data stores




GUAC's GraphQL query API enables a diverse ecosystem of tooling




Dejan Bosanac, an engineer at Red Hat and an active contributor to the GUAC project, further described GUAC’s ingestion abilities, “With mechanisms to ingest and certify data from various sources and GraphQL API to later query those data, we see it as a good foundation for our current and future SSCS efforts. Being a true open source initiative with a welcoming community is just a plus.” 



Next steps

Google is committed to making GUAC the best metadata synthesis and aggregation tool for security professionals. GUAC contributors are excited to meet at our monthly community calls and look forward to seeing demos of new applications built with GUAC.




“At Kusari, we are proud to have joined forces with Google's Open Source Security Team and the community to create and build GUAC,” says Tim Miller, CEO of Kusari. “With GUAC, we believe in the critical role it plays in safeguarding the software supply chain and we are dedicated to ensuring its success in the ecosystem.” 




Google is preparing SBOMs for consumption by the US Federal Government following EO 14028, and we are internally ingesting our SBOM catalog into GUAC to gather early insights. We encourage you to do the same with the GUAC release and submit your feedback. If the API is not flexible enough, please let us know how we can extend it. You can also submit suggestions and feedback on GUAC development or use cases, either by emailing [email protected] or filing an issue on our GitHub repository.




We hope you'll join us in this journey with GUAC!

How the Chrome Root Program Keeps Users Safe

Posted by Chrome Root Program, Chrome Security Team

What is the Chrome Root Program?

A root program is one of the foundations for securing connections to websites. The Chrome Root Program was announced in September 2022. If you missed it, don’t worry - we’ll give you a quick summary below!

Chrome Root Program: TL;DR

Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes for its users are secure and private. Certificates are issued by trusted entities called “Certification Authorities” (CAs). The collection of digital certificates, CA systems, and other related online servicews is the foundation of HTTPS and is often referred to as the “Web PKI.”

Before issuing a certificate to a website, the CA must verify that the certificate requestor legitimately controls the domain whose name will be represented in the certificate. This process is often referred to as “domain validation” and there are several methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value’s presence. Typically, domain validation practices must conform with a set of security requirements described in both industry-wide and browser-specific policies, like the CA/Browser Forum “Baseline Requirements” and the Chrome Root Program policy.

Upon connecting to a website, Chrome verifies that a recognized (i.e., trusted) CA issued its certificate, while also performing additional evaluations of the connection’s security properties (e.g., validating data from Certificate Transparency logs). Once Chrome determines that the certificate is valid, Chrome can use it to establish an encrypted connection to the website. Encrypted connections prevent attackers from being able to intercept (i.e., eavesdrop) or modify communication. In security speak, this is known as confidentiality and integrity.

The Chrome Root Program, led by members of the Chrome Security team, provides governance and security review to determine the set of CAs trusted by default in Chrome. This set of so-called "root certificates" is known at the Chrome Root Store.

How does the Chrome Root Program keep users safe?

The Chrome Root Program keeps users safe by ensuring the CAs Chrome trusts to validate domains are worthy of that trust. We do that by:

  • administering policy and governance activities to manage the set of CAs trusted by default in Chrome,
  • evaluating impact and corresponding security implications related to public security incident disclosures by participating CAs, and
  • leading positive change to make the ecosystem more resilient.

Policy and Governance

The Chrome Root Program policy defines the minimum requirements a CA owner must meet for inclusion in the Chrome Root Store. It incorporates the industry-wide CA/Browser Forum Baseline Requirements and further adds security controls to improve Chrome user security.

The CA application process includes a public discussion phase, where members of the Web PKI community are free to raise well-founded, fact-based concerns related to an applicant on an open discussion forum.

We consider public discussion valuable because it:

  • improves security, transparency, and interoperability, and
  • highlights concerning behavior, practices, or ownership background information not readily available through public audits, policy reviews, or other application process inputs.

For a CA owner’s inclusion request to be accepted, it must clearly demonstrate that the value proposition for the security and privacy of Chrome’s end users exceeds the corresponding risk of inclusion.

Once a CA is trusted, it can issue certificates for any website on the internet; thus, each newly added CA represents an additional attack surface, and the Web PKI is only as safe as its weakest link. For example, in 2011 a compromised CA led to a large-scale attack on web users in Iran.

Incident Management

No CA is perfect. When a CA owner violates the Chrome Root Program policy – or experiences any other situation that affects the CA’s integrity, trustworthiness, or compatibility – we call it an incident. Incidents can happen. They are an expected part of building a secure Web PKI. All the same, incidents represent opportunities to improve practices, systems, and understanding. Our program is committed to continuous improvement and participates in a public Web PKI incident management process.

When incidents occur, we expect CA owners to identify the root cause and remediate it to help prevent similar incidents from happening again. CA owners record the incident in a report that the Chrome Root Program and the public can review, which encourages an understanding of all contributing factors to reduce the probability of its reoccurrence in the Web PKI.

The Chrome Root Program prioritizes the security and privacy of its users and is unwilling to compromise on these values. In rare cases, incidents may result in the Chrome Root Program losing confidence in the CA owner’s ability to operate securely and reliably. This may happen when there is evidence of a CA owner:

  • knowingly violating requirements or obfuscating incidents,
  • demonstrating sustained patterns of failure, untimely and opaque communications, or an unwillingness to improve elements that are critical to security, or
  • performing other actions that negatively impact or otherwise degrade the security of the Web.

In these cases, Chrome may distrust a CA – that is, remove the CA from the Chrome Root Store. Depending on the circumstance, Chrome may also block the certificate with a non-bypassable error page.

The above cases are only illustrative, and considerations for CA distrust are not limited to these examples. The Chrome Root Program may remove certificates from the Chrome Root Store, as it deems appropriate and at its sole discretion, to enhance security and promote interoperability in Chrome.

Positive Ecosystem Change

The Chrome Root Program collaborates with members of the Web PKI ecosystem in various forums (e.g., the CA/Browser Forum) and committees (e.g., the CCADB Steering Committee). We share best practices, advocate for and develop new standards to promote user security, and seek ecosystem participant feedback on proposed initiatives. Collectively, ecosystem participants contributing to these working groups are protecting the Web.

In June 2022, we announced the “Moving Forward, Together” initiative that shared our vision of the future Web PKI that includes modern, reliable, agile, and purpose-driven architectures with a focus on automation, simplicity, and security. The initiative represents the goals and priorities of the Chrome Root Program and reinforces our commitment to working alongside CA owners to make the Web a safer place.

Some of our current priorities include:

  • reducing misissuance of certificates that do not comply with the Baseline Requirements, a CA’s own policies, or the Chrome Root Program policy,
  • increasing accountability and ecosystem integrity with high-quality, independent audits,
  • automating certificate issuance and strengthening the domain validation process, and
  • preparing for a “post-quantum” world.

We believe implementing proposals related to these priorities will help manage risk and make the Web a safer place for everyone.

However, as the name suggests, we can only realize these opportunities to improve with the collective contributions of the community. We understand CAs to be an essential element of the Web PKI, and we are encouraged by continued feedback and participation from existing and future CA owners in our program.

The Chrome Root Program is committed to openness and transparency, and we are optimistic we can achieve this shared vision. If you’re interested in seeing what new initiatives are being explored by the Chrome Root Program to keep Chrome users safe - you can learn more here.