Tag Archives: GitHub

Flutter SLSA Progress & Identity and Access Management through Infrastructure As Code

We are excited to announce several new achievements in Dart and Flutter's mission to harden security. We have achieved Supply Chain Levels for Software Artifacts (SLSA) Level 2 security on Flutter’s Cocoon application, reduced our Identity and Access Management permissions to the minimum required access, and implemented Infrastructure-as-Code to manage permissions for some of our applications. These achievements follow our recent success to enable Allstar and Security Scorecards.

Highlights

Achieving Flutter’s Cocoon SLSA level 2: Cocoon application provides continuous integration orchestration for Flutter Infrastructure. Cocoon also helps integrate several CI services with Github and provides tools to make Github development easier. Achieving SLSA Level 2 for Cocoon means we have addressed all the security concerns of levels 1 and 2 across the application. Under SLSA Level 2, Cocoon has “extra resistance to specific threats” to its supply chain. The Google Open Source Security team has audited and validated our achievement of SLSA Level 2 for Cocoon.


Implementing Identity & Access Management (IAM) via Infrastructure-as-Code: We have implemented additional security hardening features by onboarding docs-flutter-dev, master-docs-flutter-dev, and flutter-dashboard to use Identity and Access Management through an Infrastructure-as-Code system. These projects host applications, provide public documentation for Flutter, and contain a dashboard website for Flutter build status.

Using our Infrastructure-as-Code approach, security permission changes require code changes, ensuring approval is granted before the change is made. This also means that changes to security permissions are audited through source control and contain associated reasoning for the change. Existing IAM roles for these applications have been pared so that the applications follow the Principle of Least Privilege.

Advantages

  • Achieving SLSA Level 2 for Cocoon means we have addressed all the security concerns of levels 1 and 2 across the application. Under SLSA Level 2, Cocoon has “extra resistance to specific threats” to its supply chain.
  • Provenance is now generated for both, flutter-dashboard and auto-submit, artifacts through Cocoon’s automated build process. Provenance on these artifacts shows proof of their code source and tamper-proof build evidence. This work helps harden the security on the multiple tools used during the Cocoon build process: Google Cloud Platform, Cloudbuild, App Engine, and Artifact Registry.
  • Overall we addressed 83% of all SLSA requirements across all levels for the Cocoon application. We have identified the work across the application which will need to be completed for each level and category of SLSA compliance. Because of this, we know we are well positioned to continue future work toward SLSA Level 4.

Learnings and Best Practices

  1. Relatively small changes to the Cocoon application’s build process significantly increased the security of its supply chain. Google Cloud Build made this simple, since provenance metadata is created automatically during the Cloud Build process.

  2. Regulating IAM permissions through code changes adds many additional benefits and can make granting first time access simpler.

  3. Upgrading the SLSA level of an application sometimes requires varying efforts depending on the different factors of the application build process. Working towards SLSA level 4 will likely necessitate different configuration and code changes than required for SLSA level 2.

Coming Soon

Since this is the beginning of the Flutter and Dart journey toward greater SLSA level accomplishments, we hope to apply our learnings to more applications. We hope to begin work toward SLSA level 2 and beyond for more complex repositories like Flutter/flutter. Also, we hope to achieve an even higher level of SLSA compliance for the Cocoon application.

References

Supply Chain Levels for Software Artifacts (SLSA) is a security framework which outlines levels of supply chain security for an application as a checklist.

By Jesse Seales, Software Engineer – Dart and Flutter Security Working Group

Campaign Anomaly Detector

Posted by Meirav Shaul, Dvir Kalev, Roy Sela, Omri Levy, Tal Rimon Edelstein, Elad Ben-David, and Tzhahi Zilberstein, Team Lead

A while ago Google released “Account Anomaly Detector” which you know.

A few clients approached the gTech team at Google, asking to add some monitoring capabilities.

That’s why we created an unofficial, open-source evolved version of it. We named it “Campaign Anomaly Detector”. It has recently been published on github, ready for advertisers to deploy and use it for defining and detecting metrics anomalies.

Hosted on github, everyone is more than welcome to contribute more code to this ever-growing project. Happy monitoring!


Solution Requirements

Key Features

  • Entity to Monitor - option to select all/some child accounts under an MCC/specific campaigns.
  • Period selection - option to select both current and past periods for comparison
  • Metrics Selection & Anomaly Definition - option to select key metrics to be monitored, and the threshold values which will be considered as anomalies.
  • Dashboard - Data studio dashboard that presents identified anomalies
  • Email alerts - option to define the emails to notify once anomaly is identified

