"Fix available" can mean three different things: the upstream project has released a fix, your team has built and tested a fixed version, or the fix is deployed in the customer's environment. Tell customers only the stage that is true, and name it.
The three stages
| Stage | What is true | Safe customer wording |
|---|---|---|
| Upstream fix released | The maintainers of a component published a fixed version | A fix exists upstream. We are testing it in our product |
| Fixed build ready | Our product with the fix has been built and tested | A fixed version is ready and will be released on [date] |
| Fix deployed or released | Customers can run the fixed version | A fixed version is available. Here is how to get it |
Skipping a stage in a message is how companies end up saying "fixed" while customers still run the vulnerable build.
Who decides which stage you are at
Engineering owns the facts. Support, sales and comms quote them. A simple rule: the stage on the shared status page is the stage that can be quoted, and only the status owner changes it.
Link the fix to a VEX status
In the OpenVEX specification, fixed means product versions contain a fix, and a fixed statement names those versions. That is a useful discipline: if you cannot name the versions, you are not at the third stage.
Checks before announcing
- Does the fixed version actually contain the updated component? Check the dependency list of the build, not only the changelog.
- Do tests pass, and has the fix been verified against the original flaw where possible?
- Is the release available through every channel customers use, such as downloads, package registries and update mechanisms?
- Are release notes written without overclaiming?
CISA describes an SBOM as a nested inventory of software components (CISA). Comparing the SBOM of the fixed build to the old one is a direct way to confirm the new component version is in.
What if the fix is partial
Say so. "This release addresses the issue for the web interface. The command line tool will be updated on [date]." Partial fixes described as complete are the most damaging kind of statement.
What to tell customers who cannot upgrade yet
Offer the mitigation and the date. Give them the same facts you would want: which versions, what to change, how to verify.
Keeping the record
Log the date each stage was reached. If a customer later asks "when did you know and when did you fix it?", the log answers without reconstruction.
Try it yourself
Click through it at your own pace, or open it full screen. Click through to see how a fix is proposed, reviewed and applied. Look for the point at which it becomes releasable, not just available.
Where Safeguard fits
Safeguard provides fix pull requests through autonomous remediation, which is off by default with every category on Manual, along with SBOMs to verify what a build contains. The free scan is at gold.safeguard.sh/scan.
Quick check
Can we tell customers a fix is coming?
Yes, if you say which stage it is at and give a date only when engineering has committed to one.
How do we verify the fixed build?
Compare its dependency list to the earlier one and confirm the updated component version is present.
Sources
Last reviewed: 19 October 2026.
