Audit output does not include the OSPS spec version it evaluated against

[mlieberman85]

Description

The output of audit_openssf_baseline (MCP tool) and darnit audit (CLI) does not include the spec_version of the OpenSSF Baseline the audit was evaluated against. A user reading an audit report cannot tell whether it was produced against OSPS v2025.10.10 or v2026.02.19 (or any future revision) without a separate darnit list call.

Why it matters

• Reports become ambiguous once the pinned spec version changes: two reports from different versions cannot be compared without out-of-band metadata.
• Any downstream consumer (a coding-agent skill, an attestation, a compliance dashboard) that wants to record what standard were we audited against? has to reach into the framework metadata separately.
• Discovered while running /darnit-audit against a repo after bumping spec_version from OSPS v2025.10.10 to OSPS v2026.02.19 in PR fix(baseline): correct per-level classification and bump OSPS spec to v2026.02.19 (#342) #349. The skill's own documentation referenced the old string; there was no way to spot-check from the audit output itself.

Suggested behavior

Every audit output format should include the framework metadata that the audit was run under:

• Framework name (e.g., openssf-baseline)
• Framework version (implementation version, e.g., 0.1.0)
• spec_version (the upstream standard version, e.g., OSPS v2026.02.19)
• Ideally a timestamp

Placement suggestions:

• markdown: a small header block at the top
• json: a top-level metadata object alongside controls
• sarif: populate runs[].tool.driver.version and runs[].tool.driver.semanticVersion
• text: a one-line prefix

Related

• Surfaced by verification of fix(baseline): correct per-level classification and bump OSPS spec to v2026.02.19 (#342) #349 (verdict correctness / v2026.02.19 bump).
• Related to the pattern in feedback_darnit_testing_framing memory: audit skills are the product; the audit output has to carry its own provenance.