GitHub Partner Portal

Getting Started with Ingesting GitHub GHAS Alerts slides

2022-05-26T00:00:00+00:00

These slides provide an overview of how to ingest GitHub Advanced Security alerts into third party solutions.

Figma Widget

2022-05-12T15:35:40+00:00

Go from brainstorming and planning to building with fewer steps in between with the new GitHub widget for FigJam!

Go from brainstorming and planning to building with fewer steps in between with the new GitHub widget for FigJam!https://t.co/SRiheAuQOU pic.twitter.com/D3B1qLg2wH
— GitHub (@github) May 10, 2022

Cloud 66

2022-05-12T07:04:15+00:00

Cloud66’s new GitHub App: Deploy your code, directly from the repository to your own servers on any cloud.

🥁 Cloud 66 is available on GitHub Marketplace. Now you can deploy your code, directly from the repository to your own servers on any cloud. @GitHubEnt @GitHub https://t.co/nFTfeEI47K pic.twitter.com/i97OYG6PXY
— Cloud 66 (@cloud66) May 11, 2022

GitHub Partner Program Newsletter – Apr 2022

2022-04-25T17:36:46+00:00

If you want to receive emails when we have future Newsletters, sign up: GitHub Technology Partner Program

So what’s new?

[GitHub Beta Feature Opportunity]: API Versioning Private Beta The current version of GitHub’s REST API is v3 and has been for over 10 years. Moving forward, we want to introduce a new versioning approach to the REST API that uses the YYYY-MM-DD API version-naming scheme and which indicates the date the API version was released. We’re looking to collect feedback until the end of May 2022. By providing your opinion, you will be able to help influence the direction of API versioning at its earliest stages.

Email us at partnerships@github.com with the subject line “API Versioning Beta: [Your Company Name]” if you would like to provide feedback on API versioning

New GitHub Issue closed reasons Last year we introduced updates to our issue icons and colors along with the commitment to address your feedback on showing the reason why an issue had been closed. Today we are starting to roll out a preview of issue closed reasons to a small group of users. Your repository should have been feature flagged in, let us know if you have any questions!

GHES Storage Partners Partners in the GitHub Technology Partnership Program have the opportunity to self-validate their storage solutions with GHES. More information on the how to get listed and details here, or email us at partnerships@github.com

Reminders

Co-market with GitHub! If you created a brand new GitHub Action or App and post it in the GitHub marketplace, we’d be happy to assist with amplifying your announcement. More info on our co-marketing guidelines here

Secure your API tokens by joining the GitHub secret scanning program We’re continuing to expand our secret scanning program. If your service issues API keys or other secrets end up committed in code, we can help you detect them if/when they’re ever leaked on GitHub. For example, via the secret scanning program we notify AWS when their credentials are found in public repos, allowing them to automatically protect their users. [Find out more about secret scanning]

If you need to update your Marketplace logo We’ve been getting some questions around how to update your Marketplace action or app logo. Please look at our guide with the necessary logo requirements. Co-marketing guide.

Verified apps on the Marketplace are being updated to ‘verified creator’ Learn about the badges that you may see for some apps and actions listings on GitHub Marketplace, and how you can get yours! [Marketplace badges]

Partner-owned documentation to docs.github.com A paved path now exists for our partners to contribute and maintain documentation on docs.github.com. This provides an opportunity for our partners to describe how their tools work with GitHub. [Open an issue using the appropriate template]

Integrating with code scanning A new pattern guide on how to integrate with code scanning is now available on our Partner Resources tab, applicable to all partners with a SAST offering. If your team has a static analysis tool, we built a new pattern guide on how to integrate with code scanning. It shows you how you can surface security vulnerabilities directly in the GitHub UI before developers deploy to production. [Our new guide]

Join our Technology Partner Program Get access to GitHub Enterprise Server developer licenses, a plethora of integration resources and guides, invites to private partner events, discounts on Event Sponsorships (GitHub Universe is coming up!), comarketing opportunities, and more. Our program has no cost. [Apply today]

You know where to reach us

As always, feel free to reach out to us for questions at partnerships@github.com or support.github.com

Happy coding!

Eversql GitHub Action to optimize SQL queries automatically

2022-04-21T00:00:00+00:00

Using @GitHub Actions? You can now optimize SQL queries automatically with @EverSQL, boosting your CI/CD and making your code faster 🚀 https://t.co/CAQ5lmUukU
— EverSQL (@EverSQL) April 20, 2022

Automating SLO-as-code with GitHub Actions and Nobl9

2022-04-21T00:00:00+00:00

Nobl9’s new GitHub Action: customers will be able to leverage the GitHub Action to ensure their SLOs are updated in Nobl9 whenever they make changes to their SLO definitions in source code.