Key Components

The solution includes the following components:

  • Configuration Sheet (“input”) - Google Sheet for setting the monitoring parameters (entities for monitoring, period selection, metrics & thresholds, email alerts)
  • Simulator to support the period calculation and settings
  • Dashboard Sheet (“results”) - dedicated tab in the configuration sheet, that presents the identified anomalies
  • Data Studio Dashboard that presents the identified anomalies


Tutorial Video


Github

  • Find the open source repository here. 

Disclaimer

Copyright 2022 Google LLC. This solution, including any related sample code or data, is made available on an “as is,” “as available,” and “with all faults” basis, solely for illustrative purposes, and without warranty or representation of any kind. This solution is experimental, unsupported and provided solely for your convenience. Your use of it is subject to your agreements with Google, as applicable, and may constitute a beta feature as defined under those agreements. To the extent that you make any data available to Google in connection with your use of the solution, you represent and warrant that you have all necessary and appropriate rights, consents and permissions to permit Google to use and process that data. By using any portion of this solution, you acknowledge, assume and accept all risks, known and unknown, associated with its usage, including with respect to your deployment of any portion of this solution in your systems, or usage in connection with your business, if at all.

Dart and Flutter enable Allstar and Security Scorecards

We are thrilled to announce that Dart and Flutter have enabled Allstar and Security Scorecards on their open source repositories. This achievement marks the first milestone in our journey towards SLSA compliance to secure builds and releases from supply chain attacks.

Allstar is a GitHub app that provides automated continuous enforcement of security checks such as the OpenSSF Security Scorecards. With Allstar, owners can check for security policy adherence, set desired enforcement actions, and continuously implement those enforcement actions when triggered by a setting or file change in the org or repo.

Security Scorecards is an automated tool that assesses several key heuristics ("checks") associated with software security and assigns each check a score of 0-10. These scores can be used to evaluate the security posture of the project and help assess the risks introduced by dependencies.

Scorecards have been enabled on the following open source repositories, prioritized by their criticality score.

Org

Repos

Flutter

github.com/flutter/flutter

github.com/flutter/engine

github.com/flutter/plugins

github.com/flutter/packages

github.com/flutter/samples

github.com/flutter/website

github.com/flutter/flutter-intellij

github.com/flutter/gallery

github.com/flutter/codelabs

Dart

github.com/dart-lang/linter

github.com/dart-lang/sdk

github.com/dart-lang/dartdoc

github.com/dart-lang/site-www

github.com/dart-lang/test

With these security scanning tools, the Dart and Flutter team have found and resolved more than 200 high and medium security findings. The issues can be classified in the following categories:
  • Pinned Dependencies: The project should pin its dependencies. A "pinned dependency" is a dependency that is explicitly set to a specific hash instead of allowing a mutable version or range of versions. This reduces several security risks related to dependencies.
  • Token Permissions: The project's automated workflow tokens should be set to read-only by default. This follows the principle of least privilege.
  • Branch Protection: Github project's default and release branches should be protected with GitHub's branch protection settings. Branch protection allows maintainers to define rules that enforce certain workflows for branches, such as requiring review or passing certain status.
  • Code Review: The project should enforce a code review before pull requests (merge requests) are merged.
  • Dependency update tool: A dependency update tool should be used by the project to identify and update outdated and insecure dependencies.
  • Binary-Artifacts: The project should not have generated executable (binary) artifacts in the source repository. Embedded binary artifacts in the project cannot be reviewed, allowing possible obsolete or maliciously subverted executables in the source code.
Additionally, the Dart and Flutter teams have an aligned vulnerability management process. Details of these processes can be found on our respective developer sites at https://dart.dev/security and https://docs.flutter.dev/security. Internal process used by the team to handle vulnerabilities can be found on Flutter github wiki.

Learnings and Best Practices

  1. AllStar and Scorecards allowed Dart and Flutter to quickly identify areas of opportunity to improve security across hundreds of repositories triggering the removal of binaries, standardizing branch protection and enforcing code reviews.
  2. Standardizing third-party dependency management and running vulnerability scanning were identified as the next milestones in the Dart and Flutter journey to improve their overall security posture.
  3. It is safer to not embed binary artifacts in your code. However, there are cases when this is unavoidable.
  4. It is important to track your dependencies and to keep them up to date using tools like Dependabot.

By Khyati Mehta, Technical Program Manager – Dart-Flutter

What is Google’s Dev Library––a new open-source platform for developers

Banner showing the DevLibrary logo

