Describe the feature
The generated Aws::SSOOIDC::Client documentation embeds realistic-looking JWTs in its @example blocks for create_token and create_token_with_iam. Because these are full eyJ…-shaped tokens rather than obvious placeholders, secret scanners flag them as leaked credentials when they scan an application's installed gems / built container image.
Concretely, scanning an image that bundles aws-sdk-core (3.251.0) with Trivy's secret scanner produces a false positive on lib/aws-sdk-ssooidc/client.rb via the built-in jwt-token rule. The same false positive is reproducible with gitleaks and other regex-based scanners, and the same example values appear in aws-sdk-js-v3 and botocore, so this affects downstream consumers across all AWS SDKs.
These are clearly intentional example values (account 123456789012, ssoins-111111111111, the Microsoft AbeLi@microsoft.com sample OIDC token, etc.), so this is a documentation-quality / false-positive-noise issue, not a leaked secret.
Affected examples
In aws-sdk-core 3.251.0, lib/aws-sdk-ssooidc/client.rb (generated from the SSO-OIDC examples-1.json model, API version 2019-06-10):
id_token in the example responses (the create_token_with_iam authorization-code, JWT-bearer, and token-exchange grant examples)
assertion in the JWT-bearer grant example request
client_secret in the create_token example requests (VERYLONGSECRETeyJ…)
Note the inconsistency: the neighboring access_token, refresh_token, and authorization code examples already end in explicit …EXAMPLEACCESSTOKEN / …EXAMPLEREFRESHTOKEN / …EXAMPLEAUTHCODE markers, but the JWT-shaped values do not, which is exactly why scanners single them out.
Proposed change
Redact the JWT-shaped example values in the canonical SSO-OIDC service model (examples-1.json) so they are unmistakably non-secret while still illustrating the field shape — for example a short, obviously-fake stub such as eyJhbGciOiJub25lIn0.eyJzdWIiOiJFWEFNUExFIn0.EXAMPLE or a <id-token>-style placeholder — matching the EXAMPLE… convention already used for the surrounding tokens. Because the SDK clients are generated from this shared model, fixing it upstream propagates to all SDKs.
Reproduction
trivy fs --scanners secret <path-to-bundled-gems>/aws-sdk-core-3.251.0
# or against an image that bundles the gem:
trivy image --scanners secret <image>
# -> JWT (jwt-token) finding on lib/aws-sdk-ssooidc/client.rb
Environment
aws-sdk-core 3.251.0
- Trivy 15.0.7 (
jwt-token secret rule); also reproducible with gitleaks
Describe the feature
The generated
Aws::SSOOIDC::Clientdocumentation embeds realistic-looking JWTs in its@exampleblocks forcreate_tokenandcreate_token_with_iam. Because these are fulleyJ…-shaped tokens rather than obvious placeholders, secret scanners flag them as leaked credentials when they scan an application's installed gems / built container image.Concretely, scanning an image that bundles
aws-sdk-core(3.251.0) with Trivy's secret scanner produces a false positive onlib/aws-sdk-ssooidc/client.rbvia the built-injwt-tokenrule. The same false positive is reproducible with gitleaks and other regex-based scanners, and the same example values appear inaws-sdk-js-v3andbotocore, so this affects downstream consumers across all AWS SDKs.These are clearly intentional example values (account
123456789012,ssoins-111111111111, the MicrosoftAbeLi@microsoft.comsample OIDC token, etc.), so this is a documentation-quality / false-positive-noise issue, not a leaked secret.Affected examples
In
aws-sdk-core3.251.0,lib/aws-sdk-ssooidc/client.rb(generated from the SSO-OIDCexamples-1.jsonmodel, API version 2019-06-10):id_tokenin the example responses (thecreate_token_with_iamauthorization-code, JWT-bearer, and token-exchange grant examples)assertionin the JWT-bearer grant example requestclient_secretin thecreate_tokenexample requests (VERYLONGSECRETeyJ…)Note the inconsistency: the neighboring
access_token,refresh_token, and authorizationcodeexamples already end in explicit…EXAMPLEACCESSTOKEN/…EXAMPLEREFRESHTOKEN/…EXAMPLEAUTHCODEmarkers, but the JWT-shaped values do not, which is exactly why scanners single them out.Proposed change
Redact the JWT-shaped example values in the canonical SSO-OIDC service model (
examples-1.json) so they are unmistakably non-secret while still illustrating the field shape — for example a short, obviously-fake stub such aseyJhbGciOiJub25lIn0.eyJzdWIiOiJFWEFNUExFIn0.EXAMPLEor a<id-token>-style placeholder — matching theEXAMPLE…convention already used for the surrounding tokens. Because the SDK clients are generated from this shared model, fixing it upstream propagates to all SDKs.Reproduction
Environment
aws-sdk-core3.251.0jwt-tokensecret rule); also reproducible with gitleaks