Notifications
Clear all
Topic starter
02/08/2026 9:40 am
TL;DR: CISA’s guidance on software transparency in SaaS environments argues for broader inventories than traditional SBOMs because developers are assembling cloud services, APIs, and third-party tools faster than governance can track them, according to OXSecurity. For identity and security teams, the real issue is not inventory alone but controlling who and what can connect, share data, and persist access across SaaS workflows.
NHIMG editorial — based on content published by OXSecurity: software transparency in SaaS environments and the case for SaaS BOM
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: What breaks when departments adopt SaaS tools without identity review?
A: Ownership, offboarding, and access review all break at the same time.
Q: Why does SaaS sprawl increase non-human identity risk?
A: SaaS sprawl increases NHI risk because every new integration can create tokens, service accounts, OAuth grants, and delegated permissions that persist outside normal review cycles.
Q: How do security teams know if SaaS inventory is actually working?
A: A working SaaS inventory can answer three questions quickly: what is connected, who owns it, and what data or privileges it can reach.
Practitioner guidance
- Map every SaaS integration to an owning team Require each SaaS connection, automation account, and external app to have a named owner, an approval record, and a revocation path so shadow tools do not persist without accountability.
- Inventory non-human identities alongside SaaS apps Track API keys, OAuth grants, service accounts, and other machine credentials with the same discipline used for application inventory, because the access path is often the real exposure.
- Tie SaaS approval to data-flow review Review what data leaves the environment, where it lands, and which third parties can reuse it, then block approvals when the data path is unclear or broader than the use case.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- How SaaS BOM is structured to document application usage, data handling, and vendor approval workflows
- The specific operational use cases for finding rogue applications and hidden data flows across SaaS estates
- How the vendor positions SaaS BOM alongside PBOM for developers who need deeper software lineage visibility
- What the source article says about using SaaS BOM for policy compliance and security response
👉 Read OXSecurity's analysis of SaaS BOM and software transparency in SaaS environments →
SaaS BOM and developer cloud sprawl: what IAM teams need to know?
Explore further
02/08/2026 12:34 pm
Software transparency has become an identity governance problem, not just a software inventory problem. Traditional SBOM thinking helps with component traceability, but SaaS-heavy development adds delegated access, hidden integrations, and persistent machine identities to the risk picture. When a tool can read data, call APIs, or automate builds, governance has to follow the identity path, not only the software label. The practitioner conclusion is that SaaS visibility must be treated as access governance.
A question worth separating out:
Q: Who is accountable when a SaaS integration exposes customer data?
A: Accountability sits with the organisation that owns the delegated access path, even if the token originated from a third-party service. Security, application, and SaaS owners all need a defined revocation process and an incident playbook. If the integration can reach customer data, it must be governed like any other privileged identity.
👉 Read our full editorial: SaaS BOM exposes the governance gap in developer cloud sprawl
