In a previous Japanese post, I wrote about why I built Carapace: a local-first security CLI for people outside the small circle of organizations that get early access to the strongest defensive tooling.

That post was about design philosophy.

This one is about whether the tool can actually behave according to that philosophy when pointed at real code.

It is easy to say that a security tool should avoid false positives. It is harder to keep that discipline when the tool finds something that looks suspicious, especially when it would be tempting to say, “We found a vulnerability.”

Recently, I ran Carapace against a small, independently maintained RSS-related open source project. The result was not a dramatic “critical vulnerability found” story.

It was more useful than that.

Carapace found a technically plausible SSRF-shaped path, then stopped short of calling it exploitable because the attacker reachability was not proven. I reported it privately as a hardening suggestion, not as a confirmed vulnerability.

That distinction is the point of this article.

I will not name the project, the author, the advisory, or any specific code locations. The issue has been reported privately, and the details should stay private. What I want to show here is the inspection process: how Carapace triaged the code, how it checked reachability, and why it chose a cautious conclusion.

## What I Scanned

The target was a small RSS-related open source tool maintained by an individual developer.

RSS tooling is an interesting security target because it often handles externally influenced URLs. A system may read a subscription list, store feed URLs, fetch content server-side, parse the response, and expose the saved content througer another interface.

That pattern can become security-sensitive.

One class of issue that often appears around server-side URL fetching is SSRF: server-side request forgery. In simple terms, SSRF happens when an attacker can cause a server to make requests to destinations the attacker should not be able to reach directly.

But server-side fetching is not automatically SSRF.

The important questions are:

• Can an attacker control the URL?
• Can the server reach internal or sensitive destinations?
• Are URL schemes restricted?
• Are private, loopback, link-local, and metadata addresses blocked?
• Are redirect destinations revalidated?
• Are timeout and response-size limits enforced?

Without those questions, it is too easy to turn “this shape looks risky” into “this is a vulnerability.”

Carapace is designed not to do that.

## First Pass: Triage

Carapace does not start by sending an entire repository to the most expensive model.

For this scan, I narrowed the target to the relevant slice: RSS ingestion, external URL handling, local configuration, persistence, and the externally callable interface around saved content. The goal was not to inspect everything. The goal was to inspect the trust boundary.

Then Carapace ran a cheap triage pass.

The result was one medium-confidence candidate and several low-confidence candidates.

That split matters.

The low candidates included things like missing explicit validation or possible resource-exhaustion concerns. They were worth recording, but they were not strong enough to bother a maintainer with immediately. They depended on configuration, library defaults, or runtime assumptions.

The medium candidate was more interesting.

At a high level, it looked like this:

An externally derived URL could be saved, and that saved URL could later be fetched by the server.

If an attacker could control that URL, the path could become SSRF-relevant.

At this point, it would have been easy to say: “Carapace found an SSRF.”

But that would have been premature.

## Risky Shape Is Not the Same as Exploitability

A core rule in Carapace is that a dangerous-looking branch is not enough. The tool has to ask whether an attacker can actually reach that branch.

So the candidate went into deep-dive.

The deep-dive checked the technical path first.

It found that the server-side fetch path did not visibly enforce the defenses I would expect around untrusted URLs. From the reviewed slice, there was no clear scheme restriction, no visible blocking of private or loopback destinations, no redirect destination revalidation, and no explicit timeout or response-size limits.

That is a real technical concern.

But one question remained:

Can an attacker actually set the URL?

That is where the conclusion changed.

From the code reviewed, the source of those URLs appeared to be a locally configured file controlled by the operator. I did not find a public API or external input path that allowed an arbitrary user to add or modify the URL that would later be fetched by the server.

So the result was not “confirmed SSRF.”

The result was:

plausible, but needs validation.

In practical terms:

• Severity: low
• Confidence: medium
• Reportability: worth sharing privately as hardening guidance, not as a confirmed remote exploit

That middle ground is exactly what I wanted Carapace to be able to produce.

## The Value of Not Saying “We Found a Vulnerability”

In security, “we found a vulnerability” is a strong phrase.

Strong phrases get attention. They also create work for the person receiving them.

For an open source maintainer, a low-confidence report still has a cost. They have to read it, understand it, reproduce or disprove it, decide whether it matters, and possibly communicate back.

That cost is real.

So Carapace should not maximize the number of findings. It should maximize the number of findings that are worth a human’s time.

In this case, I did not treat the result as a confirmed vulnerability.

The careful statement was:

There is a server-side URL-fetching path that would be risky if the URL became attacker-controlled. The reviewed code does not show the expected URL-fetch hardening. However, the current code does not show a confirmed external path for an attacker to set that URL.

That is less exciting than “SSRF found.”

It is also more honest.

And in practice, that kind of conclusion is often valuable. It says:

This does not appear to be burning right now. But this is where it could burn later.

That is a different kind of security value. It is not a trophy. It is maintenance guidance.

## Responsible Disclosure as Hardening, Not Alarm

I sent the result privately to the maintainer.

The tone was deliberate.

I did not write it as “I found a vulnerability.” I wrote it as a low-to-medium confidence hardening suggestion.

The report made three things clear:

First, the server-side URL-fetching shape is technically relevant.

Second, I could not confirm that a remote attacker can currently control the URL.

Third, if a future feature allows user-controlled subscriptions, imports, or URL registration, this path could become much more serious.

The suggested hardening was general and defensive:

• restrict allowed URL schemes
• reject private, loopback, link-local, and metadata address ranges
• revalidate redirect destinations
• add timeouts and maximum response-size limits

These are standard defenses for systems that fetch external URLs server-side.

The point was not to accuse. It was to help the project avoid a sharper version of the issue later.

That is the posture I want Carapace to have: do not exaggerate, but do not stay silent when there is a useful preventive
fix to suggest.

## A Small but Useful Field Test

There is no dramatic ending here.

Carapace did not produce a headline-grabbing critical vulnerability.

Instead, it did something quieter:

That is the behavior I wanted to see.

A security tool is not valuable only when it finds severe bugs. It is also valuable when it refuses to overclaim.

That is the kind of tool I want Carapace to become.

Carapace is still small. It is still early. But this scan showed that its core habit can hold up against real open source code: find suspicious paths, validate reachability, and report only what can be said honestly.