Frequently Asked Questions

Yes , you can disclose vulnerabilities publicly.

Please use these guidelines when preparing a public write-up of a vulnerability you discovered and disclosed to our organization.

Disclosure Timing

• Do not publish any details of the vulnerability until we have confirmed remediation or granted explicit written permission.
• If you wish to publish after remediation but before receiving explicit permission, please coordinate with us to agree on a safe publication date.

Redaction of Sensitive Information

• Do not include:
  • Proprietary or user data
  • Internal system identifiers (e.g., production IPs, hostnames)
  • Authentication credentials, session tokens, or cookies
• Anonymize or mask any details that could allow reproduction on live systems.
  • Example: * Replace real IP addresses with placeholders like `10.0.0.1`, and mask usernames or tokens with `[REDACTED]`.
• Ensure PoCs and screenshots do not contain any personally identifiable information (PII) or sensitive data, even if redacted.

Write-Up Structure

We recommend the following structure for your write-up. Use clear formatting (such as Markdown or plain text) for readability.

Title: [Vulnerability Title] Author: [Your Name or Alias] Date Reported: [YYYY-MM-DD] Date Resolved: [YYYY-MM-DD] Scope: [General description of the asset or system affected] Vulnerability Type: [e.g., Cross-Site Scripting (XSS)]

Summary:

A brief description of the vulnerability and its impact.

Steps to Reproduce:

Safe, redacted, and non-destructive steps to demonstrate the issue. Avoid including any steps that could disrupt production systems.

Impact:

Describe what a malicious actor could achieve if the vulnerability were exploited.

Root Cause:

A high-level explanation of the underlying flaw (e.g., improper input validation).

Remediation:

Describe the fix implemented or recommended (e.g., code patch, configuration change) and/or best practices.

Timeline: Report submitted: [Date] Acknowledged: [Date] Resolved: [Date] Permission to publish: [Date]

References:

List any relevant external resources, advisories, CVEs, or CWEs.

Acknowledgments: University of Nebraska.

Proof of Concept (PoC) Restrictions

• Only include redacted or simulated payloads.
• Do not include scripts, URLs, or code that target our live systems.
• Do not submit executable files, malware samples, or any content that could be weaponized.
• Ensure PoCs do not contain any PII or sensitive data.

Coordination and Review 

• Submit a draft of your write-up to us prior to publication.
• We may request adjustments to remove sensitive or proprietary information.
• Please allow up to 10 business days for our review and feedback before publishing. 

Legal and Ethical Compliance 

• Ensure your write-up only reflects testing performed within the authorized scope and in accordance with the VDP rules of engagement.
• Do not describe or reference any unauthorized access or disruptive actions. 

By following these guidelines, you help us maintain a secure, transparent, and collaborative security community. We appreciate your professionalism and contributions. 
For questions or to submit your write-up draft, please refer to the contact information provided in the main VDP documentation. 

Yes. On University-managed systems, a report may be in scope if it demonstrates failure to enforce a mandatory authentication requirement defined by University policy or standard, such as accepting passwords below the required minimum length.

For this type of report, the reporter should show the control failure on the affected asset, for example:

• the exact registration, login, or password-change endpoint
• the weak password accepted
• the observed result

Reporters do not need to perform brute-force, password spraying, credential stuffing, or account takeover to show this issue. Those testing methods remain out of scope.

General security recommendations that do not demonstrate violation of a mandatory University requirement remain out of scope.