Git events audit log

I’m using the Git events audit log REST API, and I feel that the data returned could be a lot more informative. I refer to the “git.clone” actions in particular.

In General, to clone a GitHub repository you need credentials or a token.
If a GithubApp or a 3rd party service has received a user’s consent and has the necessary permissions, it can also clone the organization or user’s repository.

If some user clones a repository, we’ll see its username in the actor field of the audit logs repsone.
In cases in which a 3rd party service is using a given token, I would expect to see some indication that the clone was performed via a token that was assigned to a GithubApp or 3rd party service.
Currently, the actor field contains the member that gave the consent to the application (integrating user) without any other indication that it was used by some other service.
This means there is no difference whatsoever between a clone that a user performed and a clone that a 3rd party service performed by using a token that the user had assigned to it.

The whole point of the Audit logs is to give admins visibility on the actions performed on their assets.
Therefore, I believe that the token association should be a vital part of the git events audit data.

Hey @ilia-cy :wave:

Thanks so much for joining us here to voice your experience. I’ve had to review some past user interactions, and I’m curious…

You mention that the user who had configured a certain bot was the assigned actor in your returned results from the API. I’ve found that when a bot performs a clone, the event is returned by the audit log API and would list an empty actor value.

Is it possible to let us know which repository you’ve seen these results with? And which bot was used for the clone action?

Hello @nethgato ,
I’ve been analyzing this API for a bit and I can give you 4 different scenarios and their output.

  1. Cloning a repository locally with my own user:
{
    "actor": "ilia-cy",
    "@timestamp": 1622140324733,
    "business": "",
    "org": "<org_name>",
    "repo": "<repo_name>",
    "actor_location": {
        "country_code": "IL"
    },
    "action": "git.clone",
    "transport_protocol_name": "http",
    "transport_protocol": 1,
    "repository": "<repo_name>",
    "user": "",
    "repository_public": false
}
  1. Cloning the repository using a token that was assigned to a 3rd party OAuth application.
    Note that the actor here will be the user that integrated with the application (the one that received the application permission requests and clicked on OK)
{
    "actor": "<username_of_integrating_user>",
    "@timestamp": 1622140344203,
    "business": "",
    "org": "<org_name>",
    "repo": "<repo_name>",
    "actor_location": {
        "country_code": "DE"
    },
    "action": "git.clone",
    "transport_protocol_name": "http",
    "transport_protocol": 1,
    "repository": "<repo_name>",
    "user": "",
    "repository_public": false
}
  1. CircleCI, which clones our repositories via a deploy key that we configured in the relevant repository:
{
    "actor": "",
    "@timestamp": 1622139916962,
    "business": "",
    "org": "<org_name>",
    "repo": "<repo_name>",
    "actor_location": {
        "country_code": "US"
    },
    "action": "git.clone",
    "transport_protocol_name": "ssh",
    "transport_protocol": 2,
    "repository": "<repo_name>",
    "user": "",
    "repository_public": false
}
  1. Clone entry that we encountered by using the REST API on one of our integrated customer organizations:
{
    "@timestamp": 1622013542043,
    "business": "<buisness_name>",
    "org": "<org_name>",
    "repo": "<repo_name>",
    "actor_location": {
        "country_code": "DE"
    },
    "action": "git.clone",
    "transport_protocol_name": "http",
    "transport_protocol": 1,
    "repository": "<repo_name>",
    "repository_public": true
}

As you can see from the examples above, the actor field, which is the most important field in the audit log (along with the repository) can vary between the actual cloner, the user that generated the OAuth token for a 3rd party app, an empty string and even be missing entirely from the audit entry.

This is very confusing and in my opinion needs to be generalized into a meaningful entry that will provide details regarding the cloner and/or the token type it is using.

Please feel free to contact me regarding any specific information you need.

1 Like

Hi there @ilia-cy thanks again for continuing this conversation. I had to re-familiarize myself with the Audit Log REST API and learned that REST for the Audit Log is only available to Enterprise users. And I do see that you have had an exchange with one of our Enterprise Support Engineers about these gaps in functionality.

However for dotcom (and Enterprise) users, GraphQL is available:

…and might solve for the value proposition where feature parity with REST is lacking.

I would say that, for REST, the experience you’ve shared is as we expect currently, and the steps you’ve taken to raise your concerns are everything that you and we can do for now. Our PMs received your feedback from your internal ticket, and engaging the Community here might result in some thoughtful workarounds.

So if perhaps, for business reasons, you must use REST in your workplace, it is what it is for now. However, I’d recommend giving GraphQL a try, and letting us know if you feel similarly about anything that’s lacking for pulling audit log data via our API.

Hello @nethgato ,

I’m specifically interested in clone data.
As far as I can see in the GraphQL interface documentation, there is no clone related data in the Audit entries.
Is that indeed the case?

Hey @ilia-cy

I really should have followed the flow of this conversation better to verify that GraphQL can actually do the thing you want to do. Part of that is due to my lack of experience with GitHub Enterprise, but also a failing in this interaction to pay attention to the details. Which are important!

I too, was unable to locate clone related data in the Audit Log API for GraphQL.

Though I do want to reiterate that while we are happy to have conversations that impact our Enterprise users here in the Community, it is typically best to engage with them directly:

And I did find your ticket with our Enterprise Support folks. For Enterprise users, it’s almost always going to be the best path by interacting directly with them. As features, bugs, etc., will vary depending on the version being used and availability to either Enterprise only, or early access to pre release features that different Organizations might have access to.

So for now, this conversation is best rephrased to our Product Management team through our feedback form:

…for review and consideration. Though I do see that this action was taken in your ticket I mentioned above.

Thanks again for bringing this up here, to note the gap in functionality that exists with the Audit Log API!

:bow: