Summary
Currently, the backstage-plugin-wiz backend uses a single set of administrative credentials (Client ID/Secret) to fetch data from the Wiz API. This leads to a vertical privilege escalation scenario where any Backstage user can see security issues of any project/entity, regardless of their actual permissions in Wiz or their ownership of the service in Backstage.
The Problem
In an enterprise-wide rollout, the current architecture lacks data isolation:
Global Visibility: The backend proxy executes all requests with the privileges of the configured Wiz Service Account.
No Ownership Validation: A user who is not a member of "Team A" can still see all vulnerabilities, misconfigurations, and secrets identified by Wiz for "Team A" services simply by browsing the Backstage Catalog.
Compliance Risk: This violates the "Principle of Least Privilege" (PoLP) and may breach internal security policies regarding the exposure of sensitive vulnerability data.
Proposed Solution: User-Context Aware Fetching
We need a mechanism to ensure that the user requesting the data in Backstage is actually authorized to see it.
Use Case
"As a Security Officer, I want to ensure that developers only see security issues relevant to their own services, while sensitive infrastructure vulnerabilities remain restricted to the Cloud Security Team."
Summary
Currently, the backstage-plugin-wiz backend uses a single set of administrative credentials (Client ID/Secret) to fetch data from the Wiz API. This leads to a vertical privilege escalation scenario where any Backstage user can see security issues of any project/entity, regardless of their actual permissions in Wiz or their ownership of the service in Backstage.
The Problem
In an enterprise-wide rollout, the current architecture lacks data isolation:
Global Visibility: The backend proxy executes all requests with the privileges of the configured Wiz Service Account.
No Ownership Validation: A user who is not a member of "Team A" can still see all vulnerabilities, misconfigurations, and secrets identified by Wiz for "Team A" services simply by browsing the Backstage Catalog.
Compliance Risk: This violates the "Principle of Least Privilege" (PoLP) and may breach internal security policies regarding the exposure of sensitive vulnerability data.
Proposed Solution: User-Context Aware Fetching
We need a mechanism to ensure that the user requesting the data in Backstage is actually authorized to see it.
Use Case
"As a Security Officer, I want to ensure that developers only see security issues relevant to their own services, while sensitive infrastructure vulnerabilities remain restricted to the Cloud Security Team."