Some will, especially larger health systems. Prepare a one page description of how code moves from commit to release: who can change it, what checks run, how dependencies enter, and how releases are traced. NIST's Secure Software Development Framework gives you a shared vocabulary for the conversation.
Why a reviewer looks at the pipeline
A dependency scan tells them what you ship. The pipeline tells them whether what you ship can be changed without anyone noticing. NIST describes the SSDF as a core set of high-level secure software development practices that can be integrated into any SDLC, and says it gives purchasers a common vocabulary for talking to suppliers. A hospital security team can use it that way.
The one page
| Topic | What to state | Evidence |
|---|---|---|
| Source control | Who can merge, whether review is required | Branch protection settings |
| Dependency entry | How new components are added and checked | Pull request check, policy |
| Build | Where it runs, whether it is reproducible, who can edit the definition | Pipeline file, access list |
| Checks | Which tests and scans run, what blocks a release | Pipeline run example |
| Secrets | How credentials reach the build | Secret store description |
| Release | How artifacts are stored, tagged and traced to commits | Registry and tag convention |
| Access | Who can deploy, how access is reviewed | Access review record |
State what is enforced by tooling separately from what depends on people following a process. Reviewers value that distinction.
Steps to prepare
- Draw the pipeline as five boxes: commit, review, build, test, release.
- Under each, list the control and where it is enforced.
- Mark gaps honestly with a plan and a date.
- Collect one screenshot or export per control. Remove secrets and internal hostnames first.
- Practice walking through it in five minutes.
Controls that carry weight
- Required review before merge to the release branch.
- A check that blocks new components with known critical flaws, or at least flags them.
- Build definitions stored in the repository and reviewed like code.
- Limited, logged access to production deploys.
- Artifacts tied to the commit that produced them, so you can answer what shipped on a given date.
What not to claim
Do not call a pipeline "fully secure" or "tamper proof." Do not claim alignment with a framework you have not actually mapped. If you reviewed your practices against the SSDF, say you used it as a reference, and show which practices you cover and which you do not.
Try it yourself
Click through it at your own pace, or open it full screen. It shows a check blocking a change at review time, which is the control reviewers most want to see enforced.
Safeguard's policies, gates and guardrails run in pull requests and pipelines, and its SBOM and dependency scanning feed the checks.
Quick check
Do we have to follow the NIST SSDF?
Not as a rule for most private vendors. It is guidance that many buyers use as a reference, so mapping to it can help answers.
What if our pipeline is mostly manual?
Say so, describe the checks people perform, and list the steps you will automate first.
Sources
Last reviewed: 19 October 2026.
