SSPM covers settings inside SaaS apps, a different surface from vulnerable code and packages. In a vulnerability and supply chain program it fits as a configuration risk feed, owned by IT or cloud teams, tied to the same asset register and ticket flow rather than run as a separate island.
What does each program look at?
| Program | Looks at | Typical finding |
|---|---|---|
| Vulnerability management | Software you run, versions, patches | Unpatched server |
| Software supply chain security | Code, packages, build and release | Malicious or vulnerable dependency |
| SSPM | Configuration of SaaS apps | Public sharing link default, admin without strong sign in |
All three result in a list of things to fix and an owner. That similarity is the reason to integrate them.
Why do SaaS settings belong in the same conversation?
Because they connect. Your source code host, build service, ticketing tool and chat are SaaS apps. A setting that lets any member create a token with broad access to repositories is a supply chain issue and an SSPM issue at once. The same goes for third party apps authorized against your code host.
NIST's Secure Software Development Framework, SP 800-218, expects protected development environments, including controlling access to code and build tools. Many of those environments are SaaS products, and their configuration is how access is controlled.
Where does the program connect?
Asset register. Add SaaS apps with business owner, data type and admin count. The same register that tracks servers and applications should hold them.
Priority. Rank by what the app holds and connects to. A misconfiguration in the tool that deploys code to production outranks one in a rarely used survey tool.
Ticket flow. SSPM findings should land in the queue engineering and IT already use, with the same severity words and due dates.
Ownership. Name a person per app. Without one, findings age.
Reporting. Show SaaS configuration findings beside software vulnerabilities in the same risk review, so leadership sees one program.
What should you cover first?
Start with SaaS tools in the software delivery chain: code hosting, CI service, package registry, artifact storage, secrets management, and the identity provider. Check:
- Who can create access tokens, and with what scope?
- Which third party apps hold access to repositories?
- Is strong sign in required for all admins?
- Are audit logs on, and kept long enough to use?
- Can anyone change branch protections or approval rules?
These are checks you can do by hand before buying any tool, to learn where the real gaps are.
What does it not replace?
SSPM does not find vulnerable packages, test code, or check that a build was not tampered with. It does not replace vulnerability scanning of what you run.
A constructed example from a delivery chain
Imagine a company where any member of the code hosting organization can authorize third party apps. A developer connects a handy code formatting app that asks for broad repository access. Nobody reviews it. Months later the app's maker changes ownership. Nothing in vulnerability scanning would flag this, because no package is vulnerable. A posture check on the code host's settings would show that app authorization is open to everyone, and a review of grants would show the broad access. This example is invented, but the pattern is common enough that grant reviews belong in every supply chain program.
How often should you review these settings?
Review the delivery chain tools monthly at first, because teams change settings often while they are building processes. Once the baseline is stable, move to quarterly, and trigger an extra review whenever you add a new tool, change identity provider or reorganize teams. Record each review with the date, reviewer and changes made, so an auditor can see the control working over time and so you can spot drift between reviews.
Where Safeguard fits
SSPM is outside Safeguard's scope, and Safeguard does not replace an SSPM tool. Safeguard works on the code and delivery side: reachability analysis, policies and gates enforced at build, CI and release, and compliance evidence automation. Together with SaaS posture checks run elsewhere, this covers both what you ship and the tools you ship with.
What to do
- Add SaaS apps to the asset register with owner and data type.
- Rank apps by what they hold and connect to.
- Review the five delivery chain checks above by hand.
- Route SSPM findings into your existing ticket queue.
- Report SaaS and software findings in the same review.
Quick check
Is a code hosting setting a supply chain issue?
Yes. Who can create tokens, change branch rules or authorize third party apps decides who can alter your code, which is a supply chain concern.
Should SSPM be a separate program?
It can be a separate tool but should share the asset register, ticket flow and reporting with the rest of your risk program.
Sources
- NIST SP 800-218, Secure Software Development Framework
- NIST SP 800-207, Zero Trust Architecture
- NIST Cybersecurity Framework 2.0
Last reviewed: 18 October 2026.
