Current Behavior In SCS SBOM Orchestration → SBOM Attestation (Private Key / Password / Public Key fields): * The UI allows: * Fixed value * Runtime input ( <+input> ) * Expression However, these fields only accept secret identifiers*** in practice, such as: * mySecret * org.mySecret * account.mySecret If a user supplies an expression that resolves to a secret value (for example a Secret-type variable or \<+secrets.getValue("id")> ), the pipeline fails validation with errors like: > Invalid Secret Reference. Valid references must be one of the following formats [ id, org.id, account.id ] for scope [ project, organisation, account ] respectively This means SCS effectively treats these fields as “identifier-only”, even though the UI advertises Expression and Runtime input as options. --- Problem This behavior is: * Inconsistent with STO and other CI steps , which generally: * Accept secret values , * Support Secret-type variables and secrets.getValue(...) expressions, * Handle nested expressions that resolve to secrets. * Confusing for users , because: * The UI suggests they can use expressions and secret variables the same way they do in STO/CI. * But SCS rejects those patterns and requires them to pass only identifiers. * Limiting for reuse and governance , because: * It’s harder to dynamically pick different attestation keys per environment/org/project. * Users must resort to “String variable that holds a secret identifier” patterns, which is not intuitive and feels like a workaround. This is already surfacing in real customer pipelines and is likely to affect more users as HAR + SBOM adoption grows. --- Desired Behavior Align SCS SBOM Attestation secret handling with STO/CI , so that: Private Key / Password / Public Key fields accept: * Direct secret identifiers ( id , org.id , account.id ) — as they do today. * Expressions that resolve to secret identifiers , e.g.: ```yaml <+stage.variables.sbom_private_key_id> # "cosign_pk_test" ``` * Expressions that resolve to secret values , including: * \<+secrets.getValue("mySecret")> * Pipeline/stage variables of type Secret * Nested expressions that ultimately resolve to a secret. Validation happens after expression evaluation , similar to STO: * The expression is evaluated first. * If the result is a valid secret reference or secret value, the step proceeds. * Only truly invalid values should trigger the “Invalid Secret Reference” error. Backward compatible behavior : * Existing SCS pipelines that use plain identifiers should continue to work as-is. * New pipelines can adopt the more flexible STO/CI-style patterns without surprises. --- Why This Matters * Reduces confusion and support noise by bringing SCS in line with the rest of CI/STO . * Makes it much easier to: * Reuse SBOM/attestation pipelines across multiple environments, * Follow best practices for secret management (no hard-wiring per-step), * Build dynamic, policy-driven setups (e.g., different keys per env/org). * Matches user expectations: if a field supports “Expression” and is secret-related, it should behave consistently across modules.