Customers can now update their SLO configurations in Nobl9 with @GitHub Actions. Learn more about our integration with @GitHubEnt: https://t.co/Or77bNvY7z #SLO #GitHub
— Nobl9 (@nobl9inc) April 14, 2022

Perforce launches new GitHub Actions to help game developers

2022-03-23T00:00:00+00:00

Today, Perforce has launched a new GitHub Action in the GitHub marketplace that will help game developers integrate their Helix Core environment with GitHub. The new action will enable developers building game pipelines on Helix Core to trigger GitHub Actions.

Game studios using both GitHub and Perforce have built custom complex pipelines to keep their code and assets in sync. This first party integration facilitates the use of GitHub Actions as an orchestrator for code and assets stored in Helix Core.

This work is an important piece to the strategic partnership that was announced today with Microsoft and Perforce to make it easier to extend game production into the cloud for game creators of all sizes.

Learn more about the work that Perforce has created and go over to Discussions to participate.

Welcome to our new Technology Partner Resources Page

2022-03-15T08:00:52+00:00

Welcome!

We’re happy to announce that we have launched our new Technology Partner Resources Page! 🎉 The Partner Hub provides access to all the resources you need so that we can work together to create incredible experiences for our shared customers.

As a first step, evaluate which GitHub Partner Program to join. The Technology Partner program is for ISVs, integrators, and cloud service providers that want to extend the GitHub platform and co-market with us, while the Service and Channel Partner Program is for service-oriented and resell partners that want to deliver services to our joint customers and co-sell with us.

Partner Program Requirements

For the Technology Partner Program, see the Program Requirements section on the Technology Partners tab.
For the Channel Partner Program, see our Services & Channel Partners Handbook.

Where to get started

Get started by browsing through the below articles:

Technology Partners

Platform integration 101 slides - Overview of how to build technical integrations with GitHub
Learn GitHub Actions - Guide to help you use GitHub Actions to accelerate application development workflows
GitHub Apps 101 slides - Introduction to GitHub Apps
GitHub Technology Partner Program: Co-marketing with GitHub - When you’re close to launching an integration in our Marketplace, we can help you co-market!

Services & Channel Partners

GitHub Services & Channel Partners Handbook - Accelerate your business and help your customers reach their full DevOps potential
GitHub Channel Partner Value Proposition - Market opportunities, partner growth insights, and GitHub orientated offerings for partners

Partner Hub Updates

Check out our new Resources and Newsfeed sections:

Resources

The Resources section contains info on topics such as integration and go-to-market.

Newsfeed

We will continuously update the Newsfeed with key information such as partner-related product updates, events, and more. Stay tuned for our quarterly newsletter with all of our ecosystem updates.

Releasing and maintaining actions

2021-03-19T00:00:00+00:00

Problem statement

So you have created an action…now what? This pattern guide shows a minimal solution to releasing and maintaining actions in open source, favoring automation whenever possible, providing value while keeping overhead at a minimum.

The solution should:

Leverage GitHub Actions for continuous integration, dependency updates, release management, and task automation.
Promote discoverability with regular publishing to GitHub Marketplace.
Provide confidence through automated tests and build badges.
Indicate how the action can be used, ideally as part of a broader workflow.
Signal what type of community contributions you welcome, e.g. issues, pull requests, or vulnerability reports.

Solution

We recommend that Technology Partners build actions with JavaScript instead of in containers for speed and cross-platform functionality, so this guide will focus on JavaScript actions.

Though they are “just” Node.js repositories with metadata in an action.yml file, JavaScript actions have a few interesting properties compared to traditional Node.js projects:

Dependent packages are committed alongside the code, typically in a compiled and minified form, so automated builds and secure community contributions are important.
Tagged releases can be published directly to GitHub Marketplace and consumed by workflows across GitHub, making sensible releasing and tagging of special interest.
Many actions make use of the GitHub API and third party APIs, so we encourage robust end-to-end testing.

We base a solution on actions/javascript-action, putting special focus on solving the problem areas identified above. We use GitHub Actions to automate releasing the action and publishing to GitHub Marketplace, and open source best practices to increase confidence and usage.

Implementation

Automate release management

GitHub recommends creating releases using semantically versioned tags – for example, v1.1.3 – and keeping major (v1) and minor (v1.1) tags current to the latest appropriate commit. When a release is created, it can be published to GitHub Marketplace for increased discoverability.

^
|
|
| * commit 9a4eb0d (tag: v1, tag: v1.1, tag: v1.1.0)
|/  Author: Octocat <octocat@github.com>
|
|      New features!
|
|  
| * commit ac2415 (tag: v1.0, tag: v1.0.3)
|/  Author: Octocat <octocat@github.com>
|
|       Initial release
|
*
|
main

We let GitHub Actions do the automation for us to enable this workflow:

Do feature work in branches per GitHub flow.

