# Git Push Monitoring

Nightfall monitors the following signals during a Git push operation:

* The endpoint where the push originates
* The user performing the push
* The Git protocol (HTTPS / SSH)
* The remote destination URL
* The repository name and configured remotes

```
Managed Endpoint with Nightfall agent
   └── git push
        ├── Action: Git Push
        ├── Source: Managed device
        └── Destination:
             ├── Approved domain → Allowed
             └── Non‑approved domain → Exfiltration Event generated
```

A Git Push Monitoring policy evaluates where code is being pushed, not what is being pushed. If the destination does not match your approved Git domains, Nightfall generates an exfiltration event.

**Supported Git Destinations**

Git Push Monitoring supports:

* GitHub Cloud
* GitLab Cloud
* Bitbucket
* Any Git server accessible via HTTPS or SSH

**Policy Configuration**

1. **Step 1: Define Approved Git Destinations**

Customers define approved Git hosting locations using Domain Collections.

Examples:

* github.com/my‑company‑org/\*
* gitlab.company.com/\*
* bitbucket.org/company/\*

These domains represent where source code is allowed to be pushed.

2. **Step 2: Configure Git Push Monitoring Policy**

Policy Type: Endpoint Exfiltration\
Action: Git Push

Destination Condition Options:

* Any domain
* Domain in approved list
* Domain not in approved list (recommended)

Recommended Configuration:

```
Action: Git Push
For: Domain not in <Approved Git Domains>
```

This configuration alerts when developers push code outside approved repositories.

**Example Use Cases**

1. **Prevent Personal GitHub Usage**
   1. Approved: github.com/company‑org/\*
   2. Detected: github.com/john‑doe/test‑repo
2. **Monitor Scratch or Temporary Repositories**
   1. Even if the repository is newly created or unnamed, Nightfall detects the push if the destination domain is not approved.
3. **Enforce Corporate GitHub & GitLab Usage**
   1. Ensure all production code stays within:
      1. Corporate GitHub organizations
      2. Internal GitLab instances

**Event Details**

When a Git push violates policy, Nightfall generates an event with metadata‑only context.

**Event Summary Fields**

| Field           | Description                 |
| --------------- | --------------------------- |
| Event Type      | Git Push                    |
| Repository      | Repository name             |
| Actor           | User performing the push    |
| Device          | Endpoint hostname           |
| Destination URL | Git remote URL              |
| Git Remotes     | origin, personal, etc.      |
| Risk            | Critical, High, Medium, Low |

**Example Scenarios**

The following scenarios illustrate the support matrix for this capability.

1. **Push to Approved Repository**
   1. Git operation succeeds
   2. No alert generated
2. **Push to Non‑Approved Repository**
   1. Git operation succeeds (no blocking)
   2. Exfiltration event generated
3. **HTTPS and SSH Both Supported**
   1. Detection works for both authentication methods
4. **Multiple Remotes Supported**
   1. Events reflect the actual remote used for the push
5. **Unmanaged Devices**
   1. No detection occurs without an endpoint agent

Git Push Monitoring provides organizations with a simple and effective control to:

* Detect source code exfiltration
* Enforce approved Git destinations
* Gain visibility into developer Git activity