如何撰寫維護者可驗證的安全報告

A scanner says it found a vulnerability. The report sounds confident, names a dangerous function, and recommends a patch. But can another person reproduce the failure from a clean checkout, with the exact inputs and configuration you used?

That question is becoming more important as automated and AI-assisted analysis increases the number of potential findings sent to open-source maintainers. OpenSSL received an average of 71 security reports and inquiries per month between May and July 2026, compared with nine in the same period a year earlier. The number reached 108 in August. Of roughly 500 reports over the past year, 63 resulted in disclosed vulnerabilities. Many others were duplicates, ordinary bugs, or issues that did not warrant a security advisory, but still needed human review.[1]

The useful lesson is not “AI reports are bad.” OpenSSL says AI tools are finding issues in obscure parts of its code, and the project uses AI internally to review code, investigate reports, and write tests. The problem is that a plausible finding is not the same thing as a validated security issue. Human investigation and approval remain necessary.[1]

This article gives you a practical, local-only workflow for turning a scanner or model output into a report another engineer can evaluate. It does not probe a live service, exploit a third-party system, or decide whether a finding deserves a CVE. It helps you answer a narrower question: can you provide enough evidence for maintainers to reproduce and assess the claim?

The report is a proof, not a verdict

A vulnerability report should let a maintainer independently test a specific claim. “This function looks unsafe” is a lead, not a proof. “With version X, configuration Y, and this input, an unauthenticated remote peer can cause process termination” is a testable claim, provided the steps and evidence really demonstrate it.

Keep these concepts separate:

• Observation: What happened when you ran the test? For example, a process exited with a segmentation fault.
• Reachability: Can an attacker-controlled input actually reach the code path in a supported configuration?
• Impact: What can an attacker make the affected application do? A crash, information disclosure, or code execution are not interchangeable outcomes.
• Security conclusion: Does the evidence meet the project’s security policy? The maintainer, not the model that suggested the issue, makes that determination.

This distinction matters because a crash in a local unit test does not by itself prove a remotely exploitable denial of service. An unsafe-looking line does not prove that attacker-controlled data reaches it. A patch generated by an AI tool does not prove that the patch is correct or complete.

Step 1: Freeze the claim before investigating

Write a one-sentence hypothesis before asking an AI assistant to expand it or editing code. Keep it narrow enough that a test could disprove it.

For example:

When a parser receives an input with condition X, function Y dereferences a missing field and the test process terminates.

That is deliberately more useful than “the parser has a critical memory-safety vulnerability.” It identifies a trigger and an observable outcome without exaggerating impact or severity.

Record the exact repository, commit, build options, operating system, compiler, and dependency versions. If you cannot identify the version, say so. A finding against an old branch may already be fixed, may not affect supported releases, or may rely on behavior that no longer exists.

Do not copy secrets, customer data, private source code, or sensitive production logs into a public AI service while investigating. Use a local or approved environment, and minimize the material you share. A security report should not create a second incident through accidental disclosure.

Step 2: Make the smallest safe reproducer

Start with the smallest input and setup that demonstrates the behavior. Prefer a unit test or isolated local program. Do not test against a system you do not own or have explicit permission to assess.

A useful reproducer should state:

1. The exact version or commit tested.
2. The exact build and configuration commands.
3. The complete input, or a clear way to generate it.
4. The command that runs the test.
5. The expected result and the actual result.
6. Whether the issue reproduces on a clean checkout.

Keep the reproducer deterministic. Remove unrelated services, network dependencies, credentials, and environment assumptions where possible. If the failure depends on a compiler flag, feature toggle, or non-default configuration, show that requirement explicitly rather than implying every installation is affected.

For memory-safety claims, use the project’s documented sanitizers or debugging tools where appropriate. A sanitizer trace can help localize a fault, but it still does not establish the attacker’s ability to reach the code or the real-world impact. Preserve the full output and include only the relevant excerpt in the report.

Step 3: Check whether the behavior is already known

Before submitting, search the project’s security advisories, issue tracker, release notes, and recent commits. Search using the affected function, error signature, input type, and likely root cause. A duplicate still costs maintainers time, even if the duplicate reporter acted in good faith.

OpenSSL’s public discussion about mass AI-generated issue submissions describes the specific concern: a burst of reports can make carefully reproduced reports harder to see. One participant proposed limiting a reporter to a small prioritized sample, and another pointed to an existing policy asking contributors planning many pull requests to start with a representative set and explain their process.[2] That is a useful general principle: prioritize and validate findings before sending a batch.

Do not assume a public issue tracker is the right place for a security report. Follow the project’s current private disclosure instructions. OpenSSL’s vulnerability page directs suspected security bugs to its reporting process.[3] Other projects may have a security policy file, an email address, or a hosted disclosure platform. Use the current official route, not an address copied from an old blog post.

Step 4: Use AI as a skeptical reviewer, not an authority

If an AI tool helped find the issue, ask it to challenge the claim rather than merely rewrite it persuasively. Give it the hypothesis and the minimal reproducer, then ask questions such as:

• Which exact input is attacker-controlled, and where is that assumption visible in the code?
• What evidence shows the suspected function is reachable in this configuration?
• What benign explanation could produce the same output?
• Which setup detail would make this result fail to reproduce?
• Does the test prove the stated impact, or only a lower-level symptom?
• What additional test would falsify the hypothesis?

