When no fix exists, publish an affected status paired with an action statement: what customers can do today, such as a workaround or configuration change, and when you will update them next. Be specific about affected versions, and careful about exploit detail until a fix is out.
Why say anything early
Customers cannot protect themselves from a risk they do not know about. A short honest notice with a mitigation often reduces exposure more than a polished advisory a week later. Both OpenVEX and CSAF anticipate this case.
What the formats require
The OpenVEX specification says an affected statement must include an action statement, and that status values include affected and under investigation. The CSAF VEX profile says that for each product listed as known affected, additional product specific information must be given in remediations as an action statement. So a bare "affected" with no guidance is not just unhelpful, it is an incomplete document under both.
What to include
| Element | Example of useful content |
|---|---|
| Status | Affected, with the date the status was known |
| Versions | Exact versions or range, and any known unaffected versions |
| Action statement | The workaround, with steps and side effects |
| Detection | How to tell if the issue is being used against a deployment, if known |
| Next update | A date and time for the next message |
| Contact | Where to ask questions |
What to hold back
The EU Cyber Resilience Act, in Annex I Part II, allows a manufacturer in duly justified cases to delay publishing information about a fixed vulnerability until users have had the chance to apply the patch. That text is about fixed vulnerabilities. For an unfixed one, the same instinct applies: tell customers what to do, and avoid details that make an attack easier than it needs to be.
Steps
- Confirm the issue and the affected versions.
- Find the narrowest safe workaround: disabling a feature, restricting access, or a configuration flag.
- Test the workaround, and note any cost to users.
- Write the action statement in imperative steps.
- Publish an affected statement with the action statement, and a promised next update time.
- Notify the exposed customers directly. See who to notify first.
- Keep the next update promise, even if the update is "no change".
- When the fix ships, move the status to fixed and publish the new version.
Writing the action statement
Use short steps in order. Say who can do each step. Say how to check it worked. Say what to do if it did not. Avoid "consider" and "may want to". If there is no workaround, say that plainly, and say what customers can do to reduce exposure, such as limiting network access.
Quick check
Can we use "under investigation" instead of affected?
Yes, while you are still determining the facts. Once confirmed, change to affected and add the action statement.
What if the workaround breaks a feature?
Say so. Customers can then weigh the risk and decide.
Safeguard's autonomous remediation with fix pull requests is off by default, so a team chooses when a fix PR is raised. A free scan can show affected dependencies.
Sources
- OpenVEX specification
- CSAF 2.0 specification, OASIS, Profile 5
- Regulation (EU) 2024/2847, EUR-Lex, Annex I Part II
Last reviewed: 19 October 2026.
