Token lifecycle, CLI, and CI/CD use

Automation scope

• Repository management APIs
• SBOM submission and scan-status queries
• Policy-decision use within CI/CD
• Separate permission scope and token lifecycle

Token lifecycle

Automation identity must remain separate from human sessions; record purpose, owner, permission scope, and expiry or rotation plan when creating a token. Handle the token value only during secure transfer at creation and never write it to logs or documentation.

• A separate least-privileged token for each pipeline or integration
• Injection from a secret manager with no value in source, image, artifact, or build logs
• Successful use, out-of-scope denial, revocation, and rejection of the old token after rotation
• Responsibility to revoke the token when its owner leaves or the pipeline is retired

CI/CD decision flow

The pipeline submits a CycloneDX SBOM with fixed organization, project, and environment context, tracks the scan identity, and queries the terminal result. Pipeline behavior for PASS, WARN, BLOCK, or NOT_EVALUATED must be explicitly defined in the organization's gate policy.

Resilience and observability

Choose client timeouts, retries, and polling intervals to align with idempotency and rate boundaries. Trace each call with correlation, task, or scan identity and verify retries do not accidentally duplicate work.

Automation security boundary

Client-side checks are not a security boundary; API authorization applies to every request. Retain pipeline decisions with the source snapshot and policy revision used. Because no complete public endpoint and SDK version matrix is available, pin the target API contract in the acceptance environment.