Treat every answer as a suggestion to verify against the source, build, and test output. Models can generate confident but nonexistent call paths, misunderstand a guard, or describe a crash as code execution without evidence. If the suggested analysis cannot be confirmed, remove it from the report.

A useful report can disclose that AI assisted with the investigation, but disclosure is not a substitute for validation. The important distinction is whether the submitter personally reviewed the evidence and can explain the reproduction. OpenSSL’s discussion itself calls for a reasonable level of review and validation from people submitting reports produced with AI tools.[2]

Step 5: Separate evidence from interpretation

Structure the report so a maintainer can inspect what you observed before reading your conclusion.

Evidence should include the minimal reproduction, exact environment, command output, and relevant source location. Quote only the lines needed to understand the trace. Redact secrets and personal data. If an artifact is too large, provide a small, safe reproducer rather than asking the maintainer to trust a screenshot or an opaque archive.

Interpretation should explain why the observed behavior matters, what an attacker can control, what preconditions exist, and what impact you believe follows. Mark uncertainty directly. “I have not confirmed remote reachability” is more helpful than quietly turning a local crash into a remote exploit claim.

Avoid assigning a CVSS score as if it were a project decision. You may offer a tentative severity rationale, but show the assumptions and let the project assess it. OpenSSL’s published advisories show why conditions matter: some issues apply only when specific flags are enabled, and the project’s explanations distinguish the trigger and impact rather than relying on a vulnerability label alone.[3]

A report template you can use

Copy this into a private draft and fill every applicable field. If you do not know something, write “unknown” instead of guessing.

## Summary
One sentence describing the observed security-relevant behavior.

## Affected project and version
- Repository:
- Release or commit:
- Supported version status, if known:

## Preconditions
- Attacker access required:
- Required configuration or feature flags:
- Is the configuration default? Yes / No / Unknown

## Reproduction environment
- Operating system:
- Compiler/runtime and version:
- Build options:
- Relevant dependencies:

## Reproduction steps
1. Start from this clean version or commit:
2. Run these build commands:
3. Provide or generate this exact input:
4. Run this test command:

## Expected result
What should happen according to the project’s behavior or specification?

## Actual result
What happened? Include a short log excerpt and attach the full relevant output securely.

## Security impact and limits
- What input can an attacker control?
- What impact did the test directly demonstrate?
- What impact is inferred but not yet demonstrated?
- What important preconditions or limits apply?

## Duplicate check
Links or search terms checked in advisories, issues, and release notes.

## AI assistance
Whether AI tools helped, and what you personally reproduced or verified.

## Disclosure
How the project can contact you, using its approved private channel.

This template is intentionally evidence-first. It discourages inflated claims and gives reviewers a fast path to the reproduction. It also makes uncertainty visible, which is better for everyone than filling gaps with plausible details.

Step 6: Submit one prioritized report, then respond

If an analysis tool produces dozens of candidate findings, do not submit them as a burst. Sort them by evidence quality, reachable attack surface, demonstrated impact, and confidence that they are not duplicates. Choose the strongest, most independently reproducible example first. OpenSSL’s maintainers have explicitly discussed the workload created by high-volume submissions and the possible value of asking reporters to prioritize.[2]

After submission, be ready to answer focused questions: Can you reproduce on another supported version? Does the issue require a non-default option? Can you reduce the test further? Does the same input produce the same result? If you cannot answer yet, say what you have not checked. Avoid posting exploit details publicly before the project’s disclosure process permits it.

And remember that maintainers need more than issue reports. OpenSSL is asking developers to help review code, not merely submit more contributions, while it works to increase its experienced reviewer capacity.[1] For open-source security, a careful reproduction, a useful review, or sustainable funding may be more valuable than another unverified scanner output.

The checklist

Before sending a security report, check each item:

• [ ] I identified the exact version or commit.
• [ ] I reproduced the behavior locally from a clean setup.
• [ ] I included the exact input, configuration, and commands.
• [ ] I separated the observed symptom from inferred security impact.
• [ ] I checked official advisories, issues, and release notes for duplicates.
• [ ] I used the project's current private reporting channel.
• [ ] I removed secrets, customer data, and unnecessary exploit detail.
• [ ] I reviewed any AI-generated explanation against source code and test output.
• [ ] I prioritized this report instead of submitting a batch of unchecked findings.

AI can make it cheaper to search code and generate hypotheses. The OpenSSL experience suggests that the scarce part is often the human work that follows: reproducing, prioritizing, understanding impact, fixing, and reviewing. A report that makes those steps easier is not just more polite. It is more likely to help a maintainer act on a real problem.

Have you submitted or reviewed a security report recently? What evidence made it easy, or difficult, to verify?

I write about software engineering, security, and AI. Subscribe to follow the next practical breakdown.

Sources

1. Axios: A major open-source encryption tool is getting buried in AI requests, October 20, 2026.
2. OpenSSL GitHub Discussion #32378: Should the project have a policy for mass filling of AI generated issues?, August 14, 2026.
3. OpenSSL vulnerabilities and reporting information.