When a feature branch commit is pushed, GitHub Actions runs a test workflow from which you can call unit and integration tests.

Create pull requests to the main branch to initiate discussion and review, merging when ready.

When a pull request is opened, either from a branch or a fork, GitHub Actions again runs the test workflow, this time with the merge commit. A label workflow also runs to add appropriate labels to the pull request depending on which file path is being changed.
Note: for security reasons, workflows triggered by pull_request from forks have restricted GITHUB_TOKEN permissions and do not have access to secrets. If your tests or other workflows triggered upon pull request require access to secrets, consider using a different event like a manual trigger or a pull_request_target. Read more here.

Create a semantically tagged release using the GitHub UI, also publishing to GitHub Marketplace with a simple checkbox.

When the release is created, GitHub Actions runs a publish workflow that uses a community action, JasonEtco/build-and-tag-action to compile and bundle the JavaScript and metadata file and force push semantic major, minor, and patch tags as visualized above.

Unlike some other automated release management strategies, we intentionally do not commit dependencies to the main branch, only to the tagged release commits. By doing so, we encourage users of our action to reference named tags or shas, and we help ensure the security of third party pull requests by doing the build ourselves during a release.

Committing to semantic releases means that the users of your actions can pin their workflows to a version and know that they might continue to receive the latest stable, non-breaking features, depending on their comfort level:

### A workflow consuming your action

# The latest major release version:
uses: github-developer/javascript-action@v1

# Or, the latest minor release version:
uses: github-developer/javascript-action@v1.1

# Or, the latest patch release version:
uses: github-developer/javascript-action@v1.1.0

# Or, a specific commit sha:
uses: github-developer/javascript-action@ff958b3d4b36abb3d3058e1e866695ce6111d213

Open source like the best

Working in the open can be hard, but fortunately, GitHub provides tools and guides to make it easier. Here are a few structures we recommend setting up for healthy bidirectional communication.

By providing the following signals to the community, we encourage use, modification, and contribution to our action:

Maintain a great README with plenty of usage examples, guidance, and badges
- How to add a workflow status badge (docs)
- Other metadata badges (shields.io)
Set up community health files like CODE_OF_CONDUCT, CONTRIBUTING, and SECURITY, either organization-wide or in your action repository.
Keep issues current by utilizing actions like stale

Check out more resources for building in the open here.

Concrete implementation

Template repository: https://github.com/github-developer/javascript-action

Examples

Examples where similar patterns are employed include:

Integrating with Code Scanning

2021-03-09T00:00:00+00:00

Problem statement

Many of GitHub’s Technology Partners offering security products in the form of static analysis tooling, wish to surface their tools’ security findings directly in GitHub’s UI, making it easier for developers to adopt their tooling, and adding value to the development workflow by identifying potential vulnerabilities before they reach production. This kind of developer workflow is often associated with DevSecOps and the concept of shifting left, as security analyses are performed frequently and earlier in the development process.

Solution

A paved path exists that is tailored for this type of integration in the form of GitHub code scanning, a developer-first, GitHub-native approach to easily find security vulnerabilities before they reach production.

Technology Partners can integrate their tooling with code scanning by submitting analyses in the Static Analysis Results Interchange Format (SARIF) (v2.1.0) format to GitHub. This format is specified formally here, however GitHub code scanning supports only a subset of the properties, which are listed here.

The analysis is typically triggered by events originating from GitHub, such as developers pushing code (the push event), opening a pull request (the pull_request event), or on some pre-determined automated schedule (i.e. once per week).

Two implementation approaches are available, via GitHub Actions, or via GitHub Apps, each of which are explored further below.

Prior to diving in to the implementation detail, it is worth designing how your tool should structure its output using the SARIF format, with consideration for the SARIF properties that are supported by GitHub code scanning.

Commonly, this will be an iterative process:

Generate your SARIF report (potentially by hand, at least initally)
Validate your SARIF report, using the online SARIF validator at sarifweb.azurewebsites.net/Validation
- Important: It is recommended to enable GitHub ingestion rules, for additional code scanning compatibility validation
Upload your SARIF report to GitHub code scanning for visual verification. Note: Code scanning is available for all public repositories and for private repositories owned by organizations where GitHub Advanced Security is enabled. For more information, see About GitHub Advanced Security.
- Uploading may be done using the REST API, via a curl command. Note, the SARIF report must be gzipped and base64-encoded prior to being uploaded to GitHub.
- Alternatively, commit the SARIF report directly to a GitHub repo and upload it to code scanning using the github/codeql-action/upload-sarif action.
Repeat.

Example SARIF report

An example SARIF report (generated by the Brakeman tool for an intentially vulnerable Ruby on Rails application), whose structure was designed by following the process outlined above, is available:

The following points warrant special mention:

