G
Granite Caterpillar
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:
  1. 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.
  1. 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.
  1. 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.
Created by Pedro Mastelaro
·