Developers worldwide are creating open-source tools and tutorials; however, they have difficulty getting them discovered. The content published often spanned on many different sites—from GitHub to Medium. Therefore Google decided to create a space where the best projects related to Google technologies can be highlighted in one place—introducing the Dev Library, a curated archive of projects and articles built specifically using Google technologies.

Dev Library as a platform showcases blog posts and open source tools with easy-to-use navigation for these product areas: Machine Learning, Flutter, Firebase, Angular, Cloud, and Android.

What makes the Dev Library unique?

Not all the articles or projects submitted by you, get on the site! A team of Google experts look for accuracy and relevancy in each featured piece, so you know when you view the content on the site, it has the stamp of approval from Google.

How does it help me?

Visibility. Developers can have a hard time promoting and publicizing their learnings, despite extensive expertise. Dev Library is one such way to reach out to the world and say, "Hey! I have created this amazing project. Would you like to check it out"?

In addition, you also get to network with fellow contributors who are also using the Dev Library to showcase their projects.

To celebrate the efforts of our contributors, we created dedicated author pages for each person, allowing them to collate their projects in one place.

What content can I expect to see on the Dev Library?
To demonstrate the breadth of content on the site, here are some examples of published content pieces and video interviews with the developers who authored these posts:

What is the end goal?

Developers who know how to write well. Often we have witnessed developers with an entire portfolio of projects and knowledge bombs, still struggling to get it out there. But we need more developers writing about their work. Their struggles. Their code blocks. How their project was built up. And much more.

With the Dev Library, we somehow want to bring in that difference.

Upskill more developers to write well, market better, and reach out to a global audience waiting for long-form answers!

How can I support the Dev Library?
There are two ways you can help us grow the Developer Library:

  1. If you have great content that you would like to see published on the Dev Library, please submit it for review here.
  2. The team welcomes feedback, so if you have anything you’d like to see added or changed on the Dev Library site, please complete this short feedback form or file an issue on GitHub.

We can’t wait to receive your submissions and feedback!

Let Dev Library bring to you an amazing place to submit your open-source work.

Simpler Google Pay integration for React and web developers

Posted by Soc Sieng, Developer Advocate

The Google Pay API enables fast, simple checkout for your website.

The Google Pay JavaScript library does not depend on external libraries or frameworks and will work regardless of which framework your website uses (if it uses any at all). While this ensures wide compatibility, we know that it doesn’t necessarily make it easier to integrate when your website uses a framework. We’re doing something about it.

Introducing the Google Pay button for React

React is one of the most widely-used tools for building web UI's, so we are launching the Google Pay Button for React to provide a streamlined integration experience. This component will make it easier to incorporate Google Pay into your React website whether you are new to React or a seasoned pro, and similarly, if this is your first Google Pay integration or if you’ve done this before.

We’re making this component available as an open source project on GitHub and publishing it to npm. We’ve authored the React component with TypeScript to bring code completion to supported editors, and if your website is built with TypeScript you can also take advantage of type validation to identify common issues as you type.

Get real time code completion and validation as you integrate with supported editors.

Getting started

The first step is to install the Google Pay button module from npm:

npm install @google-pay/button-react

Adding and configuring the button

The Google Pay button can be added to your React component by first importing it:

import GooglePayButton from '@google-pay/button-react';

And then rendering it with the necessary configuration values:

<GooglePayButton
  environment="TEST"
  paymentRequest={{ ... }}
  onLoadPaymentData={() => {}}
  />

Try it out for yourself on JSFiddle.

Refer to component documentation for a full list of supported configuration properties.

Note that you will need to provide a Merchant ID in paymentRequest.merchantInfo to complete the integration. Your Merchant ID can be obtained from the Google Pay Business Console.

Your Merchant ID can be found in the Google Pay Business Console.

Support for other frameworks

We also want to provide an improved developer experience for our developers using other frameworks, or no framework at all. That’s why we are also releasing the Google Pay button Custom Element.

Custom elements are great because:

Like the React component, the Google Pay button custom element is hosted on GitHub and published to npm. In fact, the React component and the custom element share the same repository and large portion of code. This ensures that both versions maintain feature parity and receive the same level of care and attention.

Try it out on JSFiddle.

Google Pay JavaScript library

There's no change to the existing Google Pay JavaScript library, and if you prefer, you can continue to use this directly instead of the React component or custom element. Both of these components provide a convenience layer over the Google Pay JavaScript library and make use of it internally.

Your feedback

This is the first time that we (the Google Pay team) have released a framework specific library. We would love to hear your feedback.

Aside from React, most frameworks can use the Web Component version of the Google Pay Button. We may consider adding support for other frameworks based on interest and demand.