The output conforms to version 2.1.0 of the SARIF spec, as indicated by the top-level version and schema properties, and confirmed by the online SARIF validator
The top-level runs object is an array containing a single element, an object representing the tool, rules, and results of the run.
- The tool’s semanticVersion is useful to include, it’s helpful for ingestion systems to know run-over-run if a tool is updated.
The rules array represents the set of vulnerabilities that the tool scans for, each rule is represnted by an id, name, fullDescription, helpUri, help text, and an additional properties bag
- Each rule’s id uses a prefix that is representative of the tool name, BRAKE in this instance, followed by a numeric identifier. This helps with filtering of rules in the GitHub code scanning UI
- Each rule’s name is a hierarchical property, this makes sense for this particular tool and othes may also adopt this pattern where it makes sense
- Each rule’s fullDescription ends with a period, which helps facilitate a consistent user experience when the rule is rendered by GitHub code scanning
- Each rule’s help references an external article via a URL. Generally it is preferred to include the help text inline, within the SARIF report, but for this implementation this was not straightforward, and will hopefully be addressed in a subsequent iteration.
The results array captures the results of the analysis, with each violation of a rule being captured in a single result entry. For example, rule BRAKE0014 is violated five times, as indicated by results on lines 437, 458, 479, and 500, 521
- Each result’s entry references the rule being violated, via the rule’s id and position in the rules array
- Each result’s entry maps onto a source file via the locations array, for portability across systems, the uri is expressed a path relative to %SRCROOT%

The following screenshot shows the GitHub code scanning representation of a violation of rule BRAKE0014, derived from the corresponding result object on lines 520 through 540.

Note, this is a relatively straightforward SARIF report, more sophisticated constructs are possible. To learn more, it is recommended to follow the SARIF tutorials, and review the specification.

Implementation detail

Once you are satisfied with the structure of the SARIF produced by your tool, there are two primary approaches when integrating it with code scanning:

Via GitHub Actions
Via GitHub Apps

The former is generally applicable where:

The tooling is installable as a CLI tool that can easily execute on GitHub’s compute (e.g. Brakeman, detekt), -or-
The tooling may be easily invoked via public or authenticated API calls. Tokens for authentication may be held in GitHub as encrypted secrets.

The latter is more suitable for solutions that have unique compute requirements, or that have user-facing elements (such as configuration controls or dashboards), potentially via a dedicated web UI or control panel.

GitHub Actions and GitHub Apps are both covered in more detail in the Platform Integration 101 presentation.

Additional resources are also available for both GitHub Actions and GitHub Apps

Onboarding your integration into the GitHub code scanning UI

When complete, the onboarding of your integration into the GitHub code scanning can be initiated by opening a new pull request in the actions/starter-workflows repo. Additional instructions are located in the pull request template.

Publication to GitHub Marketplace

In addition to onboarding into the code scanning UI, we highly recommend publishing your integration to Marketplace for increased visibility.

Additional information is available for both GitHub Actions and GitHub Apps.

Examples

Existing implementations and examples are available:

Brakeman SARIF implementation: github.com/presidentbeef/brakeman/pull/1500 (Brakeman is an open source statis analysis tool, popular in the Ruby on Rails community)
Code Scanning playground: github.com/swinton/code-scanning-playground (a forkable template repo, showing a simple code scanning workflow leveraging ESlint)

Resources for learning SARIF

Useful resources for learning SARIF are available:

SARIF tutorials from Microsoft: github.com/microsoft/sarif-tutorials
SARIF Validator web-based tool: sarifweb.azurewebsites.net/Validation
SARIF specification, v2.1.0: docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html

Further documentation

Further documentation is available on GitHub.com, including:

SARIF support for code scanning: docs.github.com/github/finding-security-vulnerabilities-and-errors-in-your-code/sarif-support-for-code-scanning
Code scanning REST API: docs.github.com/rest/reference/code-scanning

GitHub Partner Portal

Getting Started with Ingesting GitHub GHAS Alerts slides

Figma Widget

Cloud 66

GitHub Partner Program Newsletter – Apr 2022

So what’s new?

Reminders

You know where to reach us

Eversql GitHub Action to optimize SQL queries automatically

Automating SLO-as-code with GitHub Actions and Nobl9

Perforce launches new GitHub Actions to help game developers

Welcome to our new Technology Partner Resources Page

Welcome!

Partner Program Requirements

Where to get started

Technology Partners

Services & Channel Partners

Partner Hub Updates

Resources

Newsfeed

Releasing and maintaining actions

Problem statement

Solution

Implementation

Automate release management

Open source like the best

Concrete implementation

Examples

Related

Integrating with Code Scanning

Problem statement

Solution

Example SARIF report

Implementation detail

Onboarding your integration into the GitHub code scanning UI

Publication to GitHub Marketplace

Examples

Related

Resources for learning SARIF

Further documentation