Awesome Reviewers expert instructions

domains / / awslabs/aidlc-workflows

Secure-by-default integrations

When adding configurable external services/integrations (e.g., registries, MCP servers, plugins), apply security-by-default and supply-chain controls—especially when the integration can access credentials.

raw .md Security Json

When adding configurable external services/integrations (e.g., registries, MCP servers, plugins), apply security-by-default and supply-chain controls—especially when the integration can access credentials.

Apply:

  • Default-off: Do not enable external/incoming server entries by default. Require an explicit opt-in (e.g., config flag, environment variable, or explicit allowlist).
  • No mutable releases: Avoid using tags like @latest (or other non-deterministic references). Pin to an exact version (and ideally verify integrity/checksum).
  • Credential awareness: If the integration can use local AWS/other credentials, make that behavior explicit and least-privilege; require explicit enablement/authorization.
  • Document rationale: Record the security decision (why enabled, which credentials, which pinned versions) so future changes preserve the security posture.

Example (pattern):

{
  "mcpServers": {
    "aws-mcp": {
      "enabled": false,
      "command": "uvx",
      "args": ["mcp-proxy-for-aws@1.2.3"],
      "notes": "Disabled by default; requires explicit opt-in due to credential usage."
    }
  }
}

If you need a registry to be enabled, document the exact reason, threat model, and pinned dependency versions—and ensure credentials are not implicitly accessible without explicit consent.