For SaaS that ships continuously, "prior to release" means the vulnerability check runs in the pipeline before each change reaches production, and also on a schedule between releases. The CISA form asks for both: automated checks "on an ongoing basis and prior to product, version, or update releases."
The sentence in the form
Item 4a of Section III says the producer "operates these processes on an ongoing basis and prior to product, version, or update releases." Item 4b adds a policy or process to address discovered vulnerabilities "prior to product release."
The form also names the scenario. Its scope section lists software where "the producer delivers continuous changes to the software code (as is the case for software-as-a-service products or other products using continuous delivery/continuous deployment)." So hosted products were expected to answer the same item, just in a faster rhythm.
Two clocks to run
| Clock | What triggers it | Example check |
|---|---|---|
| Per change | Every merge or deploy | Dependency scan and code analysis as a blocking pipeline step |
| Ongoing | A schedule or a new advisory | Nightly rescan of what is already deployed |
The per change clock proves the "prior to release" part. The ongoing clock matters because a dependency that was clean on Monday can have a new advisory by Thursday while your code has not changed.
Define what blocks a release
A check that never blocks anything is hard to call a process. Write down:
- Which findings stop a release, for example a known exploited vulnerability in a reachable dependency.
- Who can approve an exception, and for how long.
- Where the exception is recorded.
- How a failed gate gets back to the owning team.
This is the content of item 4b, a policy or process for addressing discovered issues before release. The form's appendix links item 4 to SSDF tasks PO.4.1 (define criteria for software security checks) and PO.4.2 (implement processes to gather the information that supports those criteria).
Evidence that satisfies a reader
- The pipeline definition showing the scan step and its failure behavior.
- A sample of recent runs, including at least one that failed and was fixed.
- The schedule definition for the between releases scan.
- The exception log with dates and approvers.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what the gate checks on a pull request and what happens to a change that fails it.
Where Safeguard fits
Safeguard offers policies, gates and guardrails that can block a pull request on dependency findings, plus continuous monitoring of what you have already shipped. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does every deploy need a full scan?
The form says the checks run before releases and on an ongoing basis. How deep each run goes is your call, as long as the process is consistent and documented.
Is a nightly scan alone enough?
The form's wording asks for pre-release checks as well, so a schedule alone leaves the "prior to release" part open.
Sources
Last reviewed: 19 October 2026.
