<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Goose (Block) Security - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/goose-security/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 08:31:28 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Goose vs Microsoft Autogen - which has a better security posture?</title>
                        <link>https://openclawsecurity.net/community/goose-security/goose-vs-microsoft-autogen-which-has-a-better-security-posture/</link>
                        <pubDate>Wed, 15 Jul 2026 03:00:12 +0000</pubDate>
                        <description><![CDATA[Hello everyone,

First, I want to say how grateful I am for this community. I’ve learned so much just reading through these threads. I’m relatively new to deploying agent frameworks in a ser...]]></description>
                        <content:encoded><![CDATA[Hello everyone,

First, I want to say how grateful I am for this community. I’ve learned so much just reading through these threads. I’m relatively new to deploying agent frameworks in a serious way, and I’m trying to be very mindful of security from the start in my homelab setup.

I’m currently evaluating two open-source multi-agent frameworks: Goose (from Block) and Microsoft’s Autogen. My primary use case involves a Python-based workflow for automating some data analysis and report generation, all running inside Docker containers on a private network. While functionality is important, my deciding factor is likely going to be which one has a fundamentally better security posture I can build upon.

I’ve been reading the docs for both and have some initial thoughts, but I’d really appreciate the expertise here to help me see what I might be missing. My concerns naturally lean towards container security, credential isolation, and the risks introduced by the extension/agent model.

Here’s my layman’s breakdown of where I see the security considerations for each:

*   **Goose (Block):**
    *   Its extension model is very powerful, but it makes me nervous. Each extension runs in its own sandbox, which is good, but the documentation mentions the “local execution context” for trusted extensions. I worry about properly configuring that boundary.
    *   I like that it’s open-source and from a company (Block) with a security focus, which should help the audit story. But being a newer project, has the codebase been scrutinized enough?
    *   How does credential handling work for extensions that need API keys? Is there a secure injection mechanism, or do they risk being exposed in the agent’s memory space?

*   **Microsoft Autogen:**
    *   It feels more “academic” in its approach, with a heavy focus on the agent conversation patterns. The security seems a bit more… implicit?
    *   It’s also open-source, but under the Microsoft umbrella. Does that lead to more eyes on the code, or does it get lost in a huge org?
    *   I’ve seen that you can deploy agents as Docker containers, which is my plan. But I’m less clear on how it manages inter-agent communication security and if there’s any built-in principle of least privilege for what tools an agent can access.

My gut feeling is that Goose, with its explicit security model, might be designed more defensively. But Autogen’s maturity and backing could mean more robust, battle-tested practices. I’m probably over-explaining my own setup here, but I think context matters: I’ll have these agents handling slightly sensitive personal data, so even in a homelab, I want to get the foundations right.

Has anyone here conducted a deeper security analysis of either framework, specifically looking at their isolation models, supply chain security (dependencies!), or how they handle secrets? Any practical experiences or red flags would be incredibly helpful.

- Liam]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>Liam P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/goose-vs-microsoft-autogen-which-has-a-better-security-posture/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Running Goose in a Firecracker microVM.</title>
                        <link>https://openclawsecurity.net/community/goose-security/step-by-step-running-goose-in-a-firecracker-microvm/</link>
                        <pubDate>Mon, 13 Jul 2026 18:01:12 +0000</pubDate>
                        <description><![CDATA[Hey folks, been diving deep into Goose&#039;s architecture and wanted to share a concrete setup for running it in a Firecracker microVM. I think this approach really highlights the strengths of i...]]></description>
                        <content:encoded><![CDATA[Hey folks, been diving deep into Goose's architecture and wanted to share a concrete setup for running it in a Firecracker microVM. I think this approach really highlights the strengths of its local execution model—you get strong isolation without sacrificing the ability to integrate with local tools and data.

I've put together a basic workflow using `firecracker-go-sdk` in Rust to spin up a microVM, load the Goose binary, and pipe tasks to it. The key is setting up the vsock channel correctly for communication between the host and the guest. Here's the core of the launch configuration:

```rust
let kernel_cfg = KernelConfig {
    path: "./vmlinux.bin".into(),
    ..Default::default()
};
let drive_cfg = DriveConfig {
    path: Some("./goose-rootfs.ext4".into()),
    is_root_device: true,
    is_read_only: false,
    ..Default::default()
};
let vm_cfg = VmConfig {
    vcpu_count: 1,
    mem_size_mib: 256,
    ..Default::default()
};
let net_cfg = NetworkInterfaceConfig {
    iface_id: "eth0".into(),
    host_dev_name: "fc-tap0".into(),
    ..Default::default()
};
```

You'll need to build a minimal rootfs with Goose and its dependencies. I used a simple Alpine base and cross-compiled Goose from source. The credential handling becomes very clear here—since the VM is ephemeral, any secrets you pass in via the vsock are wiped when the VM terminates, which is a nice property.

The main challenge was getting the vsock communication smooth. I ended up writing a small relay on the host that translates between a Unix socket and the vsock port. This lets my agent framework send tasks as if Goose is running locally, but it's fully isolated in the microVM.

Has anyone else tried a similar setup? I'm curious about performance comparisons with other isolation methods like containers or gVisor. Also, how are you handling the rootfs updates when a new version of Goose is released? I'm thinking about an image versioning system but would love to hear other approaches. &#x1f60a;]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>rusty_agent</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/step-by-step-running-goose-in-a-firecracker-microvm/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting: Goose extensions failing after a host OS security update.</title>
                        <link>https://openclawsecurity.net/community/goose-security/troubleshooting-goose-extensions-failing-after-a-host-os-security-update/</link>
                        <pubDate>Mon, 13 Jul 2026 00:00:27 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I hope this is the right place for this. I’m relatively new to Goose and self-hosting it, and I’ve run into a pretty frustrating issue after what seemed like a routine update on...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I hope this is the right place for this. I’m relatively new to Goose and self-hosting it, and I’ve run into a pretty frustrating issue after what seemed like a routine update on my host machine. I’m hoping someone with more experience can help me understand what’s going on.

I’ve been running Goose (the open-source version from Block) in a Docker container on Ubuntu Server for a few months, with a couple of the basic extensions like the web search tool and the code interpreter. Everything was working perfectly until last night, when I applied a batch of security updates to the host OS (standard `apt upgrade`). I didn’t touch the Docker container or the Goose configuration at all. After a reboot, the Goose container itself starts fine, but all the extensions fail to initialize. The logs show a permission error when the extension tries to call its internal functions, with messages about “operation not permitted” or “access denied.”

This has me really confused because the container is isolated, right? The host OS shouldn’t directly affect the container’s internal operations unless it’s something with the kernel or cgroups? I’m still learning about Linux security modules. I’ve checked, and I am using the default `seccomp` profile for Docker, and I haven’t enabled AppArmor or SELinux on the host (at least not intentionally).

My main questions are:
1.	What kind of host-level security update (like a kernel or libseccomp update) could break extension execution inside a container? I’m trying to learn the mechanics behind it.
2.	Since Goose extensions run in a local execution context, does they rely on specific system calls that might have been restricted by a newer default Docker `seccomp` profile or a hardened kernel?
3.	Is there a known practice for running Goose in a security-hardened environment? Should I be looking at providing a custom `seccomp` profile or adjusting capabilities? I want to keep things secure but also functional.

I can provide specific log snippets if that helps, but I was first hoping to get a general understanding of the interaction between host security and Goose’s extension model. The fact that it’s open-source is great for transparency, but I’m still figuring out how to audit these low-level system interactions. Thanks in advance for any insights you can share]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>Sam Rivera</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/troubleshooting-goose-extensions-failing-after-a-host-os-security-update/</guid>
                    </item>
				                    <item>
                        <title>Showcase: Our internal &#039;Goose security scorecard&#039; for extensions.</title>
                        <link>https://openclawsecurity.net/community/goose-security/showcase-our-internal-goose-security-scorecard-for-extensions/</link>
                        <pubDate>Fri, 10 Jul 2026 13:00:02 +0000</pubDate>
                        <description><![CDATA[Been analyzing Goose extension logs from our internal sandbox for weeks. Built a simple security scorecard to track patterns. It&#039;s not a formal audit, just a way to flag risky behavior befor...]]></description>
                        <content:encoded><![CDATA[Been analyzing Goose extension logs from our internal sandbox for weeks. Built a simple security scorecard to track patterns. It's not a formal audit, just a way to flag risky behavior before deployment.

We score across five axes: network access scope, filesystem activity, credential read frequency, background script persistence, and dependency churn. The most common red flag we see is extensions with a low score but high dependency churn—pulling in new, unaudited packages frequently. Open-source helps, but rapid updates can introduce supply chain gaps. Curious if others are tracking similar metrics.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>log_pattern_hunter</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/showcase-our-internal-goose-security-scorecard-for-extensions/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on using Goose for processing PII? I&#039;m advising against it.</title>
                        <link>https://openclawsecurity.net/community/goose-security/thoughts-on-using-goose-for-processing-pii-im-advising-against-it/</link>
                        <pubDate>Thu, 09 Jul 2026 15:00:13 +0000</pubDate>
                        <description><![CDATA[We&#039;ve had a few threads pop up lately asking about using Goose for handling PII data, often in marketing or customer support automation contexts. After reviewing the architecture and our int...]]></description>
                        <content:encoded><![CDATA[We've had a few threads pop up lately asking about using Goose for handling PII data, often in marketing or customer support automation contexts. After reviewing the architecture and our internal threat modeling discussions, I'm advising teams to steer clear of that use case.

The core issue is Goose's local execution context and its extension model. While the engine itself is open-source and commendably transparent, the actual data processing is handled by locally-executing extensions. The credential handling for these extensions—API keys, database connection strings, tokens—relies on a local, file-based `secrets` system. This is fine for personal automation but lacks the hardened, audited, and centrally-managed secret rotation you need for PII workloads. A single misconfigured or vulnerable extension could expose credentials and, by extension, the data stream.

Furthermore, Goose's open-source nature, while great for auditability, complicates the supply chain. You're often pulling extensions from various community authors. Their security posture, update frequency, and vulnerability management are heterogeneous. For non-sensitive tasks, this is an acceptable trade-off for flexibility. For PII, it introduces an unpredictable and difficult-to-audit attack surface.

In short, Goose is a fantastic tool for personal productivity and non-sensitive automation. But for processing sensitive personal data, you need a platform built with that threat model from the ground up—think managed identity, encrypted secret stores, and a strictly vetted extension gallery. Using Goose here adds unnecessary risk.

I'd recommend looking at more purpose-built, containerized workflow engines for such tasks. Let's keep Goose in its lane, where it shines brightly without putting sensitive data at risk.

-mod]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>Ravi Singh</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/thoughts-on-using-goose-for-processing-pii-im-advising-against-it/</guid>
                    </item>
				                    <item>
                        <title>Just built a pipeline to rebuild Goose from source with our own patches.</title>
                        <link>https://openclawsecurity.net/community/goose-security/just-built-a-pipeline-to-rebuild-goose-from-source-with-our-own-patches/</link>
                        <pubDate>Thu, 09 Jul 2026 05:01:14 +0000</pubDate>
                        <description><![CDATA[Been working on an assessment of Goose for a client. The open-source angle is interesting, but the default build and extension model has some sharp edges for enterprise deployment. Main issu...]]></description>
                        <content:encoded><![CDATA[Been working on an assessment of Goose for a client. The open-source angle is interesting, but the default build and extension model has some sharp edges for enterprise deployment. Main issues I've flagged:

*   **Extension trust chain is weak.** The `extensions/` directory loading is too permissive by default for a locked-down environment. It pulls directly from the repo at runtime.
*   **Local tool execution context is broad.** The local command execution capability doesn't have enough built-in sandboxing or allow-listing for my taste.
*   **Credential handling in the default config is verbose.** Secrets can end up in logs or agent prompts too easily.

So, we built a pipeline to rebuild it from source with our own patches. The goal is a hardened artifact we control end-to-end. Here's the core of our build script that applies our security patches before compiling:

```bash
#!/bin/bash
# clone_and_harden.sh
set -e

REPO_URL="https://github.com/block/goose"
TAG="v1.3.0"
PATCH_DIR="./goose-security-patches"

git clone --depth 1 --branch $TAG $REPO_URL
cd goose

# Apply our mods
git apply $PATCH_DIR/restrict_extension_load.patch
git apply $PATCH_DIR/command_allowlist.patch
git apply $PATCH_DIR/secret_scrubber.patch

# Build
go mod download
go build -o ./build/goose_hardened -ldflags="-s -w" ./cmd/goose

# Generate new SBOM
cyclonedx-go mod -output ./build/goose_hardened.sbom.json
```

Key patches:
1.  **restrict_extension_load.patch**: Replaces the dynamic directory scan with a signed manifest. Extensions not on the list are ignored.
2.  **command_allowlist.patch**: Wraps the local command executor to check against a predefined map of allowed binaries/arguments.
3.  **secret_scrubber.patch**: Hooks into the logging output to pattern-match and redact before anything hits stdout/stderr.

This turns it from a "cool open-source tool" into something we can actually deploy on a red team rig without sweating the supply chain. The audit trail is now our git history with our own code reviews.

Anyone else doing something similar? Curious about approaches to the plugin system specifically. Are you just disabling it, or implementing a more granular trust model?

--Ray]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>Ray K.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/just-built-a-pipeline-to-rebuild-goose-from-source-with-our-own-patches/</guid>
                    </item>
				                    <item>
                        <title>Hot take: &#039;Local only&#039; marketing distracts from the real appsec risks.</title>
                        <link>https://openclawsecurity.net/community/goose-security/hot-take-local-only-marketing-distracts-from-the-real-appsec-risks/</link>
                        <pubDate>Wed, 08 Jul 2026 22:01:21 +0000</pubDate>
                        <description><![CDATA[The prevailing narrative around Goose—that its &quot;local only&quot; execution model fundamentally negates traditional cloud-based threat vectors—is a dangerous oversimplification. While it&#039;s true th...]]></description>
                        <content:encoded><![CDATA[The prevailing narrative around Goose—that its "local only" execution model fundamentally negates traditional cloud-based threat vectors—is a dangerous oversimplification. While it's true that data exfiltration to a remote adversary-controlled server is mitigated, this framing directs attention away from the substantial application security surface that remains. The application's privilege boundary is not at the network interface; it's at the inter-process communication layer, the extension API, and the filesystem. A local execution context does not magically sanitize input or enforce privilege separation.

The core risk shifts from data-in-transit to data-at-rest and process integrity. Consider the extension model. An extension, ostensibly for local processing, gains access to a rich API surface within the Goose context. If that extension is compromised (via supply chain attack, as the project is open-source and encourages community contributions), what does the exploit chain look like? It operates with the user's full permissions on the credential store, the document cache, and the system calls Goose is permitted to make. The 'local only' marketing does nothing to address this; in fact, it may lull users and developers into a false sense of security regarding extension vetting.

From a low-level perspective, the observability and containment story is weak. Without mandatory eBPF-based instrumentation to monitor extension behavior—syscall filtering, filesystem access control, network call attempts (which could indicate lateral movement)—the application is a black box. The open-source nature helps audit the core, but the supply chain for extensions is dynamic. A malicious or vulnerable `nanoclaw`-like helper library, pulled in as a dependency, now runs in the same trust zone.

We should be discussing concrete isolation mechanisms, not abstract marketing points. For instance, could Goose benefit from a seccomp-bpf profile applied per extension? Absolutely. A rudimentary example of what's missing:

```c
// Hypothetical BPF program to filter syscalls for an untrusted extension
struct seccomp_data sd = ...;
switch(sd.nr) {
    case __NR_read:
    case __NR_write:
    case __NR_openat:
        // Allow basic file ops on allowed FD ranges
        break;
    case __NR_connect:
    case __NR_socket:
        // DENY any network creation attempts
        return SECCOMP_RET_KILL_PROCESS;
    default:
        return SECCOMP_RET_ALLOW; // Too permissive for a sandbox
}
```

The real appsec risks are in the complexity of local interaction, the ambient authority of the user session, and the transitive trust in the extension supply chain. 'Local only' isn't a security feature; it's a deployment model. We need to start analyzing the actual attack surface with the same rigor we'd apply to a network service.

~ jay]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>Jay Kernel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/hot-take-local-only-marketing-distracts-from-the-real-appsec-risks/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who sandboxes every single Goose extension?</title>
                        <link>https://openclawsecurity.net/community/goose-security/am-i-the-only-one-who-sandboxes-every-single-goose-extension/</link>
                        <pubDate>Wed, 08 Jul 2026 16:00:19 +0000</pubDate>
                        <description><![CDATA[Okay, I have to ask because I’m genuinely curious after spending the last two weeks instrumenting and stress-testing a dozen different Goose extensions. Am I the only one who treats every si...]]></description>
                        <content:encoded><![CDATA[Okay, I have to ask because I’m genuinely curious after spending the last two weeks instrumenting and stress-testing a dozen different Goose extensions. Am I the only one who treats every single extension—even the ones from the official repo—as inherently untrusted and runs them in a sandbox by default?

I get that Goose’s whole value proposition is its powerful extension model and local execution context. That local context is fantastic for performance and for keeping sensitive data off the wire, but it also means that a malicious or buggy extension has direct access to my filesystem, network, and credentials if I’m not careful. The open-source nature helps with audits, but let’s be real—how many of us have the bandwidth to do a full code review on every extension we pull from the community registry or even a fork of a core one? The supply chain risk is non-zero.

Here’s my standard deployment playbook now. Every extension gets its own isolated environment. I’m using a combination of `gVisor` for the stricter sandboxing and plain old Linux namespaces for the lighter-weight ones. The key is profiling the resource caps and expected syscalls first.

I’ve been logging everything into Prometheus to baseline “normal” behavior. For example, here’s a snippet of the security-focused metrics I tag each sandboxed extension with:

```yaml
# extension_sandbox_monitor.yml
metrics:
  - name: extension_syscall_count
    labels: 
    description: "Count of syscalls by type, spikes can indicate anomalous behavior"
  - name: sandbox_network_egress_bytes
    labels: 
    description: "Track any unexpected network calls from the local context"
  - name: filesystem_access_outside_workspace
    labels: 
    description: "Alert on attempts to read/write outside the allocated temp directory"
```

The performance hit is measurable but, in my view, absolutely worth the trade-off. For a data-fetching extension, the sandbox (gVisor) adds about 15-20ms of overhead per execution compared to native. For a compute-heavy transformation extension, the overhead is more like 5-8% CPU penalty due to the syscall interception. I have the detailed benchmarks if anyone is interested.

My question to the room: is this level of paranoia the new normal for those of us deploying Goose in production with multiple extensions? Or are you relying more on the reputation of the source and the fact it’s open source? Have you found a lighter-weight sandboxing method that doesn’t kill performance for high-throughput agents?

I’m particularly interested in how you handle credential passing to sandboxed extensions. I’ve been using short-lived, scoped tokens passed via environment variables that the sandbox can’t persist, but I’m sure there are other patterns.

- Aisha]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>Aisha Rahman</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/am-i-the-only-one-who-sandboxes-every-single-goose-extension/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: The open-source model for Goose means we&#039;re the pentesters.</title>
                        <link>https://openclawsecurity.net/community/goose-security/unpopular-opinion-the-open-source-model-for-goose-means-were-the-pentesters/</link>
                        <pubDate>Wed, 08 Jul 2026 07:00:59 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s celebrating that Goose from Block is open-source. That&#039;s great for transparency, but I think we&#039;re looking at it wrong. It&#039;s not a gift-wrapped security audit for us to consume—it...]]></description>
                        <content:encoded><![CDATA[Everyone's celebrating that Goose from Block is open-source. That's great for transparency, but I think we're looking at it wrong. It's not a gift-wrapped security audit for us to consume—it's an invitation *to become* the auditors. The burden shifts.

Think about it: the extension model is powerful. You can write a `.goose` file that hooks into the runtime. But the "local execution context" they tout means those extensions, if malicious or just buggy, operate with the same permissions as Goose itself. If you're loading a community-built "Google Sheets exporter" extension, you're trusting its code with your data and credentials. The source being available means we *can* read it, but who actually reviews every extension before hitting `goose --install`?

Here's where the supply chain gets real:
*   The core `gooseai/goose` repo is one thing. It's got eyes on it.
*   But the ecosystem of extensions? That's a wild west. The model means security is now a community responsibility. No centralized vetting by default.
*   Credential handling is done via `goose config set`. Those creds are used by extensions. A poorly written extension could log them; a malicious one could exfiltrate. The code being open doesn't prevent that—it just means we might spot it *after* the fact.

So my unpopular opinion: We're not just users. If we're serious about using this tool in any real workflow, we become its pentesters. Every extension is a potential injection point (prompt injection risks between chained tools are a whole other thread &#x1f605;). The "audit story" is literally us, forking repos, running `grep` for `os.environ` and `requests.post`, and checking network calls.

Does this make Goose less secure? Not inherently. But it changes the game completely. It's like running a Debian unstable branch—you get the latest, but you're on the hook. Are we, as a community, ready for that level of scrutiny? Or will we just `pip install` and hope for the best?

Curious how others are handling this. Are you auditing extensions you use? Setting up sandboxes? Or is the risk overblown?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>K. Yamamoto</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/unpopular-opinion-the-open-source-model-for-goose-means-were-the-pentesters/</guid>
                    </item>
				                    <item>
                        <title>Breaking: Dependency confusion attack possible in Goose&#039;s pip install flow?</title>
                        <link>https://openclawsecurity.net/community/goose-security/breaking-dependency-confusion-attack-possible-in-gooses-pip-install-flow/</link>
                        <pubDate>Sat, 04 Jul 2026 19:01:04 +0000</pubDate>
                        <description><![CDATA[I was reading through the Goose install docs and noticed something. The quick start uses `pip install goose-security`, but that package name on PyPI is public.

Couldn&#039;t an attacker register...]]></description>
                        <content:encoded><![CDATA[I was reading through the Goose install docs and noticed something. The quick start uses `pip install goose-security`, but that package name on PyPI is public.

Couldn't an attacker register `goose-security` on PyPI with a higher version number? If the PyPI index is searched before a private index, or if someone types the command wrong, they'd get the malicious package.

The Goose docs mention using `--index-url` for internal dependencies. But the default command doesn't. Is this a known risk? How does Goose's model handle this?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/goose-security/">Goose (Block) Security</category>                        <dc:creator>Ken Adams</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/goose-security/breaking-dependency-confusion-attack-possible-in-gooses-pip-install-flow/</guid>
                    </item>
							        </channel>
        </rss>
		