If you encounter any problems with the React component or custom element, please raise a GitHub issue. Alternatively, if you know what the problem is and have a solution in mind, feel free to raise a pull request. For other Google Pay related requests and questions, use the Contact Support option in the Google Pay Business Console.

What do you think?

Do you have any questions? Let us know in the comments below or tweet using #AskGooglePayDev.

Simpler Google Pay integration for React and web developers

Posted by Soc Sieng, Developer Advocate

The Google Pay API enables fast, simple checkout for your website.

The Google Pay JavaScript library does not depend on external libraries or frameworks and will work regardless of which framework your website uses (if it uses any at all). While this ensures wide compatibility, we know that it doesn’t necessarily make it easier to integrate when your website uses a framework. We’re doing something about it.

Introducing the Google Pay button for React

React is one of the most widely-used tools for building web UI's, so we are launching the Google Pay Button for React to provide a streamlined integration experience. This component will make it easier to incorporate Google Pay into your React website whether you are new to React or a seasoned pro, and similarly, if this is your first Google Pay integration or if you’ve done this before.

We’re making this component available as an open source project on GitHub and publishing it to npm. We’ve authored the React component with TypeScript to bring code completion to supported editors, and if your website is built with TypeScript you can also take advantage of type validation to identify common issues as you type.

Get real time code completion and validation as you integrate with supported editors.

Getting started

The first step is to install the Google Pay button module from npm:

npm install @google-pay/button-react

Adding and configuring the button

The Google Pay button can be added to your React component by first importing it:

import GooglePayButton from '@google-pay/button-react';

And then rendering it with the necessary configuration values:

<GooglePayButton
  environment="TEST"
  paymentRequest={{ ... }}
  onLoadPaymentData={() => {}}
  />

Try it out for yourself on JSFiddle.

Refer to component documentation for a full list of supported configuration properties.

Note that you will need to provide a Merchant ID in paymentRequest.merchantInfo to complete the integration. Your Merchant ID can be obtained from the Google Pay Business Console.

Your Merchant ID can be found in the Google Pay Business Console.

Support for other frameworks

We also want to provide an improved developer experience for our developers using other frameworks, or no framework at all. That’s why we are also releasing the Google Pay button Custom Element.

Custom elements are great because:

Like the React component, the Google Pay button custom element is hosted on GitHub and published to npm. In fact, the React component and the custom element share the same repository and large portion of code. This ensures that both versions maintain feature parity and receive the same level of care and attention.

Try it out on JSFiddle.

Google Pay JavaScript library

There's no change to the existing Google Pay JavaScript library, and if you prefer, you can continue to use this directly instead of the React component or custom element. Both of these components provide a convenience layer over the Google Pay JavaScript library and make use of it internally.

Your feedback

This is the first time that we (the Google Pay team) have released a framework specific library. We would love to hear your feedback.

Aside from React, most frameworks can use the Web Component version of the Google Pay Button. We may consider adding support for other frameworks based on interest and demand.

If you encounter any problems with the React component or custom element, please raise a GitHub issue. Alternatively, if you know what the problem is and have a solution in mind, feel free to raise a pull request. For other Google Pay related requests and questions, use the Contact Support option in the Google Pay Business Console.

What do you think?

Do you have any questions? Let us know in the comments below or tweet using #AskGooglePayDev.

Gmail Add-ons framework now available to all developers

Originally posted by Wesley Chun, G Suite Developer Advocate on the G Suite Blog

Email remains at the heart of how companies operate. That's why earlier this year, we previewed Gmail Add-ons—a way to help businesses speed up workflows. Since then, we've seen partners build awesome applications, and beginning today, we're extending the Gmail add-on preview to include all developers. Now anyone can start building a Gmail add-on.

Gmail Add-ons let you integrate your app into Gmail and extend Gmail to handle quick actions.

They are built using native UI context cards that can include simple text dialogs, images, links, buttons and forms. The add-on appears when relevant, and the user is just a click away from your app's rich and integrated functionality.

Gmail Add-ons are easy to create. You only have to write code once for your add-on to work on both web and mobile, and you can choose from a rich palette of widgets to craft a custom UI. Create an add-on that contextually surfaces cards based on the content of a message. Check out this video to see how we created an add-on to collate email receipts and expedite expense reporting.

Per the video, you can see that there are three components to the app's core functionality. The first component is getContextualAddOn()—this is the entry point for all Gmail Add-ons where data is compiled to build the card and render it within the Gmail UI. Since the add-on is processing expense reports from email receipts in your inbox, the createExpensesCard()parses the relevant data from the message and presents them in a form so your users can confirm or update values before submitting. Finally, submitForm()takes the data and writes a new row in an "expenses" spreadsheet in Google Sheets, which you can edit and tweak, and submit for approval to your boss.

