From 6a2821e0a2b9d39e909c84a968c90af4ea3f8488 Mon Sep 17 00:00:00 2001 From: Ulises Jeremias Date: Wed, 16 Sep 2026 14:31:17 -0300 Subject: [PATCH 1/4] fix(secrets-guide): stop printing a secret in the SDK example and drop duplicated direnv section The SDK retrieval example ended with console.log("Secret Password:", password), which demonstrates the exact anti-pattern the guide exists to prevent: secrets landing in stdout, CI logs and log aggregators. Replaced with a usage example that passes the value straight to the consuming client, plus an explicit warning. The "Using direnv for Local Development" section was also duplicated verbatim (body and table of contents), which is where the #using-direnv-for-local-development-1 anchor came from. Removed the second copy. --- .../README.md | 26 +++++++------------ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md b/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md index 7cb9da6..9b98ba2 100644 --- a/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md +++ b/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md @@ -14,7 +14,6 @@ Hello, Developer Friend! Welcome to your exciting journey into the _mystical lan - [Avoiding `.env` for Sensitive Data](#avoiding-env-for-sensitive-data) - [Secure Alternatives](#secure-alternatives) - [Using `direnv` for Local Development](#using-direnv-for-local-development) - - [Using `direnv` for Local Development](#using-direnv-for-local-development-1) - [Managing Different Stages with `direnv`](#managing-different-stages-with-direnv) - [Using `teller` for a Unified Approach](#using-teller-for-a-unified-approach) - [Using SDKs for Dynamic Retrieval](#using-sdks-for-dynamic-retrieval) @@ -68,19 +67,6 @@ export SUPER_STRONG_AND_COMPLICATED_PASSWORD=$(aws ssm get-parameter --name "SUP πŸ“ To set this up, you'll need `direnv` and `aws-cli` armed and ready. The official scrolls for `direnv` are here: [Direnv Documentation](https://direnv.net/docs/installation.html). -#### Using `direnv` for Local Development - -`direnv` is like your trusty sidekick that whispers secrets to you and only you when you enter your castle (or project directory). - -Instead of writing down your secrets, `direnv` can fetch them from AWS Parameter Store on the fly: - -```shell -# .envrc example -export SUPER_STRONG_AND_COMPLICATED_PASSWORD=$(aws ssm get-parameter --name "SUPER_STRONG_AND_COMPLICATED_PASSWORD" --with-decryption --query "Parameter.Value" --output text) -``` - -πŸ“ To set this up, you'll need `direnv` and `aws-cli` armed and ready. The official scrolls for `direnv` are here: [Direnv Documentation](https://direnv.net/docs/installation.html). - ##### Managing Different Stages with `direnv` If you’re a wizard of multiple realms (stages like `dev`, `staging`, `prod`), `direnv` can still be your arcane tool. Here's a spell to conjure the right environment based on your current stage: @@ -199,11 +185,19 @@ const getSecret = async () => { return Parameter.Value; }; -getSecret().then((password) => { - console.log("Secret Password:", password); +// Hand the secret straight to the client that needs it, and let it go out of +// scope. Never log it, never return it in an API response, never write it to disk. +const password = await getSecret(); + +const db = await createPool({ + host: process.env.DB_HOST, + user: process.env.DB_USER, + password, }); ``` +> ⚠️ **Never print a secret.** `console.log(password)` looks harmless in a snippet, but in a real service that value lands in stdout, CI job logs, container logs and whatever aggregator ships them (CloudWatch, Datadog, Splunk). Those are all places your secret should never be, and all places with far broader read access than your secrets store. If you need to confirm retrieval worked, log the parameter *name* or a boolean, never the value. + πŸ“š To learn this magic, visit the grand library here: [AWS SDK for JavaScript](https://docs.aws.amazon.com/sdk-for-javascript/index.html). ## Conclusion From 5f7d1c8f1050f31ce504368c8532c4de101ed38d Mon Sep 17 00:00:00 2001 From: Ulises Jeremias Date: Wed, 16 Sep 2026 14:32:00 -0300 Subject: [PATCH 2/4] fix(security-guide): repair broken AWS CodePipeline link and surface SHIFT_LEFT_SECURITY.md The AWS CodePipeline guide was linked as CONTINUOUS_INTEGRATION_WITH_AWS.md; the actual file is CONTINUOUS_INTEGRATION_WITH_AWS_CODE_PIPELINE.md, so the link 404'd. SHIFT_LEFT_SECURITY.md also existed in the directory with nothing linking to it, making it unreachable from the guide. --- .../README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/examples/the-ultimate-guide-to-security-assessment-tools/README.md b/examples/the-ultimate-guide-to-security-assessment-tools/README.md index d7850c1..d728242 100644 --- a/examples/the-ultimate-guide-to-security-assessment-tools/README.md +++ b/examples/the-ultimate-guide-to-security-assessment-tools/README.md @@ -45,6 +45,12 @@ Performing regular scans helps in maintaining a secure codebase by identifying v Check out the [Code Scanning](CODE_SCANNING.md) guide for more details. +### Shift-Left Security πŸ‘ͺ + +The principle behind everything else in this guide: move detection as close to the moment code is written as possible, because a finding costs less the earlier it surfaces. + +Read the [Shift-Left Security](SHIFT_LEFT_SECURITY.md) guide for the reasoning and the rollout order. + ### Early Stages of Development Workflows πŸš€ - **IDE Integrations**: Learn how to integrate security tools with popular IDEs like VS Code and JetBrains. @@ -74,7 +80,7 @@ Learn how to integrate security tools into your GitLab in this [guide](CONTINUOU Integrating security scans in [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/). -Learn how to set up security scans in AWS CodePipeline in this [guide](CONTINUOUS_INTEGRATION_WITH_AWS.md). +Learn how to set up security scans in AWS CodePipeline in this [guide](CONTINUOUS_INTEGRATION_WITH_AWS_CODE_PIPELINE.md). Using these CI/CD tools ensures that every change is tested and validated for security issues before being merged and deployed. From e4c06af78fae9518b12d5adb9b5bbd8af20fc8b8 Mon Sep 17 00:00:00 2001 From: Ulises Jeremias Date: Wed, 16 Sep 2026 14:48:18 -0300 Subject: [PATCH 3/4] chore(pr-template): require internal back-reference and link check for guide PRs Nineteen of twenty published framework guides had no reference from the internal knowledge base they were derived from, because publishing and linking back were never the same step. Two checklist items make the back-reference part of done, and one catches relative links that break when files are renamed or moved between guide folders. --- .github/PULL_REQUEST_TEMPLATE.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 104b95e..a0d8d7b 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -26,3 +26,13 @@ Please describe the tests that you ran to verify your changes. Provide instructi - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have checked my code and corrected any misspellings + +## Guides and Examples + +Only applies when this PR adds, renames, or moves a guide under `examples/`. + +- [ ] **Back-reference exists.** The internal knowledge-base chapter this guide came from links to it. Publishing a guide without the link back means nobody internal ever finds it β€” this is how guides end up orphaned. +- [ ] **Registered in `examples.json`,** so the `awesome-nan` catalog picks it up. +- [ ] **Links resolve.** Every relative link in the guide points at a file that exists on this branch. Renaming or moving a companion file silently breaks links from other guides and from the knowledge base. +- [ ] **Sanitized.** No client names, internal URLs, workspace identifiers, credentials, or PII. Placeholders (`-123`, `[git-host]`) instead of real internal values. +- [ ] **No unsafe examples.** Snippets do not print, log, or commit secrets, even as illustration. A copy-pasteable bad example is worse than no example. From 14e3821faad3ba75a0b009a4f283a201dea6a51a Mon Sep 17 00:00:00 2001 From: ulises-jeremias Date: Fri, 18 Sep 2026 10:58:47 -0300 Subject: [PATCH 4/4] fix: satisfy markdownlint and textlint on guides PR - Rewrap secrets-guide warning blockquote under MD013 limit and use underscore emphasis (MD049) - Template 'Bug fix' -> 'Bugfix' per textlint terminology rule (no Danger dependency on that string) --- .github/PULL_REQUEST_TEMPLATE.md | 2 +- .../README.md | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index a0d8d7b..841cc5d 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -6,7 +6,7 @@ Fixes # (issue) ## Type of Change -- [ ] Bug fix (non-breaking change which fixes an issue) +- [ ] Bugfix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] Documentation update diff --git a/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md b/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md index 9b98ba2..7647697 100644 --- a/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md +++ b/examples/the-ultimate-guide-to-secrets-management-for-developers/README.md @@ -196,7 +196,9 @@ const db = await createPool({ }); ``` -> ⚠️ **Never print a secret.** `console.log(password)` looks harmless in a snippet, but in a real service that value lands in stdout, CI job logs, container logs and whatever aggregator ships them (CloudWatch, Datadog, Splunk). Those are all places your secret should never be, and all places with far broader read access than your secrets store. If you need to confirm retrieval worked, log the parameter *name* or a boolean, never the value. +> ⚠️ **Never print a secret.** `console.log(password)` looks harmless in a snippet, but in a real service that value lands in stdout, CI job logs, container logs and whatever aggregator ships them (CloudWatch, Datadog, Splunk). +> +> Those are all places your secret should never be, and all places with far broader read access than your secrets store. If you need to confirm retrieval worked, log the parameter _name_ or a boolean, never the value. πŸ“š To learn this magic, visit the grand library here: [AWS SDK for JavaScript](https://docs.aws.amazon.com/sdk-for-javascript/index.html).