Front · Editor's letter · p. 04–05
The repository is the attack surface
You have spent your career securing what you deploy. The thing you never secured is the moment code arrives on your machine.
Here is a thing every engineer knows and almost nobody acts on. git clone is not a download. It is a download plus a filesystem write plus, depending on what is in the archive and what you do next, code execution. Hooks. Submodule configuration. Filter drivers. Path handling quirks that have produced real CVEs in real git releases more than once.
The repository is not data that you then choose to run. It is a bundle of data and executable configuration that you have invited onto your machine, inside your home directory, with your permissions. You know this. So does everyone. And then a colleague posts a link, and you clone it, because the alternative is not cloning it, and that is not a real alternative.
Two years ago you cloned a handful of repositories a month, and you had usually heard of them. Now an agent working on your behalf pulls down a dependency you have not evaluated, to check whether its API does what a search result claimed. It does that at three in the morning while you are asleep, using your credentials, on your machine. The judgment step that used to sit between “I found this repository” and “it is now on my disk” has been compressed to nothing.
git clone is not a download. It is a download that has been granted permission to run.
That is the bottleneck this issue is about. Not “can I get the code” — that was solved decades ago. Can I get the code without the act of getting it being the vulnerability, and can I prove afterward what arrived and what I did with it.
Once you accept that code arrival is an event worth controlling, you notice that code departure is too. A push is the first moment your work crosses onto shared infrastructure. Six months later somebody asks — audit, incident, customer questionnaire — and the honest answer is that you have git history, which tells you what changed and who the commit claims to be from, and nothing else. Git history is a record of assertions, not a record of evidence.
Git history is a record of assertions, not a record of evidence. That was the right design for 2005. It is an expensive gap in 2026.
What this will cost you
- A new verb. You will type acquire instead of clone for untrusted repositories. Page 16 is entirely about making that cheap.
- Seconds, and occasionally a minute. On a normal working repository scanning is fast enough that you will stop noticing. On a very large repository it is not, and the performance page gives you real numbers rather than reassurance.
- Some false positives. Every scanner produces them. A scanner that claims otherwise is either lying or not looking hard.
- A conversation with your team. The twelve objections include the three cases where the honest answer is “you are right, do not use this for that.”
What you get for it: code that arrives without executing, commits that cannot silently ship a secret, pushes that carry proof, and a genuine answer to the question “what did we know about our supply chain in March.”