Supply Chain PyPI gitsage-local Install or Execution

How the attack works

The detection looks at process command lines for the exact string 'gitsage-local' appearing as the target of a pip install/upgrade command, or being invoked directly as a console command or Python module. It only fires on this specific package name, not on generic dependency installs or unrelated tools. It does not track what the tool does afterward — whether it actually reads repository files or writes commits is outside what this rule can see, since those events aren't available to correlate. It is purely a visibility check: package appeared, or was executed.

Netzilo detection

Why it matters

On its own this only tells you the package was installed or run somewhere in your environment. There is no known malicious version, CVE, or indicator of compromise tied to gitsage-local; the risk is that any tool with LLM access and repo write privileges is a new avenue for data exposure or unwanted commits if it is later found to be malicious or misconfigured, and organizations may not know it's running until this fires.

What you can do

• →Treat each alert as a discovery event, not an incident: confirm whether the team or developer intentionally adopted this tool.
• →If adoption is approved, suppress the alert for that specific endpoint or team rather than disabling the rule broadly.
• →Review what repository and credential access the tool has when running, since it operates with the developer's own permissions.
• →Check CI/CD and container build pipelines for pinned installs of this package and decide if that usage is sanctioned.

Known benign look-alikes

• A developer or team that has deliberately adopted gitsage-local and installs or runs it as part of normal workflow. This rule reports every such invocation by design; suppress per-endpoint once the package is approved rather than widening the pattern.
• CI/CD or container build steps that install the package from a pinned requirements or lock file where the distribution name is expanded onto the command line by the build tool (e.g. a generated "pip install gitsage-local==x.y.z" step).
• Editable or local development installs of a fork of the same project ("pip install -e ." run from a checkout named gitsage-local).
• Reinstall/upgrade churn on developer machines, which produces repeated identical reports for the same benign package.
• Shell history replay, dotfile bootstrap scripts, or setup documentation executed verbatim, where the install command is intentional and human-initiated.

References

• https://pypi.org/project/gitsage-local/
• https://attack.mitre.org/techniques/T1195/002/
• https://atlas.mitre.org/techniques/AML.T0010

Related threats