curl: More security reports do not automatically make us safer

A security report is easy to write. Someone then has to check whether it is correct, which systems are affected and what needs to change. That distribution of work is what concerns me about the current curl debate: we can generate ever more findings. The capacity to assess them does not automatically grow alongside them.

Opinion by Julian Köhn, CTO and co-founder of Kopexa. Sources checked as of 23 October 2026.

What changes at curl on 26 October

On 20 October, Daniel Stenberg announced that reports rated LOW or MEDIUM would be handled publicly on GitHub from 26 October. HIGH and CRITICAL reports remain in the private HackerOne process. Anyone unsure of the severity can still report there; the project makes the classification.

The change responds to overloaded maintainers. Public handling is intended to bring more people into the work. It does not automatically reduce the work required per report. Stenberg also identifies the disadvantage: attackers can learn about unpatched problems earlier. Announcement of the new procedure

Hero image: the original heading and publication details from Daniel Stenberg’s blog, captured on 23 October 2026; the Kopexa logo identifies our editorial analysis.

To me, this is a decision made under capacity pressure. The team distributes work and accepts a specific risk in return. It does not support a general recommendation to publish internal security findings without first reviewing them.

AI involvement is not a reason to dismiss a report

In “ignore the slop”, published on 22 October, Stenberg explains why AI-assisted reports cannot simply be ignored: they can identify real vulnerabilities.

The same standard should apply regardless of origin. A persuasive explanation is not proof. Conversely, awkward wording does not invalidate a reproducible bug.

At minimum, a report needs the affected version and configuration, the expected and actual behaviour, and the possible impact. If information is missing, the finding remains open and receives a follow-up question. Missing details neither confirm it nor automatically invalidate it. I would apply this standard to every report: which verifiable claim does it contain? The minimum should be a small case that another person can understand and reproduce.

Does it affect our actual operation?

Severity is a starting point. The operational context determines the decision: which input can an attacker control? Is the code path used? What privileges does the component have, and which data can it reach?

Consider a fictional example: the same bug exists in an isolated test environment and in an internet-facing service that processes untrusted input. The version is identical. The urgency may differ.

A finding of “not affected” also needs a verified basis. “We probably do not use that” describes a knowledge gap. Assign someone to resolve it. A later change to the configuration, input or use case can require reassessment.

Reduce an overloaded ticket to the information needed for a decision

Take an open finding from your own records. Work with the responsible developer or administrator to add these five details:

• Finding: What has been demonstrated, and what remains a suspicion?
• Affected system: Which running component and configuration are involved?
• Decision: Update, isolate, investigate further or postpone with a documented reason?
• Ownership: Who takes the next step, and by when?
• Review: Which date or new information triggers another assessment?

Keep the summary short enough for someone else to review. Long scanner attachments cannot replace the reasoning behind a decision.

Long scanner reports can remain as attachments. Their length should not obscure who needs to do what next. A risk acceptance needs an owner and a limit. For example, the assumption “this service is internal” needs another check before someone makes it reachable through a new access path.

Better security is not a count of closed tickets

I would rather ask how long confirmed, relevant findings remain unresolved, which assumptions have never been tested, and which findings have no owner.

Prioritisation must not become permanent storage for inconvenient issues. Exceptions need review, and an actual update needs a plan and verifiable evidence.

In Kopexa, you can connect risks with measures, owners and evidence. Evidence stays with the relevant measure. This does not replace technical assessment; it helps turn the resulting work into clear responsibilities.

The review question: Which finding can we decide on using the facts available, and which specific information is still missing?