Skip to content
FortressDiscuss your project

Advisory format

Reproducibility is part of the record.

Every published finding uses the same evidence-led structure so a researcher can understand the tested claim and repeat it safely.

Format reference · Not a vulnerability report

The prompts below describe the information each advisory contains. No vulnerability details or artifacts are published here.

Status
Template — unpublished
Severity
State the rating and the basis it rests on, such as the scoring system and version
Fix status
Specify separately from publication status
Product / advisory ID
Product and stable Fortress reference
Identifiers
CVE or vendor identifiers, if assigned
Published
Not published
Last updated
Record the date of each revision

Impact

State the demonstrated security boundary and business consequence. Distinguish observed impact from potential impact, and explain the limits of the assessment.

Remediation

Identify the vendor-supported update or mitigation, its scope and limitations, and how to verify remediation. If no fix is available, state that explicitly.

Affected / fixed versions

Version scope and basis of confirmation
AffectedFixedBasis
Exact release or bounded rangeFixed release, or explicitly unknownDistinguish direct testing from vendor confirmation

Tested environment

Platform
OS, architecture, runtime, and dependency versions.
Build
Exact product build, source revision, and configuration.
Isolation
Lab topology, synthetic data, and reset conditions.

Prerequisites & role

Required role
Minimum role, privileges, and account state.
Access
Required network or local access and authentication.
Configuration
Non-default settings, dependencies, and setup assumptions.
Constraints
Authorized test scope, side effects, and cleanup requirements.

Exact reproduction steps

  1. Establish the test state

    Document the exact lab setup, version, role, synthetic inputs, and baseline checks.

    Expected observation: Describe the starting state that confirms the environment is ready.

  2. Record the validation procedure

    Provide the reviewed, ordered procedure with literal inputs and explicit placeholders. Keep one action per step and record side effects.

    Expected observation: State the observable result for each step, including any relevant output or exit status.

  3. Compare and restore

    Repeat the same procedure against the fixed build, identify any changed assumptions, and document cleanup.

    Expected observation: Record the affected and fixed observations separately; identify inconclusive runs.

Affected vs fixed results

Affected build

Exact expected affected behavior and the corresponding observed evidence.

Fixed build

Exact expected fixed behavior and the corresponding observed evidence, or ‘not tested’ with a reason.

Document negative controls, repeatability, and limits. A single fixed-build observation does not establish the status of every release.

Evidence hashes

For each evidence item, record its filename, what it demonstrates, and the full 64-character SHA-256 digest of the reviewed bytes. Hashes identify evidence; they do not prove the conclusion. Private evidence does not receive a public download link.

Safe artifact links

Link only to separately reviewed, sanitized static exports. Each download identifies its type, byte size, purpose, and SHA-256 digest. If artifacts are withheld or unavailable, explain why.

Disclosure timeline

Use dated entries for initial report, vendor acknowledgement, fix availability, independent retest, coordinated publication, and later corrections. Mark unknown events explicitly; do not infer acknowledgement or agreement.

Credits

Name the researchers and contributors with their roles and agreed attribution. Separate discovery, validation, remediation, and coordination credit.

References

List the vendor bulletins, CVE records and other sources the advisory relies on, with the exact title and address of each. Do not present a source as agreement with a conclusion it does not state.