GenScript.AORA detected in gstack-connect-chrome - false positive? + Supply chain hardening proposal #545
Description
This is raised in good faith — not an accusation, simply a flag worth surfacing publicly so others can weigh in and the project can consider some low-effort hardening steps.
After updating gstack today (2026-03-27) my antivirus flagged a GenScript.AORA threat in the connect-chrome skill files. I'm fairly confident it's a false positive. But I can't be 100% certain without confirmation, and the broader question of supply chain hardening seems worth raising regardless.
| Field | Detail |
|---|---|
| Threat name | GenScript.AORA (generic heuristic, not a named payload) |
| Location | /.agents/skills/gstack-connect-chrome/SKILL.md |
| Trigger | Updated via /gstack-upgrade |
| AV product | ESET Smart Security Premium on Windows 10 |
Screenshot
Question 1 — Has anyone received an AV warning when updating or using gstack?
Has this come up before in any form — during install, upgrade, or normal use? Any AV product, any OS, any skill or binary.
If this is a known recurring false positive, a note in the README or a pinned issue would go a long way. If it hasn't come up before, that's also worth knowing.
Question 2 — Supply chain hardening
First, let me be clear: this is not about distrust. gstack, Garry Tan, and Y Combinator have built something genuinely excellent — gstack has fundamentally changed the way I use Claude, and I mean that sincerely. But precisely because we're starting to depend on it heavily, we should make sure that dependence is built on solid ground.
Supply chain attacks are no longer a niche threat. They hit solo developers, small teams, and Fortune 500 companies alike — xz, event-stream, node-ipc, faker.js — the pattern is well established and accelerating. Blind trust in any fast-moving dependency, no matter how reputable the maintainer, is a risk posture we should all be moving away from.
The specific concern here: gstack pulls directly from GitHub and ships updates at high frequency. A poisoned dependency could land between releases and go unnoticed.
Suggested hardening
CI scanning: there are actions to scan with VirusTotal and ClamAV and others, they could be scheduled every day or on push.
A scan-skills meta-skill (gstack-native approach):
gstack already ships a security-oriented skill (/cso). The natural extension is a dedicated scan-skills skill that periodically audits the installed skill tree — checksums, unexpected file changes, known-bad patterns. A skill that watches the other skills. This fits the gstack model perfectly and would give users confidence without requiring them to set up external tooling.
Note: Yes, a
scan-skillsskill could itself get compromised — that's a fair objection. But even an imperfect scanner raises the bar significantly. A compromised scanner would have to actively hide findings to be dangerous, which is a much harder and more detectable attack than silently poisoning a passive skill file. Layered, imperfect defenses beat no defense.
For reference, Cisco has already built exactly this for the broader agent ecosystem:
cisco-ai-defense/skill-scanner — detects prompt injection, data exfiltration patterns, and malicious code in agent skill files using static analysis + LLM semantic analysis + behavioral dataflow. It even has a pre-commit hook and a GitHub Actions workflow ready to drop in. Worth evaluating as either a direct integration or an inspiration for a gstack-native equivalent.
The goal isn't to slow gstack down — it's to make sure the speed stays safe.