deploy/scaffold skills should gate on auth when proprietary data is detected #9
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
When deploying an app that serves proprietary/client data (financials, PII,
trade secrets), the deploy/scaffold workflow should detect this and refuse
to release without auth (forward-auth or equivalent). Today it does not.
Case study
SJC dashboard deployed to
dashboard.apps.sonomajetcenter.com(a static HTMLdashboard rendering SJC's financial data — customer names, aircraft tail
numbers, fuel volumes, GL balances). The deploy proceeded without any auth
check. The dashboard served publicly (HTTP 200, no redirect, no auth gate)
until the operator caught it and requested auth be implemented.
The
enable-forward-authskill exists and works — the gap is that nothinginsists on it being called before release. The operator had to notice.
Suggested fix
Add an auth-gate to the deploy/scaffold skills (or a pre-deploy check):
When an app is deployed/scaffolded to a
*.apps.<tenant-domain>surface,check whether the app content is flagged as containing proprietary data.
This could be:
dataClassification: proprietaryin the app'smanifest/ingress.yaml)
If proprietary data is detected (or the flag is set), refuse to complete
the deploy until
enable-forward-authhas been run for the app's domain.Surface the command the operator needs to run.
If the operator explicitly wants a public app, require an opt-out flag
(e.g.,
public: truein the ingress.yaml) with a clear audit trail.Impact
Without this gate, any app deployed to a
*.appssurface serves publicly bydefault. For proprietary data, this is a data-breach risk. The operator
caught this one; the next one might not be caught.
Related
enable-forward-authskill exists and works (tested on SJC dashboard).*.appsblock has a comment saying "Auth middleware runs forall requests" but no actual auth directive is injected until forward-auth
is configured per-app.
this is a different gap (auth detection, not field naming).
Fixed in dit-client PR #54 (merged). Warn-severity check (DIT-CHK-016) fires on deploy of apps with proprietary data_classes without forward-auth. Explicit dit.public: true opt-out suppresses with an Info record (DIT-CHK-017).