How the GitHub Security Team uses projects and GitHub Actions for planning, tracking, and more

One of the best parts about working at GitHub is using GitHub to build GitHub—and not only for software development. Many of us have worked for companies that create products we love. Yet fewer of us have worked for organizations that build products across the full software development lifecycle that can be used for almost every piece of our daily flow. Instead of stringing together multiple third-party services to meet our needs, GitHub provides a tool for nearly everything. From relying on Dependabot to keep dependencies secure, to using GitHub Discussions to coordinate team announcements and updates, we’re lucky to have all these best-in-class products at our fingertips.

As Chief of Staff for the Security Team at GitHub, I have the pleasure of using GitHub products to not only help in my day-to-day, but to empower our department to run smoothly. There are so many pieces to how we run product development—from understanding and remediating incidents, to tracking and mitigating incoming bug bounties. But today, I’m going to share how we use the new projects experience and GitHub Actions to plan, manage, and automate our organizational work—a process we endearingly refer to as our “organizational operating system.”

How we use projects to plan and track

Our team consists of engineers, analysts, researchers, and executives across many departments, like product security engineering, security lab, security operations, and more. Inspired by our own product, we all aim to be collaborative and transparent both in how we plan and track our work, which makes pursuing goals easier for all the security teams at GitHub. As such, one of our tasks as a leadership team is creating and tracking long-term, cross-functional initiatives at the beginning of each quarter that span all these teams.

Each objective, key result, and initiative is given its own tracking issue in our github/security repository, with cross-references to each other, details, and links—including a named directly responsible individual (DRI) via the “assignee” field. That way, stakeholders can start from an objective and drill all the way down into team-level work or connect a single task to its broader objective to ensure we’re all aligned.

Never force a human to do what a robot can.

– Motto of the GitHub Security Team

The new projects experience allows us to manage our initiatives flexibly and intuitively. The issues can be filtered and sorted using metadata so we—or anyone at GitHub for that matter—can easily view and categorize them in useful ways. Additionally, projects assigns everything a URL, which is so helpful. The content can also be personalized for the specific viewer. For instance, if you only want a high-level overview, you can get that from the issue. Or, if you want more detail, you can click in further.

As an example, we maintain a single project board to track security reports for two separate incident response teams. The board includes a summary view for executive briefings, as well as a specialized view to highlight high-impact cases or reports that need extra attention. This makes viewing and understanding the board effortless. Check out how the projects team uses projects for all people in the organization, from engineers to team leadership.

Image of how our planning and tracking project looked for our team last quarter

How we use GitHub Actions to automate planning and tracking

All that tracking introduces some administrative overhead, so we rely on automation whenever possible, using the most natural automation tool for us: GitHub Actions. GitHub Actions helps us open issues in bulk, add them to project tracking boards, and even to hold ourselves accountable for regular status updates throughout the quarter. At a regular cadence, DRIs are expected to post a brief comment on the tracking issue, and GitHub Actions automatically updates the project board, allowing us to see each key result’s progress in a single, unified view.

As one specific example, when we need to update the board, we use an open source composite GitHub Action command. This command makes it easy to update the fields of a GitHub project board, regardless of where updates have taken place on GitHub. To use this GitHub Action, we add the following to a YAML file in the repository’s .github/workflows/ directory and customize it with the following:

name: Update status on project board
on:
  repository_dispatch:
    types: [status_update]
jobs:
  update_project:
    runs-on: ubuntu-latest
    steps:
      - name: Update status
        uses: github/update-project-action
        with:
          github_token: $
          organization: github
          project_number: 1234
          content_id: $
          field: Status
          value: $

name: Update status on project board
on:
  repository_dispatch:
    types: [status_update]
jobs:
  update_project:
    runs-on: ubuntu-latest
    steps:
      - name: Update status
        uses: github/update-project-action
        with:
          github_token: $
          organization: github
          project_number: 1234
          content_id: $
          field: Status
          value: $

Note: The above step can be repeated multiple times in a given job to update multiple fields on the same or different projects.

Wrap up

Our team is allergic to process for process’ sake. We only want tools that help us do what we do better in a native, non-intrusive way. Pairing projects with some light automation removes the burden of project tracking and the time commitment of weekly status updates. It meets our team where they are.

I hope our use cases have inspired you for your team’s planning and tracking. Find out how to get started with projects in our GitHub Docs here, and see our latest ships in our Changelog.