BOTTLENECK
0 articles opened

Front · Infographic · p. 06–07

What actually happens

Two timelines, same repository. The top is git clone. The bottom is securegit acquire. Read them against each other.

git clone

  1. t+0

    Network fetch begins

    None yet

  2. t+2s

    Objects written into .git

    Disk write, your permissions

  3. t+3s

    Hook scripts land in .git/hooks

    Dormant executables now on disk

  4. t+3s

    .gitmodules, .gitattributes land

    Filter and submodule directives, unread

  5. t+4s

    Working tree checkout

    Paths written per attacker-influenced names

  6. t+4s

    Clone reports success

    You believe you have data. You have data and configuration.

  7. t+30s

    You cd in and run anything git-adjacent

    Hooks may execute. Filters may execute.

  8. t+45s

    You open the repo in an editor with extensions

    Editor-level execution surface

securegit acquire

  1. t+0

    Fetched as an archive, not as a live repo

    Inert bytes

  2. t+2s

    Archive extracted to a staging path

    Files on disk, no git configuration active

  3. t+2s

    Hooks stripped

    Dormant executables removed, not merely ignored

  4. t+3s

    Scanners run across the tree

    Findings collected

  5. t+4s

    A sanitization report is written alongside

    You have something to read

  6. t+5s

    Converted into a normal git repository

    Now it is a repo — after inspection

  7. t+5s

    A chain receipt records the acquisition

    Provenance from moment zero

The three things people get wrong

Myth

I only clone repos I trust.

You clone repos your dependencies trust, which is a different set and a much larger one. You also clone repos an agent selected on your behalf from a search result. The trusted-source model assumes a human evaluated the source. Increasingly, none did.

The question is not “do I trust this” but “did anyone actually look.”

Myth

My scanner catches this.

Most scanning runs in CI, which is after the clone, on a machine that is not yours, looking at the tree rather than the repository metadata. The hooks that concern us are in .git, which most scanners exclude by default and which CI usually does not receive.

Scan the .git directory. Most tools do not, by default. Check yours.

Myth

This is theoretical.

Hook execution and path-handling behavior in git have produced real, patched CVEs on multiple occasions. The mitigation is always “upgrade git,” which works until the next one, and which does nothing about the window between disclosure and your fleet actually upgrading.

Defense in depth exists because point fixes arrive late and unevenly.