Skip to content

New Audit Log events and event context

GitHub's audit log allows admins to quickly review the actions performed by members of their Enterprise. It includes details such as who performed the action, what the action was, and when it was performed. To ensure the audit log can be used as an effective security and compliance tool, GitHub is constantly evaluating new audit log events and ensuring those events have the necessary fields to provide meaningful context. GitHub has made the following enhancements to the Enterprise audit logs:

  • business.sso_response and org.sso_response events will be displayed in the REST API and audit log streaming payloads for GitHub Enterprise Cloud (GHEC) and GitHub Enterprise Server (GHES) version 3.8 or later.
  • repo.rename, project.rename, and protected_branch.update_name events will now include the old_name field make clear the current and past name of renamed repos, projects, and protected branches.

GitHub Actions: Use the GITHUB_TOKEN with workflow_dispatch and repository_dispatch

Customers will now be able to use the GITHUB_TOKEN with workflow_dispatch and repository_dispatch events to trigger workflows. Prior to this change, events triggered by GITHUB_TOKEN would not create a new workflow run. This was done to prevent the accidental trigger of endless workflows. This update makes an exception for workflow_dispatch and repository_dispatch events since they are explicit calls made by the customer and not likely to end up in a loop.

name: Create Workflow Dispatch

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.actions.createWorkflowDispatch({
              owner: context.repo.owner,
              repo: context.repo.repo,
              workflow_id: 'test.yml',
              ref: 'main',
            })

For more details see
Triggering a workflow from a workflow.

For questions, visit the GitHub Actions community.

To see what’s next for Actions, visit our public roadmap.

See more

Dependabot unlocks transitive dependencies for npm projects

Your GitHub repositories with Dependabot alerts enabled and Dependabot security updates enabled will automatically generate Dependabot pull requests for vulnerable npm transitive dependencies.

Previously, Dependabot couldn't generate a security update for a transitive dependency when its parent dependency required incompatible specific version range. In this locked state, developers had to manually upgrade the parent and transitive dependencies.

Now, Dependabot will be able to create pull requests for npm projects that upgrade both the parent and child dependencies together.

For example, if a vulnerability for the transitive dependency node-forge triggers a Dependabot alert and allows a PR to be created:

2 generated security update white bg

Prior to this change Dependabot would fail to create a Dependabot security update for transitive dependencies 😕. But not anymore! 😁 Now, Dependabot will unlock the node-forge security update by bumping the parent webpack-dev-server version in addition to patching the `node-forge dependency within the same Pull Request!

3 update PR white bg

This change will apply to pull requests generated by Dependabot that update vulnerable npm packages.

See more
View all changes