Check out the documentation to get started with Gmail Add-ons, or if you want to see what it's like to build an add-on, go to the codelab to build ExpenseItstep-by-step. While you can't publish your add-on just yet, you can fill out this form to get notified when publishing is opened. We can't wait to see what Gmail Add-ons you build!

Google Summer of Code 2016 wrap-up: GitHub

Every year open source organizations, mentors, and university students come together to build and improve open source software through Google Summer of Code (GSoC). This guest post is part of a series of blog posts from people who participated in GSoC 2016.

GitHub-Mark-120px-plus.png


Open source maintainers at GitHub mentored 5 students in Google Summer of Code this year. The students did great work that we’d like to highlight and congratulate them on:

Updates to GitHub Classroom 

GitHub Classroom helps teachers automate their work and interact with students in issues and pull requests. Last summer two students took on projects to help teachers work more efficiently and with greater insight into their classrooms.

Classroom Project #1 

Cheng-Yu Hsu is a student who worked to implement new features suggested by teachers using GitHub Classroom, including due dates for assignment submissions and visualizations of classroom activities. In reflecting on the project, Cheng-Yu said:

"Having a great community is one of the most important factors of a successful open source project, so participating [in] the community is also a huge part of this project. It is great to have chances responding to user feedback, helping people resolve issues and brainstorming new features with them."

Classroom Project #2

Shawn Ding worked on student identifiers and team management for GitHub Classroom. This means that teachers using GitHub Classroom can use things such as student emails to identify their assignments. Teachers can also now manage their students and teams of students using GitHub Classroom via drag and drop in the settings page which then updates the data on GitHub.

Front-end controls for Jekyll

Jekyll Admin is a Jekyll plugin that provides users with a traditional CMS-like graphical interface to author content and administer Jekyll sites from the comfort of their browser. GSoC student Mert Kahyaoğlu has been using Facebook’s React framework to create the front-end that will allow you to write a new post, edit existing pages or add new files. And it will all work with GitHub Pages.

Best of all, Mert's plugin allows people to author content and administer Jekyll sites without knowledge of command line or installing an external text editor like Atom. Once installed, Jekyll users start their site as they would normally and simply append “/admin” to their site's URL to launch the WordPress-like administrative interface. Jekyll Admin's initial release is ready for use on your own site.

Octokit.net 

Alexander Efremov added support to Octokit.net for interacting with the GitHub API using a repository ID, alongside the existing support for providing the owner and repository name. This means integrators do not have to update their systems when a repository changes ownership. The changes to support these APIs were rolled out incrementally over a number of pull requests, and 0.21 release of Octokit.net made these new APIs available to the public.

We had a great time mentoring these students on their projects this year!

By Carol Smith, John Britton and Brandon Keepers, Organization Administrators for GitHub

GitHub on BigQuery: Analyze all the code

Posted by Felipe Hoffa, Google Developer Advocate

Google, in collaboration with GitHub, is releasing an incredible new open dataset on Google BigQuery. So far you've been able to monitor and analyze GitHub's pulse since 2011 (thanks GitHub Archive project!) and today we're adding the perfect complement to this. What could you do if you had access to analyze all the open source software in the world, with just one SQL command?

The Google BigQuery Public Datasets program now offers a full snapshot of the content of more than 2.8 million open source GitHub repositories in BigQuery. Thanks to our new collaboration with GitHub, you'll have access to analyze the source code of almost 2 billion files with a simple (or complex) SQL query. This will open the doors to all kinds of new insights and advances that we're just beginning to envision.

For example, let's say you're the author of a popular open source library. Now you'll be able to find every open source project on GitHub that's using it. Even more, you'll be able to guide the future of your project by analyzing how it's being used, and improve your APIs based on what your users are actually doing with it.

On the security side, we've seen how the most popular open source projects benefit from having multiple eyes and hands working on them. This visibility helps projects get hardened and buggy code cleaned up. What if you could search for errors with similar patterns in every other open source project? Would you notify their authors and send them pull requests? Well, now you can. Some concepts to keep in mind while working with BigQuery and the GitHub contents dataset:
To learn more, read GitHub's announcement and try some sample queries. Share your queries and findings in our reddit.com/r/bigquery and Hacker News posts. The ideas are endless, and I'll start collecting tips and links to other articles on this post on Medium.

Stay curious!