Every scanner integration starts with a token. Where that token lives afterwards is an architectural decision most teams make implicitly — by pasting it into a variable group, an extension setting, or a pipeline secret, where it is one verbose log line or one misconfigured fork away from exposure.
The common leak paths
- Variable groups readable by broad project scopes and echoed by debugging steps.
- Queue and webhook payloads that carry credentials 'for convenience'.
- Tokens embedded in pipeline YAML or task parameters, then cloned with the repo.
- Long-lived personal access tokens created by an admin who has since left.
Principles that prevent them
Credentials belong in managed secret storage, resolved server-side at the moment of use, by the narrowest identity that needs them. Work items in queues should carry references and context — never secrets. Rotation should be an operational action with an audit record, not an archaeology project.
How Kangl handles provider secrets
In Kangl, provider credentials are stored as references to managed secret storage such as Azure Key Vault; the backend resolves them only at the controlled boundary where a provider call happens. Queue messages between the API and workers carry tenant and job context — not credentials. Pipelines never see the provider token at all, because the control plane makes the provider calls.
